Barracuda09
Every day the same problem, only a restart helps
After a certain period of non-use of SatPi and TVHeadend (usually the next day), SatPi always stops working. As soon as I try to watch a channel (free or encrypted), the tuner in the front-end overview turns blue, but not green, and I can't watch TV. Only restarting Enigma2 (OpenATV 7.5.1) solves the problem.
SatPi Version: 1.6.2.204~gfe180a5
I would like to attach a log file, but it is really difficult to capture everything from the log window.
You can send the log to syslog, see attached picture and enable:
- Log messages to syslog
- Log Debug messages
It happened again. I previously enabled syslog, but where is the log saved?
Edit: Here is the Log file. The problem should start at around 7:20 PM in the log. But maybe earlier too.
For some reason the tuner locks but does not give data in this situation.
Could you give a log when it is working.
Hello. I restarted the VU+ and shortly afterward successfully ran a stream for about a minute. Here's the log file.
What happens if you restart SatPI within the webGUI of SatPI? And not restart Enigma or reboot box
Today it happened again, tuners are only displayed blue and there is no signal. This time I only restarted Satpi. After that, the tuner is not even more than blue when I open a channel. Nothing happens at all in Frontend Overview.
Here is the log:
Did you have a look at this, how to setup TvHeadend: https://github.com/Barracuda09/SATPI/wiki/Using-SatPI-as-frontend-for-Tvheadend
Pay special attention to Maximum PIDs make this between 15 - 20 max
I solved the problem differently. I set the receiver to restart every morning at 4:00 a.m. and then go directly into standby mode. Since then, I've had no problems with inactive tuners. I have OpenATV (latest version) installed.
The problem occurs when there is a power outage. SATPI starts before the internet provider's router finishes initializing...
@lgm75 That seems not a problem of SatPI, but from the image an init order
@lgm75 That seems not a problem of SatPI, but from the image an init order
Perhaps...
I made a script run with cron and now it is OK :
#!/bin/bash
sleep 60
/usr/bin/curl -s http://192.168.1.10:8875/STOP
sleep 5
/usr/bin/satpi --iface-name eth0
I have build a new version for Vu, could you try if it works better? 1.6.2.204~gfe180a5_Enigma.zip
Only works for a few hours, then we have the restart the receiver to get access to the tuners again. I had the some problem with MiniSatIP, now "mode 0" works for me, see here for more details.
@LITUATUI Thanks for you sponsoring.
You could try to restart SatPI from the web GUI.
What is your setup?
- Much activity like EPG scan or mux scan
I know the drivers from Vu are not as stable as it should be. And not updated that often.
No problem :)
Yes, I can restart SatPI from the web GUI.
My setup:
- VU+ Uno 4K SE with FBC DVB-C tuner
- OpenPLI (development builds)
- TVHeadend + Cloudflared (docker compose in a N100 mini PC)
What I usually do, is to only have one tuner (the first one) with EPG scanning enabled on TVHeadend. Then I give higher priority from the last to the first tuner.
I'll try again without channel or EPG scanning to see if it's more stable and report back.
Didn't last a hour.
Mon Jul 28 15:54:31.4572 2025 7 Client: 192.168.0.235 requested desc.xml Mon Jul 28 15:54:31.4601 2025 6 HTTP Client 192.168.0.235:56542 Connection closed with fd: 8 Mon Jul 28 15:54:31.6582 2025 6 HTTP Connection from 192.168.0.235 Port 56544 with fd: 8 Mon Jul 28 15:54:31.6584 2025 7 Client: 192.168.0.235 requested desc.xml Mon Jul 28 15:54:31.6606 2025 6 HTTP Client 192.168.0.235:56544 Connection closed with fd: 8 Mon Jul 28 15:54:31.8604 2025 6 HTTP Connection from 192.168.0.235 Port 56546 with fd: 8 Mon Jul 28 15:54:31.8606 2025 7 Client: 192.168.0.235 requested desc.xml Mon Jul 28 15:54:31.8662 2025 6 HTTP Client 192.168.0.235:56546 Connection closed with fd: 8 Mon Jul 28 15:55:32.4575 2025 6 HTTP Connection from 192.168.0.235 Port 56746 with fd: 8 Mon Jul 28 15:55:32.4577 2025 7 Client: 192.168.0.235 requested desc.xml Mon Jul 28 15:55:32.4607 2025 6 HTTP Client 192.168.0.235:56746 Connection closed with fd: 8 Mon Jul 28 15:55:32.6582 2025 6 HTTP Connection from 192.168.0.235 Port 56748 with fd: 8 Mon Jul 28 15:55:32.6584 2025 7 Client: 192.168.0.235 requested desc.xml Mon Jul 28 15:55:32.6628 2025 6 HTTP Client 192.168.0.235:56748 Connection closed with fd: 8 Mon Jul 28 15:55:32.8587 2025 6 HTTP Connection from 192.168.0.235 Port 56750 with fd: 8 Mon Jul 28 15:55:32.8590 2025 7 Client: 192.168.0.235 requested desc.xml Mon Jul 28 15:55:32.8617 2025 6 HTTP Client 192.168.0.235:56750 Connection closed with fd: 8 Mon Jul 28 15:55:45.4648 2025 6 HTTP Connection from 192.168.0.121 Port 41440 with fd: 8 Mon Jul 28 15:55:45.4668 2025 6 HTTP Connection from 192.168.0.121 Port 41444 with fd: 10 Mon Jul 28 15:55:45.4671 2025 6 HTTP Connection from 192.168.0.121 Port 41450 with fd: 13 Mon Jul 28 15:55:45.4674 2025 6 HTTP Connection from 192.168.0.121 Port 41458 with fd: 14 Mon Jul 28 15:56:33.4552 2025 6 HTTP Connection from 192.168.0.235 Port 56904 with fd: 11 Mon Jul 28 15:56:33.4554 2025 7 Client: 192.168.0.235 requested desc.xml Mon Jul 28 15:56:33.4587 2025 6 HTTP Client 192.168.0.235:56904 Connection closed with fd: 11 Mon Jul 28 15:56:33.6549 2025 6 HTTP Connection from 192.168.0.235 Port 56910 with fd: 11 Mon Jul 28 15:56:33.6558 2025 7 Client: 192.168.0.235 requested desc.xml Mon Jul 28 15:56:33.6589 2025 6 HTTP Client 192.168.0.235:56910 Connection closed with fd: 11 Mon Jul 28 15:56:33.6658 2025 6 HTTP Connection from 192.168.0.235 Port 56912 with fd: 15 Mon Jul 28 15:56:33.6664 2025 7 Client: 192.168.0.235 requested desc.xml Mon Jul 28 15:56:33.6687 2025 6 HTTP Client 192.168.0.235:56912 Connection closed with fd: 15 Mon Jul 28 15:56:33.8560 2025 6 HTTP Connection from 192.168.0.235 Port 56918 with fd: 11 Mon Jul 28 15:56:33.8562 2025 7 Client: 192.168.0.235 requested desc.xml Mon Jul 28 15:56:33.8594 2025 6 HTTP Client 192.168.0.235:56918 Connection closed with fd: 11 Mon Jul 28 15:56:33.8709 2025 6 HTTP Connection from 192.168.0.235 Port 56920 with fd: 11 Mon Jul 28 15:56:33.8711 2025 7 Client: 192.168.0.235 requested desc.xml
@LITUATUI What happens when you just toggle this. This will write again the settings to FBC tuners.
I have been using that option in all frontends expect the first (from Frontend 2 to Frontend 8).
@LITUATUI I understand, but it is a way to try to bring the FBC tuners back to live, by rewriting the settings.
This rewrite, is done by toggling this option.
@LITUATUI I understand, but it is a way to try to bring the FBC tuners back to live, by rewriting the settings.
This rewrite, is done by toggling this option.
I see.
But am I using this setting correctly? "FBC Linked" enabled from FE 2 to FE 8?
Turning the "FBC Linked" on and off didn't bring the tuners back.
This problem also happens with MiniSatIP, it only works correctly when "mode 0" is used.
@Barracuda09 just out of curiosity, do you have any Enigma2 receiver with FBC tuner for testing?
I understand that you want things to work properly. But with my workaround, you won't have any problems. The tuners have never been used again, and channel searches also work. You don't have to change anything.