Klaus Schmidinger wrote:
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?
Is there a way to predict whether receiving a channel
Udo Richter wrote:
Klaus Schmidinger wrote:
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?
Is there a way to predict whether
Anssi Hannula wrote:
...
Attached is a patch which has this approach.
So after *this* patch the above quoted scenario would continue like this
instead:
- recording is made via budget card (same behaviour as VDR 1.4.1) if
AvoidPrimaryDevice is set
- recording is made via FF card (leaving budget
Udo Richter wrote:
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
Anssi Hannula wrote:
Martin Dauskardt wrote:
I upgraded to 1.4.1-4, which seems to include the patch from Anssi
(http://linuxtv.org/pipermail/vdr/2006-August/010360.html )
I am not happy with this patch: My machine has a FF-card and
Budget-Card+CAM. There was no timer for any encrypted channel
Klaus Schmidinger wrote:
@Martin: any news on this? With recent drivers and firmware it should be
possible to record and watch even the high-bandwidth channels like ZDF
on a FF card.
Question is, how recent. I'm just running a recording on ARD.
vdr-1.4.1-5, DVB driver of kernel 2.6.16.19,
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
Anssi Hannula wrote:
Consider this scenario:
- user watches channel 1, transponder 1, via FF
- recording starts for channel 1, transponder 1, via FF
add here:
- live view is interrupted as FF switches to transfer mode
- recording starts for channel 2, transponder 2, via budget
The primary
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
