Udo Richter wrote: > 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: [...] > 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. > Starting the timer on the FF might actually be more logical on this point. Consider this scenario: - user watches channel 1, transponder 1, via FF - recording starts for channel 1, transponder 1, via FF - recording starts for channel 2, transponder 2, via budget versus: - user watches channel 1, transponder 1, via FF - recording starts for channel 1, transponder 1, via budget - recording starts for channel 2, transponder 2, via FF - live view is interrupted as FF switches transponder However, if VDR can cope with the FF switching transponder and switch to transfer-mode automatically, this is not much of a problem. Unfortunately, if there are problems with the FF handling the recording, I guess the latter scenario should be used. In either case, VDR should not decide what it does based on whether teletext receiver is attached. Probably GetDevice() should be modified so that the "!device[i]->Receiving(true)" of the first rule would be replaced with something like "!device[i]->Receiving() && device[i] != cTransferControl::ReceiverDevice()". -- Anssi Hannula
