get_pmt read error

[splinux]

Hello,

I use vdr-plugin-dvbapi togheter with yavdr 0.5.0 and oscam svn (now rev 7943) It is working correctly, except sometimes (often) when I zap from channel to channel i get following errors. Sometimes it is after 1 zap, sometimes 10 and not always on the same channels.

Nov 28 08:25:51 pccave vdr: [6895] DVBAPI-Error: get_pmt: read_sections: read error: Connection timed out

Nov 28 08:25:51 pccave vdr: [6895] DVBAPI-Error: Error obtaining PMT data, returning

I then need to reboot vdr. Don't know if it is dvbapi or oscam related, but can't find the solution. Any idea what could be the reason of the read error. Thanks SP

[manio]

Hi! This error is when filters on dvb receiver doesn't provide PMT data in a specified time (currently 2 seconds). It may be a lock issue (or even diseqc), or some driver problem. Can you try if you also have this problems on rev: a98ff1e801? You can also try to increase the time in CAPMT.h, DEMUX_FILTER_TIMEOUT line. I don't know why you have to restart vdr. It should just work when you switch channel again, or to some other channel, no need to restart vdr.

ps. what card/driver/frontend you're using?

[splinux]

Hello, Thanks for your answer. I tried the rev you gave. I don't have the indicate error anymore but after some times I get "no free space for new SID" With the previous version I had to restart vdr because I had always "channel not available" thanks, I use a hvr4000 card with cx2388x version 0.0.9 driver frontend is conexant cx24116/cx24118

thanks

sp

[splinux]

Hello, Don't know if it can help, but it seems that the error "no free space for new SID" only occurs when I am zapping channels with the plugin xvdr (client is openelec) and not directly on the console or while streaming in http (client is a xstreamer sidewinder). Thanks, SP

[manio]

Thank you for your input but i still doesn't know why you have those timeouts. What if you increase the timeout in the CAPMT.h? And about "no free space for new SID": it could occur when the dvbapi plugin is not properly informed by vdr about stopping streaming of a channels. It was a problem in xvdr but a long time ago (introduced in 228b18c112 and fixed in b62ccbdd8c6). Maybe a vdr problem? what version you're using?

[aleis]

For me, having had the exactly same issues and Error-Logs on a Zotac ZBOX with Atom CPU, the above mentioned commit solved the problems. Increasing the timeout in CAPMT.h wasn't that helpful, because the same error occured, when switching to a channel, that isn't decodable even though it worked for suscribed channels.

[manio]

@aleis Some questions:

1. what vdr version you're using
2. i assume you have problems on master and it is ok when you checkout a98ff1e, right?
3. do you have this problems every time you zap or maybe only from time to time?

[aleis]

1. I am using version 1.7.27, https://launchpad.net/~yavdr/+archive/stable-vdr/+build/3859309 It's the vdr Package coming by default with yavdr 0.5
2. i have these problems on master, so i patched your changes of a98ff1e into the cloned master und buildt a working deb Package of it
3. with the unmodified master branch i have the same symptoms as splinux, means, sometimes it's no problem switching channels multiple times, but i can be sure that it comes to the posted Errors. It get the Eroor by the way always and reproducible by switching to an undecodable channel in my channellist.

I also encountered these problems at a friend of mine, nearly same hardware, exactly the same version of vdr.

As I said, only increasing the DEMUX_FILTER_TIMEOUT (without usage of the patch) improves the situation on decodable channels but by accidentally switching to a non decodable one i get the erorrs again and can't switch back to any scrambled channel.

If you want to have logs of both situations you have to be a little more patient, probably I could post them tomorrow.

[manio]

Thanks for the info. I am wondering if the problem exists on more recent vdr versions, eg on 1.7.36. Can you mail me? - i have some details to discuss.

[aleis]

Hi, it seems updating to vdr 1.7.33 solved the problem, no idea why, but now it does what it's meant to be done for at least three days with current master. I have another vdr with 1.7.27, that isn't reachable for me atm, but if you wish to, i would test the plugin with it asap.

[manio]

Thanks for the info.

@splinux Can you also confirm it?

[aleis]

Oddly enough, the Error still occurs, but it seems without consequences,

Jan 29 16:21:31 vdr-zotac vdr: [2989] initializing plugin: dvbapi (1.0.4): DVBAPI type SOFTCAM Jan 29 16:22:00 vdr-zotac vdr: [2989] DVBAPI-Error: get_pmt: read_sections: read error: Die Wartezeit für die Verbindung ist abgelaufen Jan 29 16:22:00 vdr-zotac vdr: [2989] DVBAPI-Error: Error obtaining PMT data, returning

Even at the time of and after the Error Message all channels get descrambled very well.

[aleis]

OK, probably I switched my channels too fast to see that it's not alright, when the error occurs, the tuned channel does not get descrambled, but I can switch to the next channel and all is good again.

[manio]

Can you try my getpmt branch?

[aleis]

Built it and will try it for a while...

[aleis]

As far as i can see, the PMT Errors are gone. It's all working very well with your getpmt Branch now and the channels get descrambled fast and reliable. Thanks.

[manio]

Great and thank you for your time testing this. Please test it longer to be damn sure that this one-line fixes this issue. Let me know about the results.

[jeanpijon]

Hi, I have that error still. vdr 1.7.27, pmt branch. It does only in decoding HD channels with encryption. SD-all ok. HD without encryption also ok. I can supply logs, if you want. Thanks Jean

[manio]

@jeanpijon: A log would be useful, use a pastebin for this. What branch you were testing? getpmt? What if you revert on master 8fb6597350 (or if you just use a98ff1e801)? If you need further help with this - let me know. @aleis how about your tests?

[jeanpijon]

@manio it was getpmt, but also affected master. Hi, this is log from a98ff1e: http://pastebin.com/gKwTwXMc. this one is from 8fb6597 http://pastebin.com/xj7jT3gd and none of them is working. Bug confirmed also on vdr 1.7.33. I can provide more testing if you want, but need info where and what to test. Thanks Jean

[manio]

@jeanpijon I think your problem is more a hardware problem or a wrong channel parameters in channels.conf. Have a look:

Feb  8 19:36:44 htpc vdr: [17565] frontend 1/0 timed out while tuning to channel 38, tp 111797

In this case the plugin can't do anything.

[jeanpijon]

I took channels.conf parameters from actual w_scan scan. When I try to tune to this transponder with scan-s2 I am getting this:http://pastebin.com/t45sh1Mi so at least it gets LOCK, which means, there shouldn't be a timeout, true? If this is not a plugin problem, can u point me somewhere else?

Thanks

Jean

[manio]

@jeanpijon If you have a lock then it should work also in vdr. Maybe the card has a problem only from time to time to acquire a lock, it may also depend on dish signal/quality. The dvbapi plugin is using the vdr data if it has it. So you could try this: try several times zap to this "CT Sport HD" and another one. Finally vdr should have ca descriptors data for this channel and the plugin should not try to obtain it itself. ps. what dvb card and frontend you are using?

[aleis]

Sorry for the long time needed to reply.

I still get errors, BUT without any negative effect, all channels get descrambled anyways. Here a log how it looks constantly in my syslog, even though the PMT Errors aren't as often as the other Errors. http://paste.ubuntu.com/1700139/

I don't know if the one line we changed had any effect on this, because suddenly the master branch does work good as well. And I did NOT change anything at my hardware ?!

[aleis]

Oh, probably I found something.

It's probably a network related problem due to the fact I'm using WiFi to connect to my server and the connection could be not fast or stable enough some times ?

[jeanpijon]

@manio Hi Manio, sorry for late response - problem was that they changed sth in HD transponders during my tests, so you were obviously right. It was simply fixed by rerunning scan through VDR. Thank you for your support and for the great work you are doing!

[manio]

Ok, thank you for your input. I am currently closing this issue, if someone still has this problem and is sure that the cause is not weak signal, bad channels.conf or hardware problem please reopen.

[wilb]

I know this is pulling something up from the dead, but I appear to be having issues along the lines described in this thread and they've been fixed (or worked around at least) by the commit referenced above (rev: a98ff1e)

I'm currently using YaVDR 0.5.0 with the latest stable vdr package they are distributing, along with the community maintained builds of oscam and dvbapi to match:

vdr - 2.0.6-6yavdr1 oscam-upstart-svn9850 - 1.20-svn9850.20141016.1925-1~precise vdr-plugin-dvbapi - 1.0.6.git20140424.1608-1~precise

As a background, I have a dual tuner setup - one on a fixed dish, one on a GotoX rotor, driven using the gotox patch and configured through diseqc.conf . As such there are often valid cases in which I may zap a channel and VDR thinks there is no signal, but a few seconds later a lock will arrive and off we go. I also have some cases where I haven't zapped a channel in a while and maybe the line in channels.conf is out of date, but generally the "add new transponders" setting will keep on top of this.

This evening I've been able to narrow an issue I've been seeing on and off for a while down to a constantly reproducible state where VDR ends up blocking out the use of a CAM on a particular tuner, resulting in me only being able to get FTA channels unless I restart VDR. I can make this happen on both my fixed dish and on my rotor by tuning to an encrypted channel that oscam cannot decrypt. If i leave this a few seconds, the result is that I get a "channel not available" message back from VDR when I try and tune the same tuner to another encrypted channel and have to restart VDR to fix it.

This thread came to my attention so I've just pulled down the commit above, built it manually and dropped it in place of my packaged DVBAPI library. I now have infinitely more graceful behaviour but at the cost of being even further back in time with my dvbapi library than I was before.

I'm tempted to do a wholesale upgrade of vdr / oscam / dvbapi but I worry that I'll encounter the same issue as it's a bit of an edge case...

[manio]

Hello wilb, In fact the problem you described was one of the main benefit after rewriting my plugin to use a new CAM interface provided by the current VDR versions. Currently even stable VDR has this feature so I strongly urge you to update your VDR to not use this old (and unsupported currently by me) VDR versions and dvbapi plugin. Please just use the newest stable VDR and current dvbapi plugin. I think it should work much more stable and robust for you. My plugin is not obtaining PMT itself. VDR is prepared for constantly trying to tune and then attach/detach the CAM.

[wilb]

Thanks for the clarity on that. I used to be well into keeping on top of my VDR box back when I had more time but moved over to using the YaVDR distro for simplicity which is the reason why I'm behind the times. Given what you've said I'll set aside a bit of time to get things up to date though.

Thanks!

[wilb]

Just in case anyone else stumbles upon this thread I can confirm that upgrading everything has resulted in a nice working setup. :+1: