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. Klaus -------------- next part -------------- A non-text attachment was scrubbed... Name: vdr.1.3.37-tunertimeout2.diff Type: text/x-patch Size: 6251 bytes Desc: not available Url : http://www.linuxtv.org/pipermail/vdr/attachments/20060104/88dcc234/vdr.1.3.37-tunertimeout2.bin
