Project

General

Profile

Bug #1534

Continuity Counter Error on switching channels

Added by tris tee almost 9 years ago. Updated almost 9 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
Category:
DVB
Target version:
-
Start date:
2013-01-13
Due date:
% Done:

0%

Estimated time:
Found in version:
3.3.328
Affected Versions:

Description

Hello,

For some time now i`m experience massive "Transport error indicator, Continuity counter error." on switching channels in XBMC (tvheadend client).

Im now on Tvheadend 3.3.328~g60371b0

I have tried the tvheadend server 3.2 and 3.3 on ubuntu 12.04 and openelec 2.99.1 (3.0 RC 1).

On each operating system and each tvheadend version, the same result.

My tvheadend server log looks always like this:
[INFO]:subscription: "127.0.0.1 [ xbmc | XBMC Media Center ]" subscribing on "BR Nord HD", weight: 150, adapter: "Sundtek DVB-S/S2 (III) (0/0)", network: "ASTRA 1", mux: "ASTRA 1: 11,582,250 kHz Horizontal (Default (Port 0, Universal LNB))", provider: "ARD", service: "BR Nord HD", quality: 100
[WARNING]:TS: Sundtek DVB-S/S2 (III) (0/0)/ASTRA 1: 11,582,250 kHz Horizontal (Default (Port 0, Universal LNB))/BR Nord HD: H264 #5201: Continuity counter error
[WARNING]:TS: Sundtek DVB-S/S2 (III) (0/0)/ASTRA 1: 11,582,250 kHz Horizontal (Default (Port 0, Universal LNB))/BR Nord HD: TELETEXT
#5204: Continuity counter error
[WARNING]:TS: Sundtek DVB-S/S2 (III) (0/0)/ASTRA 1: 11,582,250 kHz Horizontal (Default (Port 0, Universal LNB))/BR Nord HD: MPEG2AUDIO #5203: Continuity counter error
[WARNING]:TS: Sundtek DVB-S/S2 (III) (0/0)/ASTRA 1: 11,582,250 kHz Horizontal (Default (Port 0, Universal LNB))/BR Nord HD: AC3
#5206: Continuity counter error
[WARNING]:TS: Sundtek DVB-S/S2 (III) (0/0)/ASTRA 1: 11,582,250 kHz Horizontal (Default (Port 0, Universal LNB))/BR Nord HD: MPEG2AUDIO #5202: Continuity counter error
[WARNING]:TS: Sundtek DVB-S/S2 (III) (0/0)/ASTRA 1: 11,582,250 kHz Horizontal (Default (Port 0, Universal LNB))/BR Nord HD: MPEG2AUDIO
#5202: Continuity counter error, 15 duplicate log lines suppressed
[WARNING]:TS: Sundtek DVB-S/S2 (III) (0/0)/ASTRA 1: 11,582,250 kHz Horizontal (Default (Port 0, Universal LNB))/BR Nord HD: H264 #5201: Continuity counter error, 946 duplicate log lines suppressed
[WARNING]:TS: Sundtek DVB-S/S2 (III) (0/0)/ASTRA 1: 11,582,250 kHz Horizontal (Default (Port 0, Universal LNB))/BR Nord HD: TELETEXT
#5204: Continuity counter error, 22 duplicate log lines suppressed
[WARNING]:TS: Sundtek DVB-S/S2 (III) (0/0)/ASTRA 1: 11,582,250 kHz Horizontal (Default (Port 0, Universal LNB))/BR Nord HD: AC3 #5206: Continuity counter error, 38 duplicate log lines suppressed
[WARNING]:TS: Sundtek DVB-S/S2 (III) (0/0)/ASTRA 1: 11,582,250 kHz Horizontal (Default (Port 0, Universal LNB))/BR Nord HD: MPEG2AUDIO
#5203: Continuity counter error, 14 duplicate log lines suppressed
[WARNING]:TS: Sundtek DVB-S/S2 (III) (0/0)/ASTRA 1: 11,582,250 kHz Horizontal (Default (Port 0, Universal LNB))/BR Nord HD: Transport error indicator

My satellite dish is perfectly oriented. I also replaced all coax cable with a new 135db and high quality plugs.
I bought even a new Sharp LNB.
I have a Sundtek Sky Ultimate Version 5 (Newest driver 9.January).
91% Signal reception in tvheadend.

I have already contacted the support sundtek about this issue.
They studied my system and hardware configuration in detail, and came to the following conclusion:

The hardware (stick,cable,lnb whatever) needs more time to change the mux/frequenz as tvheadend provides...
If i add a timeout of 1,8 seconds to the driver of the stick, all "Continuity counter errorĀ“s" are gone.
I can do this on the sundtek driver with this command: mediaclient --ts-settle-timeout=1800 -d /dev/dvb/adapter0/frontend0

however, it is not a consistent solution.

Shouldn`t Tvheadend recognize that the hardware is not ready yet?
If the error occurs (as described above) it comes to sporadic errors in xbmc:
-livetv freeze
-could not descramble on encrypted channels
-artifacts

Perhaps you can improve this behavior with "Transport error indicator, Continuity counter error."

regards

firsttris

History

#2

Updated by tris tee almost 9 years ago

Message from Sundtek:

"As we have found your LNB needs some time to setup the constellation.

Basically, it's a problem of tvheadend.

You can set a timout for the video-transfer after the reconfiguration of the constellation (22khz tone on / off, polarization horizontal / vertical)"

http://support.sundtek.com/index.php/topic,1048.msg7365.html#msg7365

#3

Updated by Adam Sutton almost 9 years ago

  • Category set to DVB
  • Status changed from New to Need feedback

I'm not really sure why this is considered a TVHeadend issue, if the driver decides to start streaming data before its actually ready to do so (e.g. all synths etc... are properly locked) then that's entirely out of TVH's control.

If a hardware specific solution exists to overcome this problem then that would seem the best solution. However we are having a quick discussion to see whether its worthwhile adding a generic option to TVH (though I'm personally not convinced of the benefit).

Adam

#4

Updated by Markus Bonet almost 9 years ago

I am experiencing such behaviour as well with my Tevii S480 and the Sky Xpress DUAL cards installed.
Maybe it's totally unrelated, but I really would like to do something about it. So at least I clearly promote a generic option!

#5

Updated by Mark Clarkstone almost 9 years ago

Markus Bonet wrote:

I am experiencing such behaviour as well with my Tevii S480 and the Sky Xpress DUAL cards installed.
Maybe it's totally unrelated, but I really would like to do something about it. So at least I clearly promote a generic option!

I can confirm I'm having the same issues with both my Tevii S471 & the Technisat SkyStar HD USB, I believe it to be LNB related.

#6

Updated by Adam Sutton almost 9 years ago

I was about to add that I have spoken to a guy from sundtek and the believe is this is an LNB issue, i.e. the LNB is taking a long time to accurately lock its frequency and this results in bad data into TVH for a period of time.

Personally I'm not really sure what you could/would hope to achieve by modding TVH for this. You could provide a user configurable (default 0) artificial delay on every channel zap (to allow it time to settle) but most people would never use this since they want quick zap times not artificially slowed ones.

And to the best of my knowledge all this currently does is result in a period of BAD input that will cause distortion on the screen (when it happens, which may not be everytime?) whereas adding this option would ensure that EVERY channel zap (or at least every freq re-tune) would incur a delay even if its not necessary.

Adam

#7

Updated by tris tee almost 9 years ago

Adam Sutton wrote:

I was about to add that I have spoken to a guy from sundtek and the believe is this is an LNB issue, i.e. the LNB is taking a long time to accurately lock its frequency and this results in bad data into TVH for a period of time.

Personally I'm not really sure what you could/would hope to achieve by modding TVH for this. You could provide a user configurable (default 0) artificial delay on every channel zap (to allow it time to settle) but most people would never use this since they want quick zap times not artificially slowed ones.

And to the best of my knowledge all this currently does is result in a period of BAD input that will cause distortion on the screen (when it happens, which may not be everytime?) whereas adding this option would ensure that EVERY channel zap (or at least every freq re-tune) would incur a delay even if its not necessary.

Adam

is it possible to add something like a "dynamic delay"?

an option for video-transfer timeout as long as "Continuity counter error" happens.

regards

Tristan

#8

Updated by tris tee almost 9 years ago

This Problem triggers sporadic errors in xbmc:
-livetv freeze
-could not descramble on encrypted channels
-artifacts

ps: the delay for the sundtek driver works quite well. it only adds a timeout when you change the frequency.

#9

Updated by tris tee almost 9 years ago

I have tried at least 5 different high quality LNB's.

All LNB's produce the same result.

But, the cable is very long 15-20meters - maybe that's the reason.

My Question:
Someone has to check if the tuner is ready to steam a channel?!
> the driver does not verify this?
> tvheadend does not verify this?

#10

Updated by Adam Sutton almost 9 years ago

No, Tvheadend assumes that if the tuner IS streaming data then its ready. If its not because its not properly locked that is the tuners mistake not TVHs. There is a callback that indicates the tuning has been completed and I will take a look at providing a patch for you guys to test.

However my hunch is this will be reported pretty quickly as the tuner also thinks its locked (or it wouldn't be sending data) and its a problem with the LNB not properly settling and causing the input to move in and out of being good. But that's just supposition at this stage.

Adam

#11

Updated by Markus Bonet almost 9 years ago

What I experienced in the past as well (but this can be related to in some cases DECT disturbing the tuner as well): tvheadend would send wrong ECMs to my HD02 card resulting in a hanging card, so I would need to reset the reader. Because the CA data in the stream is corrupted as well.

This is only heading in the same direction, and I want to clearify that it can be totally unrelated.

At least I have these Cont Counter errors as well.

So I would be happy to do some tests.

#12

Updated by Adam Sutton almost 9 years ago

  • Status changed from Need feedback to Rejected

OK, I'm going to close this. I do not believe the issue is TVHs per se. The problem is a poor/slow LNB results in the tuner passing bad data to TVH. It does its best to process this and I would expect it to recover, but I think the issue here is that the client (XBMC) is giving up before that happens?

The suggestion of an extra delay could solve the problem, though its not a nice solution. However if that is what people think is necessary to solve this and would prefer to see it handled in TVH rather than the existing workaround of configuring the adapter. Then can you submit a Feature Request, though bare in mind it probably won't get high priority from the core team so you probably need to find someone to look at it.

If you don't agree with this and believe there is still a genuine bug, then please shout.

Adam

#13

Updated by Markus Bonet almost 9 years ago

What about your previous suggestion?

"There is a callback that indicates the tuning has been completed and I will take a look at providing a patch for you guys to test."

#14

Updated by Adam Sutton almost 9 years ago

I have looked into it and spoken to a few people and its not going to be much use in this scenario. The problem is that ioctl() simply reports that the tuner believes it has successfully tuned. If it had not then it wouldn't be streaming data. Therefore it won't gain much.

From what I can tell there is simply no reliable way to be sure that the LNB is happy, since the tuner believes it has tuned, but presumably the LNB lock is not stable.

There is already an unused function that checks the status, you could try enabling this and see what it reports. Look for the call to check_frontend() in src/dvb/dvb_fe.c.

Adam

#15

Updated by Wojciech Myrda almost 9 years ago

I wrote a quite a long post just to learn that it asked me login again and it was gone...

Anyways here are few of those points...

1) Even if it not a bug in the code itself the issue still exists what number of bugs in the redmine shows https://www.lonelycoder.com/redmine/projects/tvheadend/search?utf8=%E2%9C%93&q=Continuity+Error which until resolved will likely hunt the redmine and reappear time and again. Way I see it is just like Linux kernel has workaround for bugs in the hardware same way TVH might need workaround for the bug in the driver/s.

2) XBMC has implemented delay feature under (I am writing from memory) "TV Settings -> Playback -> Delay" which might be set from 0-10000ms and defaults to 250ms. This 250ms solved the issue for me while using XBMC as the client, but still using it TVH by itself the issue is still there. Therefore borrowing the code from there might be a good idea.

3) Is it possible that Continuity Counter Error is likely appear mostly for those not connected directly through LNB but using DiseqC as well and that diseqc reports back something that the the tuner driver might take as report of being fully tuned even as LNB just started actually tuning?

I know it is hard to work on something that one does not experiences himself, but I believe this could solve for issue for many more as not everyone reports bugs they find and hopefully borrowing code from XBMC will not be as hard...

Thanks,
Wojciech

#16

Updated by Adam Sutton almost 9 years ago

1. We will always get questions about CC and transport errors, but generally speaking they are benign. I get them very occasionally and do see 1 or 2 on most channel zaps these days. They are rarely fatal. However you're talking about a very specific scenario that is unusual (in my limited experience). Because what appears to happen is the LNB is slow to lock, however while its homing in on the signal there appears to be a point that the tuner believes lock is achieved and so begins streaming. But since the lock in the LNB is not perfect the signal is poor for a while. Now in most cases I would expect an upstream client to be able to handle that. Since ultimately the only difference between now and then would be that TVH may filter some frames that contain artefacts. Though maybe I'm missing something, I haven't followed the entire thread.

And as for workarounds for hardware bugs, we already have plenty ;) The problem is we need to balance this with the effect such workarounds might have on 99% of users. If the option is to provide a configurable delay period, it might be possible, but it needs submitting as a feature request. And since this issue affects a limited number of users (again based on my experience) its not likely to be a priority for the core team. So you will probably have to investigate the mods yourselves and/or use any existing workarounds. Sorry I'm not trying to fob you off, just stating a fact of availability etc.

2. I'm probably confusing the settings, but I thought that was just a delay on XBMC sending the request to tune the channel (i.e. while scrolling through channels you get the INFO for the channel then N ms later it actually requests the channel from the backend). But its a while since I checked my XBMC settings, so it might be something new in the buffering.

3. This may or may not be related to disqec, its really not clear. But even if you were running through a switch a) not all switches support diseqc version that includes responses and b) for that reason TVH currently doesn't bother to query them, its hit and hope (since its most generic at this stage).

Adam

Also available in: Atom PDF