VDR-1.3.37: retuning -- possibly a fix for VDSB

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Util Linux NG]     [Xfree86]     [Big List of Linux Books]     [Fedora Users]     [Fedora Women]     [ALSA Devel]     [Linux USB]

  Powered by Linux