Klaus Schmidinger wrote: > Klaus Schmidinger wrote: > >> Thomas Rausch wrote: >> >>> After 6 hours I must say that my VDR did not bring yet back the >>> error. So far otherwise always. I want to hope that it functions now. :) >>> >>> In the LOG comes however repeatedly: >>> >>> Jan 3 18:15:43 cat vdr[16675]: ERROR: frontend 0 lost lock >>> Jan 3 18:15:43 cat vdr[16675]: frontend 0 regained lock >>> Jan 3 18:16:03 cat vdr[16675]: ERROR: frontend 0 lost lock >>> Jan 3 18:16:03 cat vdr[16675]: frontend 0 regained lock >>> Jan 3 18:16:25 cat vdr[16675]: ERROR: frontend 0 lost lock >>> Jan 3 18:16:26 cat vdr[16675]: frontend 0 regained lock >>> Jan 3 18:16:45 cat vdr[16675]: ERROR: frontend 0 lost lock >>> Jan 3 18:16:45 cat vdr[16675]: frontend 0 regained lock >>> Jan 3 18:17:06 cat vdr[16675]: ERROR: frontend 0 lost lock >>> Jan 3 18:17:06 cat vdr[16675]: frontend 0 regained lock >> >> >> >> Apparently the FE_GET_EVENT ioctl() sometimes delivers a different >> status value than FE_READ_STATUS. I ran some tests, comparing both >> values and whenever VDR reported a lost lock, the current FE_READ_STATUS >> value still had the FE_HAS_LOCK set correctly. >> >> Following an old recommendation of Holger W?chtler I finally changed >> the frontend status handling so that it polls the frontend and reads >> any pending event (but simply discards it), and then reads the actual >> status via FE_READ_STATUS. >> >> With the attached patch (which is again a complete patch against >> dvbdevice.c of version 1.3.37) I don't get these spurious "lost lock" >> messages any more. >> >> I've also increased the timeout for polling the event queue to 10ms, >> because 1ms seemed a little hard to me. This had no effect on the >> "lost lock" problem, however, so the change in status handling really >> is what fixed it. >> >> Please try whether this also helps in your case. > > > Unfortunately this broke the CAM menu handling, so here's > a slightly different version. > > Sorry about that... And sorry again... Looks like the only thing that was really wrong was the 'continue' in the (Status & FE_HAS_LOCK) branch. So here's yet another version, hopefully this will be the last one. Klaus -------------- next part -------------- A non-text attachment was scrubbed... Name: vdr.1.3.37-tunertimeout4.diff Type: text/x-patch Size: 6222 bytes Desc: not available Url : http://www.linuxtv.org/pipermail/vdr/attachments/20060104/258e2724/vdr.1.3.37-tunertimeout4.bin
