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