Tvheadend

Get the same behavior here after I updated to latest master on Ubuntu 14.04 (commit da3d9ecb48ab162faf0d7136eed25e7bb4cef92a)

For the most part the channels works, but suddenly a random channel can start to break up (blocking) and it usually ends with a total freeze. I also though it had something to do with idle scanning, but tvheadend can idle scan on 3 inputs while I am watching on the 4th without problems for a long time before it happens, I haven't tried to disable idle scanning to see if makes any difference though. At the moment I am not sure how to reproduce the issue, and I haven't enabled logging.

2014-11-22 21:54:18.512 [ DEBUG]:psi: PID 0010 CC error 11 != 10
2014-11-22 21:54:19.344 [ DEBUG]:psi: PID 0012 CC error 0 != 15
2014-11-22 21:54:19.403 [ DEBUG]:psi: PID 0000 CC error 14 != 13
2014-11-22 21:54:19.627 [ DEBUG]:psi: PID 0012 CC error 2 != 1
2014-11-22 21:54:20.108 [ DEBUG]:psi: PID 0012 CC error 6 != 4
2014-11-22 21:54:22.112 [ DEBUG]:psi: PID 0012 CC error 12 != 10
2014-11-22 21:54:22.183 [ DEBUG]:psi: PID 0001 CC error 11 != 10
2014-11-22 21:54:22.779 [ DEBUG]:psi: PID 08A2 CC error 14 != 13
2014-11-22 21:54:23.241 [ DEBUG]:psi: PID 0012 CC error 7 != 5
2014-11-22 21:54:23.376 [ DEBUG]:psi: PID 0001 CC error 3 != 2

same here

Same problem here.

I think the problem is only on channel that have subtitles to choose. Channel without subtitles works OK.

Still problems on commit bb07ead99b104d5e5007d2f5271062bdc21f1940

I don't think that I have any channels without subtitles, so I can not verify if this only happens on channels with subtitles. At least all are listed with at least 1 subtitle stream.

Was able to drastically reduce the number of CC errors, but not exactly sure why:

Here what I did:
(1) Deinstalled all test packages on my Synology that I installed previously but eventually did not use anymore (ffmpeg, filebot, Java SE, ...)
(2) Went into the TVH GUI and deactivated the UK: Freeview and UK: Freesat OTA grabbers (only left the EIT: DVB grabber activated)
(3) Stopped TVH and the VideoStation
(4) Rebooted the NAS
(5) Only started TVH keeping VideoStation switched off

Since then my tvheadend.log file grows substantially less rapidly. No crash since (2 days), but could be "luck". There are still errors in the log-file though with basically two "classes" of messages:

2014-11-22 13:56:34.998 [ DEBUG]:service: DMAX si 0x894ce08 SAT>IP DVB-S Tuner #4 (192.168.1.30) weight 0 prio 1 error 0
2014-11-22 13:56:34.998 [ DEBUG]:service: DMAX si 0x91a1888 SAT>IP DVB-S Tuner #3 (192.168.1.30) weight 0 prio 1 error 0
2014-11-22 13:56:34.998 [ DEBUG]:service: DMAX si 0x95987c8 SAT>IP DVB-S Tuner #2 (192.168.1.30) weight 0 prio 1 error 0
2014-11-22 13:56:34.998 [ DEBUG]:service: DMAX si 0x884c160 SAT>IP DVB-S Tuner #1 (192.168.1.30) weight 0 prio 1 error 0

I assume (but don't know) these are not error messages but just appear when I switch the channel. Not sure why I receive a message for each tuner though.

More interesting are the CC errors. There are individual ones when I watch some channels, but I get whole clusters at 2:04 and 14:04 every day. Example for a complete block:

2014-11-23 02:04:02.896 [ DEBUG]:psi: PID 0012 CC error 0 != 7
2014-11-23 02:04:13.007 [ DEBUG]:psi: PID 0012 CC error 2 != 1
2014-11-23 02:04:13.007 [ DEBUG]:psi: PID 0012 CC error 11 != 3
2014-11-23 02:04:36.709 [ DEBUG]:psi: PID 0012 CC error 10 != 15
2014-11-23 02:04:36.709 [ DEBUG]:psi: PID 0012 CC error 9 != 14
2014-11-23 02:04:36.709 [ DEBUG]:psi: PID 0011 CC error 5 != 4
2014-11-23 02:04:36.709 [ DEBUG]:psi: PID 0011 CC error 5 != 4
2014-11-23 02:11:25.698 [ DEBUG]:psi: PID 0012 CC error 8 != 5
2014-11-23 02:11:25.698 [ DEBUG]:psi: PID 0012 CC error 12 != 10
2014-11-23 02:11:51.666 [ DEBUG]:psi: PID 0012 CC error 4 != 7
2014-11-23 02:15:56.964 [ DEBUG]:psi: PID 0012 CC error 2 != 14
2014-11-23 02:15:56.964 [ DEBUG]:psi: PID 0012 CC error 9 != 3
2014-11-23 02:16:12.778 [ DEBUG]:psi: PID 0012 CC error 6 != 14
2014-11-23 02:16:12.778 [ DEBUG]:psi: PID 0012 CC error 2 != 7

The occurence of these blocks coincides with when cron starts the EPG OTA grabbing in TVH (am using the default setting).

I actually think the cc errors signal an epggrab issue now. However, no clue whatsoever, whether this has something to do with the crashes I have seen.

Compiling tvheadend with --disable-libav seems to solve the issue on my system.

To be completely sure I will have to run it for a longer period, but at the moment i looks good.

I have the same problem with the cc errors.
Version 3.9.1987~gc053acd is working fine. Have tried the latest at the moment from the trunk (3.9.2201~g6391e7b), but the same errors occur.
In my case, the issue occurs on a channel that has 2 subs available (like mentioned earlier). On a channel with a single sub available, I do not see these errors.
Compiling without libav enabled does not make any difference for me.

System is running Ubuntu 14.04 with kernel 3.13 and Digital Devices DVB-S cards.

If you disable both subtitle types in the Config / Stream / Subtitle Stream Filters - use Stream Type DVBSUB,TEXTSUB and Action IGNORE (+ enabled) - all other fields should be empty or zero, do things work correctly ?

Thanks for looking into this, Jaroslav,

Did as you proposed and created the filter ignoring both SUB types. Unfortunately, the cc errors persist. Were triggered by the OTA EPG grabber again at 02:04 last night.

The good thing is that I have not experienced any crashes since my posting 10 days ago and I'm using the TV daily.

Please let me know if I can test anything else.

I am back to square one too, as other have said the disable-libav does not work, it seems like it made the errors less frequent. But compiling with libav on a updated git version seems also to make the problem less frequent. I am now trying to ignore SUB types, but have not been watching enough to make any conclusion.

The ignore SUB type does not work at my end either.

I am getting this when the errors happens

Dec 8 18:34:05 pvr tvheadend⁸⁴⁹: mpegts: 10778H in Canal Digital - tuning on Tuner 3
Dec 8 18:34:05 pvr tvheadend⁸⁴⁹: subscription: 7FBC: "scan" subscribing to mux, weight: 1, adapter: "Tuner 3", network: "Canal Digital", mux: "10778H", hostname: "<N/A>", username: "<N/A>", client: "<N/A>"
Dec 8 18:34:05 pvr tvheadend⁸⁴⁹: mpegts: 10903V in Canal Digital - tuning on Tuner 2
Dec 8 18:34:05 pvr tvheadend⁸⁴⁹: subscription: 7FBD: "scan" subscribing to mux, weight: 1, adapter: "Tuner 2", network: "Canal Digital", mux: "10903V", hostname: "<N/A>", username: "<N/A>", client: "<N/A>"
Dec 8 18:34:05 pvr tvheadend⁸⁴⁹: mpegts: 10872H in Canal Digital - tuning on Tuner 0
Dec 8 18:34:05 pvr tvheadend⁸⁴⁹: subscription: 7FBE: "scan" subscribing to mux, weight: 1, adapter: "Tuner 0", network: "Canal Digital", mux: "10872H", hostname: "<N/A>", username: "<N/A>", client: "<N/A>"
Dec 8 18:34:06 pvr tvheadend⁸⁴⁹: eit: invalid checksum (len 310, errors 16)
Dec 8 18:34:07 pvr tvheadend⁸⁴⁹: bat: invalid checksum (len 444, errors 1)
Dec 8 18:34:07 pvr tvheadend⁸⁴⁹: sdt: invalid checksum (len 444, errors 1)
Dec 8 18:34:10 pvr tvheadend⁸⁴⁹: pmt: invalid checksum (len 94, errors 1)
Dec 8 18:34:11 pvr tvheadend⁸⁴⁹: mpegts: 10778H in Canal Digital scan complete
Dec 8 18:34:11 pvr tvheadend⁸⁴⁹: subscription: 7FBC: "scan" unsubscribing
Dec 8 18:34:12 pvr tvheadend⁸⁴⁹: mpegts: 10903V in Canal Digital scan complete
Dec 8 18:34:12 pvr tvheadend⁸⁴⁹: subscription: 7FBD: "scan" unsubscribing
Dec 8 18:34:12 pvr tvheadend⁸⁴⁹: mpegts: 10872H in Canal Digital scan complete
Dec 8 18:34:12 pvr tvheadend⁸⁴⁹: subscription: 7FBE: "scan" unsubscribing

Note that the invalid checksum WARNINGS may appear at the stream start (and they might be ok - sometimes the tuners requires little time to stabilize and some pieces of MPEG-TS tables might be missing). But they should not occur after first 10-20 seconds (during standard streaming). I would ignore them during the scan task completely (unless you see hundreds in number). If there are no errors in the video/audio streams, just ignore it..

The whole picture get distorted, blocking and sometimes it even freezes, but it's for a short moment, then the picture is perfect for a long time until it happens again. I have not found any system in the interval between the errors, it sometimes seems to be corresponding with when a new idle scan happens on unused tuners, but I have tried to turn of idle scan without any luck.

I have good signal SNR 95-100%, signal strength about 72-76%, so I do not think it has anything to do with week signal. It happen after a git update, so I should probably try to roll back and try to find the commit where it happen. I can see that Hugo mention a commit that works for him, I will see if that also works for me.

I think I solved the issue for my configuration, I got the TBS6985 with 4 tuners, and it turns out to be a physical problem. Before, I had all cables from the dish going straight into the tv server/tuner card, but as I am completing the room where the TV server will be located I have hidden the cables in the walls and installed two boxes with two sat output each.

It seems like the these boxes are the problem. If I disables the even numbered tuners so only one of the tuners on each box is enabled it works perfectly. So for me it seems like all the idle tuning generate to much noise in the sat boxes, for now I will only enable two of the tuners until I have time to check the connections.

if you have activated any power saving features on the adapters then try disabling them