Bug #5937

uncorrected blocks, continuity errors with version 4.3-1896~gce0907705~bionic

Added by Daniel M. almost 2 years ago. Updated over 1 year ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Found in version:
Affected Versions:



I use tvheadend since years without problems with digital devices SAT>IP network tuners.

With the last unstable version 4.3-1896~gce0907705~bionic I get many uncorrected blocks, continuity errors and transport errors. Stream hangs for a second (kodi client oder vlc) and uncorrected erros raise for thousands errors and all is ok for some minutes. Then it starts again.

I have this problem exactly since I upgraded to version 4.3-1896~gce0907705~bionic.
I came from version 4.3-1857~g221c29b40~bionic. So I went back to this version and all works like a charm. After upgrading again to version 4.3-1896~gce0907705~bionic the problem is exactly the same now.

How can I help to find the error? There isn't really something in the log - just sometimes a transport error when the uncorrected bits raise extremly in the status tab. But thats what I already see in the status tab.

Whats the difference why versions <=4.3-1857 work without a problem but version 4.3-1896 is unusable for me?


rec.png (14.5 KB) rec.png Lorem Ipsum, 2020-10-27 01:01
221c29b40.png (48.6 KB) 221c29b40.png Lorem Ipsum, 2020-10-27 11:57
error2.png (90.2 KB) error2.png Lorem Ipsum, 2020-10-27 18:08
error.png (161 KB) error.png Lorem Ipsum, 2020-10-27 18:08



Updated by Flole Systems almost 2 years ago

You can help finding the error by going through the versions. i would pick a point between the bad and good version and start from there, if it's an issue pick a point between this and the good version and so on. Basically you're halving the search space every time until you find the commit that introduced it.


Updated by Vahram Mazlumyan almost 2 years ago

Hi guys

Please share deb file download link for 4.3-1857 jessie and bionic.



Updated by Flole Systems almost 2 years ago

Build instructions are in the Wiki, links to them. Just check out an older revision.


Updated by Anonymous almost 2 years ago

Maybe not everyone knows how to check out a specific version. It's not so easy
because the TVHeadend version numbering is different.

First of all: We need to find the unique identifier for every commit.

A) Short version only with git

1) clone the latest master : 
git clone

Then simply change to the tvheadend dir

cd tvheadend 
2) look into the commit history log:
git log

Now you will see all commits - every commit has a unique identifier

Lets choose e.g. a version which was valid on 1st Dec 2019. The last commit before was

"commit 221c29b40b1e53ae09a69d9458442dd4fea665f5
Author: Flole998 <>
Date: Sat Nov 23 17:11:58 2019 +0100

Fix #5782
3) So we checkout this version unsing the hash.
git checkout 221c29b40b1e53ae09a69d9458442dd4fea665f5
4) now build your specific version
configure && make 
5) stop, install and restart tvh. 
systemctl stop tvheadend.service && make install && systemctl start tvheadend.service

Step 5 may be different if your are not using systemctl to control init procdures.


Updated by saen acro almost 2 years ago

You can install without stop service it will autorestart


Updated by Anonymous almost 2 years ago

saen acro wrote:

You can install without stop service it will autorestart

Maybe - but systemd is bullshitish in many,many ways - so it is
better to explicitly start and stop it.


Updated by Rudi Schoors almost 2 years ago

I have the very same problem. However I'm using the linuxserver/tvheadend (latest) docker container which appears to be the same version mentioned, 4.3-1896~gce0907705.
Reading that version 4.3-1857~g221c29b40 did not have this problem I went searching previous versions of linuxserver/tvheadend in the docker hub and found: linuxserver/tvheadend:221c29b4-ls61 to be that exact version.
This version is running rather smooth with sometimes a very short glitch. With version 4.3-1896 the distortion took on average 15 seconds.

My setup is: Synology DS415+ with tvheadend on docker and OSCam, SAT>IP (Telestar digibit twin) and KODI on Android TV (Sony).


Updated by Lorem Ipsum over 1 year ago


I am in the same club. The funny thing I can observe is that the continuity errors in Status->Stream increases every second, whereas the log only lists from time to time a "Continuity counter error".

I can't give you an exact commit, but I can give you a time-range when that happened. Since I do a timeshift backup before I backup tvheadend it must have happened between June 7 2020 and September 19 2020. I also can observe this in my recordings

Currently I am using


Updated by Flole Systems over 1 year ago

The only possible cause that comes to my mind in that timeframe could be, please try reverting that one and test again.


Updated by Lorem Ipsum over 1 year ago

I cloned the current master and reverted the commit you mentioned

git revert 25e9c0600b6090335cebee2854bea1f9b2fecaa4

Never compiled tvheadend myself, but finally I managed it. Hard work to remove a few lines of code.

Unfortunately the errors still raise up in the same amount. Tomorrow I will try to reset to commit 749f519 and compile again...


Updated by Lorem Ipsum over 1 year ago

I have tested several commits now, even down to the already mentioned commit


The issue persists, which leads me to the conclusion, that it might not be directly correlated with tvheadend. My guess is that some other package, which was updated via apt might have lead to this. But how can we narrow this down?


Updated by Flole Systems over 1 year ago

Wait a second, you are using a FritzBox? Is that a 6591?


Updated by Lorem Ipsum over 1 year ago

6590, which ran stable for months (even with multiple streams hd+uhd), before I updated Ubuntu.


Updated by Lorem Ipsum over 1 year ago

Also I did not update the firmware. The only thing that should have changed was that I updated my tvheadend server with apt. Rolling back tvheadend did not solve the issue. I could only try to jump back to a backup I made with timeshift, to make 100% sure it has to do with the software of my server.


Updated by Flole Systems over 1 year ago

First you should check with Wireshark if the RTP Stream is complete or if (for some reason) the FritzBox is sending out an incomplete/broken stream. If on Wireshark it is fine (that means the traffic reached your server correctly) then you can start looking where it got dropped.


Updated by Lorem Ipsum over 1 year ago

Thank you for the guidance.

I installed Wireshark, and observed the RTP traffic going from my fritzbox to my tvheadend server, but I didn't see anything obvious. How can I detect if "the traffic reached my server correctly"?

In the meantime I made the observation that this phenomenon exclusively happens if the descambler is active (I use oscam for this). I have updated oscam now to the most recent version, but it hasn't changed anything. The oscam log also looks fine to me.


Updated by Flole Systems over 1 year ago

You start the capture, AFTER that you start the channel, wait for the errors, stop the channel, stop the capture. Click on Telephony -> RTP -> RTP Streams, wait for it to load, select your Stream, click on "Analyze" and a Window will pop up with the packets. You can then sort by status and it will show you that packets are missing (Status will be "wrong sequence number" for the following packet) and they will also be red. Also on the left it will show Lost count (on the left under the "Forward" Section).


Updated by Lorem Ipsum over 1 year ago

There it is :(

Any Idea except get other hardware?


Updated by Flole Systems over 1 year ago

You can go one packet up and see if the RTP Sequence Number Counter increased by one or if a RTP packet got lost. Then you know if it's a reception problem or network problem.

If you run a capture on the FritzBox itself you can see if the packets are already lost there or if they get lost in your network somewhere. Also with UHD Channels the FritzBox can cause issues.

Generally the FritzBox SAT>IP Server is not good in my opinion, getting a 6591 won't be better (at the moment).


Updated by Lorem Ipsum over 1 year ago

Thanks, the RTP sequence number of the previous packet is 43261, so it means the tvheadend server never receives the missing packages.

Yes the Fritzbox is not that good for multiple streams or uhd streams. But it had never that much problems with a single hd stream. There are firmware mods, which overcome this problems. For whatever reason this is not working anymore, I think its time for a new tuner.

Do you have any recommendations for an external quad DVB-C tuner that works good with tvheadend?


Updated by Flole Systems over 1 year ago

That would indicate a network problem rather than a FritzBox problem in my opinion. I'm not sure why the FritzBox would increase the sequence counter without ever sending out the packet. If I remember correctly the classic issue was not causing sequence errors in RTP, so the stream itself was perfectly fine and the FritzBox was skipping MPEG packets.

It could also be a driver issue on your server, if the Ethernet card or driver drops the packet it would show the exact same thing. Maybe a driver update was done in the meantime aswell.


Updated by Lorem Ipsum over 1 year ago

I am using an ethernet controller with RTL8125b chipset and ubuntu 18.04. I have read that this chipset is supported natively from kernel 5.4 upwards, which is available at Ubuntu 20.04. I will give a dist upgrade a try, because then this controller shouldn't need a separate driver.


Updated by Lorem Ipsum over 1 year ago

I think I found the reason in my case. The implementation of the RTL cards into the Linux Kernels was associated with a lot of changes in the drivers of these chipsets (Kernel 5.3+). In my case it was not solved by upgrading the kernel. Instead I found this ubuntu issue

and investigated the output of "ethtool -S enp3s0" and discovered a lot of "rx_missed"-Errors. The solution was to disable the "aspm"-settings of the pcie-controllers inside the Bios of my server. Since the RTL cards are common, it might be helpfull to someone else having issues like that.

What remains is that the counting for continuity errors in "Status->Streams" differs drastically from the ones logged in the tvheadend log. This appears only on some channels for me, such that I have a counter of continuity error in the order of 10000 in "Status->Streams", whereas no continuity error has been logged inside the tvheadend log (see also the screenshot in #5937-11). If I record such a channel in "Digital Video Recorder->Upcoming/Current Recording" I see 0 Errors and 0 Data Errors. What could be the reason for this deviation?


Updated by Flole Systems over 1 year ago

I assume you're seeing this for example on 370MHz?

The deviation can happen when there is a Continuity Error in a Stream other than Audio/Video/HbbTV/Teletext/Subtitle. For example on the CAID-Stream used for descrambling. If my guess which provider you're using is correct using is correct it is affected by that issue.


Updated by Lorem Ipsum over 1 year ago

Yes, you are perfectly right again, the affected frequencies belong all to the same provider for which an oscam descrambler is active (via dvbapi).

Is it something to worry about, because I see no negative consequences in my reordings? Or is there any way to fix this?


Updated by Lorem Ipsum over 1 year ago

I have enabled debugging and all errors show the same structure

tbl-csa: emm: 370MHz in Fritzbox: PID 1509 CC error 12 != 7

I have no clue what that means, but some comparison seems to fail, which leads to all these counted CC errors, but not in a interruption of the stream.


Updated by Flole Systems over 1 year ago

And it's failing because there are packets missing. As the keys are still received properly it's still working.

The only thing you can do to fix this is contact the provider, nobody else will be able to repair the broken datastream. You can't fix this in Tvheadend, it's not a Tvheadend issue. And they will probably not understand the issue, so good luck with that.


Updated by Flole Systems over 1 year ago

  • Status changed from New to Invalid

Closing this for now until someone else who reported problems is able to provide further debug information that shows it's a Tvheadend issue.


Updated by Lorem Ipsum over 1 year ago

OK, thank you for your helpfull support so far. Since I don't see any negative consequences of these errors, I will live with it. Maybe some day they are gone, when the provider changes its stream again.


Updated by Christian Völkel over 1 year ago

Since these CC errors have no negative consequences it would be very nice to have a workaround. Perhaps a checkbox in the network or mux to disable the counting.


Updated by Flole Systems over 1 year ago

You should contact your provider and ask them to fix their stream. These are continuity errors and they should be counted. If you don't want to see them in the Webinterface just disable that column.


Updated by Anonymous over 1 year ago

Flole Systems wrote:

Closing this for now until someone else who reported problems is able to provide further debug information that shows it's a Tvheadend issue.

Actually there should be no doubt that this is an tvh issue.

-> old tvh version: some CC glitches , some counted CC errors

Nothing changed !

-> new tvh version: some CC glitches, numerous counted CC errors.

The counter goes up and up and up....

I don't have a clue what this counter now counts: for sure not CC errors.


Updated by Flole Systems over 1 year ago

It counted CC errors in a CAID stream in those cases.... As already mentioned above (and there is even a screenshot of Wireshark showing the CC error). You still sure it's not counting CC errors?


Updated by Anonymous over 1 year ago

Flole Systems wrote:

It counted CC errors in a CAID stream in those cases.... As already mentioned above (and there is even a screenshot of Wireshark showing the CC error). You still sure it's not counting CC errors?

Besides the simple fact that "CC Error" is a well-defined terminus technicus is was already stated that there are major differences between logged and now counted CC errors. The WS Screenshot timestamp doesn't match the timestamps from the log - so it's difficult to decide what has been counted.

Unfortunatly it seems that the meaning of the counter has changed whithout adaptation of the release numbers. That's really bad, because real CC Erors are often correlated with attenuation issues. Environment debugging is getting more and more difficult.


Updated by Flole Systems over 1 year ago

The Wireshark screenshot shows one of numerous examples. I have checked it on my Installation and confirmed the issue. It is also logged if the appropriate logging is enabled, so that claim is also not true (there is also a line from the logs that shows it above).

The meaning of the counter did not change (it indicates that the mpeg continuity counter was not continuos), if a provider provides a faulty signal this will happen. You should then report an issue to your provider because they are violating the specification.

There is no way to distinguish missing packets that were dropped at the provider from missing packets caused by bad signal.


Updated by J Smith over 1 year ago

I apologise if this adds 'noise' without anything especially technical backing it up - however, I built a stripped down version of TVheadend and it seems to have gone a long way to improving things for me.

My setup is a Sat>IP client, I then export the M3u from TVheadend to something else. So I have very basic needs, TVheadend is essentially a UI/frontend for my Sat>IP server, it does no recording, transcoding, etc.. When I built with the below options, I no longer see the spikes of uncorrected errors.

AUTOBUILD_CONFIGURE_EXTRA="--python=/usr/bin/python3 --disable-pcloud_cache --disable-ddci --disable-tvhcsa --disable-epoll --disable-ffmpeg_static --disable-libav --disable-libx264_static --enable-libx264 --disable-libx265_static --enable-libx265 --disable-libvpx_static --disable-libtheora_static --disable-libvorbis_static --disable-libfdkaac_static --disable-libopus_static --disable-nvenc --disable-hdhomerun_static --disable-hdhomerun_client --disable-cardclient --disable-cwc --disable-cccam --disable-capmt --disable-constcw --disable-linuxdvb --disable-satip_server --disable-iptv --disable-dvbscan --disable-timeshift --disable-trace --disable-avahi --disable-inotify --disable-ccache  --disable-pie" ./ -t focal-amd64

I don't truly understand all the ramifications of the above, but what it does seem to do, is stop the large spikes of uncorrected errors. I now perhaps see 1 instance of minor pixelation per evening, compared to multiple and/or the odd complete stall. I did also experiment with the cpu frequency scaling I saw in another bug report, whilst it improved things, did not help as much as the above. Would be interested to know if anyone else sees the same.

I've been running this for almost a week now and the improvement is definitely significant in my use case. I now perhaps get 20-30 uncorrected per 1 hour TV programme and maybe 2-10 continuity errors - rather than 10's of thousands of the former.

I guess the next step for me is to start adding options back in again, to try to determine the case.

Also available in: Atom PDF