Tvheadend

Could you retest with latest ? v3.9-2719-ga1844b8

Still same problem on 3.9.2747

I cannot reproduce this here. Do you have some logs ? If the subcriptions stalls in the "testing", something is bad, because the timeout should catch them.

I have the same problem here on 3.9.2765. I recognized it a few weeks ago as my powersaving method checks the state of active subscriptions. And right now I do have two "testing" epggrab processes again.

I will restart the server and try to catch a debug log.

Which subscriptions (which muxes) were in the failing state ?

Should there have been any? Don't remember having any failed state subs/muxes and right now I don't see any. When epggrab is stalled in "testing" there is also no entry in the "service" column.

Interesting thing is, that is doesn't seem to be everytime epg scans are running. A few minutes ago I restarted tvheadend and the processes for epggrab (got two sundteck dvb-c) were all fine and after 5 minutes gone from the active subscription page. Another restart and the problem is there again, one process hanging with "testing" and no service entry.

What can I do to provide more information for debug?

Maybe of interest: I restarted the tvheadend processes again and again... when the epggrab process is stalled it is always right at the beginning of a new started tvheadend. Then I got an epggrab while tvheadend is running its scan processes. This epggrab process will apparently hang and won't be killed. I tried it for about 20 times now, always the same... when everything is fine, tvheadend is starting its scan processes and epggrab is running after the scan. When it hangs, its starting both right from the beginning.

Do you see any 'service instance is bad, reason:' warnings in the log ? I assume that you're using the latest tvh code.

negative. not in the normal log. do I have to trace for this?

does this also happen if you disable initial scan and idle scanning?

I added to the recent tvh code the 'Id' field in the subscription tab which can help to identify the stale point using the log. Could you reproduce the issue and enable the trace log using --trace subscription,service,mpegts ? Also, report back the stalled subscriptions in the webui.

Jaroslav Kysela wrote:

I added to the recent tvh code the 'Id' field in the subscription tab which can help to identify the stale point using the log. Could you reproduce the issue and enable the trace log using --trace subscription,service,mpegts ? Also, report back the stalled subscriptions in the webui.

This is what dmesg says about this problem:

[8183667.476214] usb 2-1: DVB: adapter 4 frontend 0 frequency 0 out of range (174000000..862000000)

Rafal Kupiec wrote:

Jaroslav Kysela wrote:

I added to the recent tvh code the 'Id' field in the subscription tab which can help to identify the stale point using the log. Could you reproduce the issue and enable the trace log using --trace subscription,service,mpegts ? Also, report back the stalled subscriptions in the webui.

This is what dmesg says about this problem:

[8183667.476214] usb 2-1: DVB: adapter 4 frontend 0 frequency 0 out of range (174000000..862000000)

Irrelevant.