> Henrik Sjoberg wrote: > >>I have started working on HLCI support for mythtv (for now without any >>coordination with the mythtv project). When I last worked on it (a couple >>of weeks ago) I managed to decode at least some encypted channels. >> >>I started looking into it again last week. However, I'm seeing problem >>with the latest cvs (or any cvs since the merge) that I often don't get a >>lock when tuning channels. when I revert to cvs from for example nov 11 >>everthing works fine again. >> >> > > The only thing that is of considerable change is the addition of a > MONOSHOT read of flags .. > > mode_flags & FE_TUNE_MODE_ONESHOT > > Can you check whether this condition becomes valid for you ? If it becomes > valid, it will not read back the status from the frontend in this case and > no lock. > This condition should not ideally become valid, unless specified > explicitly. > > The condition is not valid. I have produced two logs using latest cvs, one where the fault occurs and one where it does not. Both when I am tuning to the same channel. When doing a diff between them, the first diff starts when I am to read the reply from the lock command. (When using cvs from nov 11, the log file looks as the one that is ok.) Here is the diff between the two: [root@evermeet ~]# diff -pub /tmp/ok.log /tmp/error.log --- /tmp/ok.log 2005-12-06 22:44:03.000000000 +0100 +++ /tmp/error.log 2005-12-06 22:43:57.000000000 +0100 @@ -8,9 +8,9 @@ evermeet kernel: dst_gpio_outb: mask=[00 evermeet kernel: writing [ 09 00 0a 48 d0 07 00 08 00 c6 ] evermeet kernel: dst_gpio_outb: mask=[ffffffff], enbb=[0000], outhigh=[0000] evermeet kernel: read_dst: reply is 0xff -evermeet kernel: dst_wait_dst_ready: dst wait ready after 74 +evermeet kernel: dst_wait_dst_ready: dst wait ready after 1 evermeet kernel: read_dst: reply is 0x9 -evermeet kernel: 0x0 0xa 0x48 0xd0 0x32 0x80 0x47 0x0 0xdc +evermeet kernel: 0x0 0xa 0x48 0xd0 0x7 0x0 0x8 0x0 0xc6 evermeet kernel: dst_comm_init: Initializing DST. evermeet kernel: dst_gpio_outb: mask=[ffffffff], enbb=[0001], outhigh=[0000] evermeet kernel: rdc_reset_state: Resetting state machine @@ -20,8 +20,8 @@ evermeet kernel: writing [ 00 05 00 00 0 evermeet kernel: dst_gpio_outb: mask=[ffffffff], enbb=[0000], outhigh=[0000] evermeet kernel: read_dst: reply is 0xff evermeet kernel: dst_wait_dst_ready: dst wait ready after 1 -evermeet kernel: read_dst: reply is 0xa -evermeet kernel: 0x48 0xd0 0x46 0x80 0x47 0x0 0xd1 +evermeet kernel: read_dst: reply is 0x0 +evermeet kernel: 0x0 0x0 0xc 0x80 0x47 0x0 0x2d evermeet kernel: dst_comm_init: Initializing DST. evermeet kernel: dst_gpio_outb: mask=[ffffffff], enbb=[0001], outhigh=[0000] evermeet kernel: rdc_reset_state: Resetting state machine @@ -31,6 +31,5 @@ evermeet kernel: writing [ 00 05 00 00 0 evermeet kernel: dst_gpio_outb: mask=[ffffffff], enbb=[0000], outhigh=[0000] evermeet kernel: read_dst: reply is 0xff evermeet kernel: dst_wait_dst_ready: dst wait ready after 1 -evermeet kernel: read_dst: reply is 0xa -evermeet kernel: 0x48 0xd0 0x4b 0x80 0x49 0x0 0xca - +evermeet kernel: read_dst: reply is 0x0 +evermeet kernel: 0x0 0x0 0x4b 0x80 0x4b 0x0 0xea If anyone has any idea what the problem could be, please let me know. Henrik
