Klaus Schmidinger wrote:
> Udo Richter wrote:
>> Jörn Reder wrote:
>>> Hmm, it's not that easy because it ignores the original intention of
>>> this thread.
>> Not really. The side effect that osdteletext will force recordings on
>> the FF card on the same transponder was caused by the change in
>> 1.4.1-2, that was some time before your post. Its going back to the
>> "[vdr] device.c: cDevice::GetDevice" topic from syrius.ml.
>> The topic did some twists and ended at bandwidth issues on transfer
>> mode, and I was investigating why at all the recording starts on the
>> (CAM-capable) FF card instead of the (free-only) budget card.
> Oh, I thought the budget card was the one with the CAM!?
> Now that's a whole new aspect...
>>> It makes no sense that a CAM budget card is always used to
>>> record a free channel, which makes it impossible to view and/or
>>> record encrypted channels at the same time. A CAM is a valuable
>>> resource, wasting it is obviously a bad idea.
>> What if the FF card is the only one with the CAM?
> In this particular case I guess the recording really shouldn't
> start on the primary card, because the osdteletext plugin isn't
> a "real" recording process.
> So how shall we distinguish between cReceivers that do actual
> recordings and such that just receive, e.g., teletext data?
> Or those that receive a radio channel for streaming it to
> a remote client? Where's the limit?
Hm, every cReceiver which doesn't receive critical data has -1 priority.
The only exception is the transfer-mode, which has -1 too.
vdr mailing list