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. -- Anssi Hannula
