Tvheadend

Some people have this problem: http://openelec.tv/forum/134-usage/48831-update-tvheadend-backend

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

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!

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.

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

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

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.

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?

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

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.

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."

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

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

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