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