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 f
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
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
Anssi Hannula wrote:
> Klaus Schmidinger wrote:
>> Anssi Hannula wrote:
>>>
>>> diff -Nurp -x '*~' vdr-1.4.1-5/device.c vdr-1.4.1-5-mod/device.c
>>> --- vdr-1.4.1-5/device.c2006-08-20 21:59:20.0 +0300
>>> +++ vdr-1.4.1-5-mod/device.c2006-08-23 18:41:26.0 +0300
>>> @@ -292,7
Klaus Schmidinger wrote:
> Anssi Hannula wrote:
>> Anssi Hannula wrote:
>>> Klaus Schmidinger wrote:
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 di
Anssi Hannula wrote:
Anssi Hannula wrote:
Klaus Schmidinger wrote:
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
Anssi Hannula wrote:
> Klaus Schmidinger wrote:
>> 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 s
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
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
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
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 bac
Udo Richter wrote:
> The primary device should be available for live viewing as long as
> possible. Even if I do a recording, the primary device should be
> available for channel switching, and not requiring transfer mode.
> Recording is the job of the budget card.
Hmm, it's not that easy beca
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 d
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.
>>
>>
>> Ju
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 primar
Martin Dauskardt wrote:
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.
The problem appeared with "Tagesschau" on ARD. Not every recording on
ARD or ZDF
Udo Richter wrote:
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 ke
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, late
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
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
> programmed.
20 matches
Mail list logo
