Klaus Schmidinger wrote:
> Udo Richter wrote:
>> Lots of transfer buffer overflows and sluggish OSD, because
>> VDR used the primary FF card for recording, while the secondary budget
>> card is idle. System is back to normal if I switch to another channel.
>
> Just tested it by recording ARD from the primary device and
> watching it live at the same time. No problems whatsoever.
Added tons of debug code and found the important difference.
This is watching ARD, then starting a timer on ARD:
20:37:17 dev=0 crd=0: chan=1 freq=11836 (Hi) pol=h
GetDevice ch=1 dev=0 ndr=0 Receiving(true)=1 Receiving(false)=0
r[0] pri=-1 numPids=1 pid0=104 pid1=0 pid2=0
Impact=0001880B
GetDevice ch=1 dev=1 ndr=0 Receiving(true)=0 Receiving(false)=0
Impact=00118804
20:37:29 dev=0 crd=0: chan=1 freq=11836 (Hi) pol=h
(The line with the clock is from cStatus::ChannelSwitch, the GetDevice
is from the loop in cDevice::GetDevice, r[..] is a receiver on this
device, Impact the final result of that device)
The important thing to see is that a priority -1 receiver is attached to
the primary device, PID 104 - thats teletext on ARD. As consequence,
Receiving(true) is true and VDR believes there's already a recording
running on the primary device anyway, and starts the recording on the
primary device.
The counter-proof without osdteletext running:
20:35:47 dev=0 crd=0: chan=1 freq=11836 (Hi) pol=h
GetDevice ch=1 dev=0 ndr=0 Receiving(true)=0 Receiving(false)=0
Impact=0011880B
GetDevice ch=1 dev=1 ndr=0 Receiving(true)=0 Receiving(false)=0
Impact=00118804
20:35:55 dev=1 crd=1: chan=1 freq=11836 (Hi) pol=h
... and VDR uses the budget card for recording.
Well, thats the reason, but I'm far from suggesting any fix for it.
Cheers,
Udo
