Help with IPTV and Continuity counter error

Manuel D. · 2014-05-23T17:11:19+00:00

Hi folks, I need help finding out how to fix a Continuity counter error when tuning IPTV, see an extract of the log and config files below. I am using at t...

mike garcia

Hi Manuel,

Did you fix the issue? I have the same problem and almost same scenario. Movistar Imagenio TV + Fiber 100MB/s + Raspberry Pi with XBMC+Tvheadend. I tried with the latest Raspbmc (repository "deb http://apt.tvheadend.org/stable wheezy main") and Openelec versions. Network path is all wired like this: 100/10MB WAN <-> 100MB ROUTER <-> 1GB SWITCH <-> 100MB Raspberry Pi.

Channels play smoothly from VLC from a Macbook air and from an old Intel PC, but nothing from tvheadend. On the other hand, I have a DVB-T usb capture connected to the Raspberry Pi which works fine in all the tvheadend versions I tested.

I read something that I could be related with RTP handling in the lastest versions of tvheadend.

Any clue will be highly appreciated and some beers and good tapas are guaranteed as reward :-)

Thanks,
Miguel

Phill Lavender

In short no.
I found an issue with the cat table which I've submitted a basic pull request to try to fix. No sure that it will fix the overall problem though. You're welcome to try to compile and try.
I also asked if Manuel could take a trace log and post it so we can see more clearly where the issue might be. You could do the same. It would certainly give people more to work off, since it can't be replicated unless you have iptv (which i no longer do) its a difficult one to fix without being able to see what's going on.
Thanks
Phill

Manuel D.

hi guys, sorry i cannot be more involved in my own issue... :-(
phill, one thing i did was to pick your patch and apply, i tested this new version for 10 minutes (sorry again i am out of time right now) but the issue was still there, the continuity counter error as well as the pixelation.
(i have to say that my problem with the pixelation at the bottom of the picture is not really that bad, only annoying sometimes)
i will follow your latest instructions as soon as i can...

mike garcia

Hi! Thanks for the answers. I am temporally fixing some issues with the NAT configuration since I got the IPTV vlan and routes, but it is my intention to try that new version but also prepare a spare Raspberry Pi with ssh open for the developers, so you can actually test it with IPTV. I will send the credentials to Phill by email when I get it ready.
BR

Phill Lavender

That would be great.
I remember when I had IPTV over ADSL that subscribing to more then one channel would just blow my WAN bandwidth and cause packets to drop, which obviously manifest as continuity errors. I have no idea how may channels a fibre connection can support simultaneously (HD. I'd guess is around 8Mbps so at least a couple should be possible without noticing packet issues ;-) )
Just need to be careful that other factors, like heavy network usage don't influence any testing at the time.

Phill

Phill Lavender

perexg has made some changes to the iptv code to use the udp multipacket interface.
You could compile and see if it has made any improvement to the continuity errors.
commit here: https://github.com/tvheadend/tvheadend/commit/7cc9ce7d728985fa8b168fb3f1c570098c868570 Phill

Manuel D.

hi phill,
thanks for keeping us up to date, i just compiled and tested, this time i got a segfault, no idea if this is related to last changed to the iptv code...
i still get the same continuity errors and i see the same pixelation at the bottom of the screen. i am attaching the current log with the segfault and two screenshots where i mark the pixelation zone. (no core file, it says it was dumped, but i cannot find it)

mike garcia

Hi!
Thanks a lot guys. I am having troubles to get a constant public ssh access to my tvheadend, but anyway I realized that my problem is behind than Manuel's, because I even can't see the image. So I am working on it. I am using the latest version from git, which is a little bit different than the one included in the raspberry repository and I am still getting familiar.
As soon as I reach Manuel, I will keep working on the ssh access (it looks stupid, but since I changed my openwrt router to the provider one, simple things don't work)
Good job fellas!

Phill Lavender

Guys,
This might be of use to you:
https://tvheadend.org/d/1916-spain-movistar-tv-imagenio-epg?r=12666#message-12666 Phill

mike garcia

Hi,

I finally arranged a raspberry pi with access:
ssh host: ask me
ssh user: root
ssh password: ask me
ssh port: 6022
tvheadend user: xbmc
tvheadend password: same as ssh password
tvheadend ports: 6981, 6982 (nat to 9981, 9982)
Git folder: /home/pi/git

IPTV channels: /home/pi/iptv-movistar.m3u

My email is gransmith11@hotmail.com, you can ask me for the public ip and ssh password. Anyone interested in testing tvheadend with Movistar Spain IPTV channels, is welcome.

Some testing channel:
#EXTINF:-1,[073] Discovery Channel

rtp://@239.0.0.21:8208

You can do whatever you want with this system (updates, reinstalling, etc), but not illegal stuff, of course :-o

Thanks!

Mike

mike garcia

If somebody is having problems with tvheadend and iptv, disable the firewall! Some raspbery distributions block multicast.

Now I got the "Continuity counter error" with a fresh git version. Phill is helping a lot, hopefully we will find a solution.

Thanks Phill!

Mike

Manuel D.

good luck folks, it seems to be tvheadend specific, other applications like vlc or the simple iptv plugin for xbmc can handle the stream without problem!

mike garcia

Which hardware do you use, Manuel? In my case I get the pixelation from the raspberry, either with tvheadend or vlc. However, from a laptop with wifi it plays and records fine.

Anyway, I will test simple iptv plugin.

Thanks!

Manuel D.

in my case performance should not be a problem, of course everything is possible, it is a xeon e5-1620 @ 3.60 ghz with 32 gb ecc ram and samsung ssd 840 pro disks, as well as other goodies... the same tvheadend is used for satellite and terrestrial hd streams without problem.

Manuel D.

Today my life changed! Movistar is finally OK! After a lot of trial and error with network tuning, and using VLC for watching Movistar TV, somehow I decided to play again with settings in Tvheadend. To make it short the change that made it was to set the URL using rtp instead of udp.
My bad? Maybe, but I tried this in the past without success, and I posted my settings with udp... A change/improvement in Tvheadend? Perhaps... Anyway I am happy I got finally IPTV the way it should be!

Manuel D.

i am using latest version (ubuntu unstable ppa), as of today it is 3.9.1884. each version during the past days has performed ok with the change from udp to rtp.

Paul M

possible unconnected, but I recently rebuild my TVH server and I was a bit lazy and didn't connect the secondary power input to the Turbosat DVB-S2 card (because it's got a modular PSU, and I didn't want to go and fetch the cable). TVH saw the card ok but had problems tuning in, and the signal would drop out..

the machine is called mcintyre, and I saw a flurry of errors like the one quoted ("Continuity counter error") as well as loads like this:

Oct 9 21:46:59 mcintyre tvheadend[4164]: linuxdvb: TurboSight TBS 6982SE DVB-S/S2 #1 : DVB-S #0 - retune nodata

I shut the machine down, fitted the power cable and it worked again. Quite a relief because unlike the old TVH box I replaced which was made from scrap, this one was purpose bought with actual money.

Shijune Khan

Phill Lavender wrote:
> perexg has made some changes to the iptv code to use the udp multipacket interface.
> You could compile and see if it has made any improvement to the continuity errors.
> commit here: https://github.com/tvheadend/tvheadend/commit/7cc9ce7d728985fa8b168fb3f1c570098c868570

> Phill

i just compiled manually latest version 3.9.722~g65a3c45, all went perfect with the compilation, but the error with iptv is still there, although i get the impression that it gets better with latest builds, but i cannot be sure because the cc errors are still there, but the picture seems to be less affected.
https://snaptube.cam/ when the picture takes the full screen it is not ok, but the problem is visible only in the last lines of the picture, so it is mostly acceptable, the problem gets bad when the picture takes only part of the screen and the screens shows black bars, here the error also happens in the the last lines, but then as a side effect it expands over the bottom black bar and it becomes annoying, it produces sometimes a sort of reflection of the picture in the black bar, which makes this effect worst, as it sort of distorts the whole picture.

« Previous Page