Forums

Hello,

For last 2-3 weeks I have been suffering from above mentioned problem "Timeout reading PAT" or just black screen without any messages. Most of the timed recordings fail and problem also comes just watching TV and switching bethween channels. This has happened both with channels form USB-T stick and internal DVB-S channels. When one tuner type is lost, the other type is still operational. Only way to recover is to reboot the box. Box is functional in all other ways during the problem. Problem first appeared after some online update of OpenPLi. The dmesg.txt is from problem time and second one is right after reboot (when everything is working fine). Could someone please have an look what is causing this.

This can only be a driver problem, the drivers are closed source and cannot be modified by us in any way.

This can only be a driver problem, the drivers are closed source and cannot be modified by us in any way.

Hi,

I was already afraid you would say that... Could you (or someone else) dig out what related driver has changed (within last month) and maybe sent the previous driver, so I could verify that it is the case?

This problem has been occuring on-and-off for a long time, over various driver versions. I am surprised you're seeing it just now. You can see in the commit logs when the last driver update has been (somewhere between 3-10 days ago I guess) and downgrade to a version before that, maybe it helps, maybe it doesn't

This problem has been occuring on-and-off for a long time, over various driver versions. I am surprised you're seeing it just now. You can see in the commit logs when the last driver update has been (somewhere between 3-10 days ago I guess) and downgrade to a version before that, maybe it helps, maybe it doesn't

Hmm... Maybe its related to the USB-T stick drivers as nobody else seems to have the problem and the DVB-S side problem (that I saw once... was not related to this). The problem has been longer than 10 days and is very frequent, several times a day. How/Where can I find the commits for them (newbie, in this ;-) )? Or find earlier version to downgrade to?

I did a bit more investigation on the box and found out that there were missing /etc/modules and /etc/modutils/dvb-usb-af9015 files. I added them manually and incerted the needed info into them. All needed kernel modules were loaded though in to the box (checked that also). Might this have something to do with the problem? I'll now wait and see is there any change in the behaviour. Attached an small dumb shell script of what I did.

Forgot to mention that I removed the USB-T drivers and installed them again. Intrestingly it installed an old version of the driver, so it has not been updated in repository since http://openpli.org/f...longer-working/ as since that time I have been using the driver delivered by javier3034 in the discussion succesfully for long time. Time to check for newer drivers for af9013&af9015 to repository?

I got the previous VuDuo drivers (20130207) from http://archive.vuplu...wnload/drivers/ and copied them into /lib/modules/3.1.1/extra/ and did an reboot. I still get exactly the same error "!!!pes_cb idx<0" in dmesg after switching bethween channels couple of times. Any idea what to try next?

Such a message doesn't necessarily mean an error, it can also be debugging output.

OK. So now I did an fresh install with todays OpenPLi package. Same issue still. Intresting thing is that if there is an recording ongoing in one of the DVB-T tuners © the whole bouquet where recording is made from is vieable and remains so even though the other DVB-T (D) tuner goes "black" (with switching channels). After recording finishes also the other (blackened) bouquets are viewable with tuner ©, but switching channels puts all channels "black". I monitored with top command and when I go to non working channel the enigma2 process goes to running ® state with about 50% CPU time (staying there) and returns to normal state (S) with wieable channel CPU being less than 5%. Only reboot restores the "blackened" channels back to viewable. There is all the time about 26640K free memory shown in top command, so thats not running out... Now I have no ideas what to try next. Anyone else?

An update to this problem. Now I have removed the af9015 drivers and installed an new WinTV Duet stick with dib drivers. Same problem exists still. Very strange problem as for an channel that sends dvb-subtitles the channel may be "black" but subtitles are shown correctly and signal strength + other values shows the stick to be functional.

The "timeout reading PAT" is a well-known problem on VU+ receivers (apparently it's a driver bug).

Yep. This has been discussed earlier. But the thing is that this was working fine before spring... I have now tried with all 2012 and 2013 VU drivers. Problem remains that I dont understand. So something else must have changed. Actually the problem gets worse with earlier VU drivers. Could there be some timing changed so that it does not wait long enough for signal (and does not retry)? That came to my mind because the tuning on the DVB-T stick takes longer. Why is the "failed" tuning also remembered and somehow not retried (as once failed tune on channel dont recover...).

These promlems mysteriously dissapeared with the 29.6. software update. They had nothing to do with Vu+ Duo or DVB-T drivers (they were not updated in my box...).

I other words, an optimisation previously applied was reverted because some receiver's drivers didn't handle it correctly. So yes, it actually IS a driver problem.

I would say it the other way around. The drivers work correctly as they have been working before. The optimization just did not work with the drivers already provided, without an patch to the optimization. So it's an opinion and how you want to see it... I always blaim the latest change that breaks something already working   anyways I am very happy to finally get the box working properly, two months wait was just reeeeally painful with the problem. Thanks to the person who finally fixed it!

OK. Thanks for the clarification and the workaround, which in the case of VU drivers might be permanent .