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. All active timers were set for ARD. I had absolutely no plans to watch Premiere, I was not even at home :-) But all recordings were done with the FF card. vdr started with the ARD channel, and the well known performance problem of FF cards resulted in bad recordings (buffer usage ... /clearing).
You see, I want the the opposite than the original poster asked for. For me it is more important to get good recordings than to be able to switch to an encrypted channel why recording another one. So I want vdr to always use the Budget card for recordings.Can this be done in any way without patching vdr? Is there any solution I don`t see? (Of course I don´t want to hardcode every channel in channels.conf to the Budget card. I still want to be able to make two FTA-recordings on different frequencies.)
I think the best solution would be to make this configurable in DVB settings or in timer menu so that the user can select the DVB card he wants to use for the recording.
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. All active timers were set for ARD. I had absolutely no plans to watch Premiere, I was not even at home :-) But all recordings were done with the FF card. vdr started with the ARD channel, and the well known performance problem of FF cards resulted in bad recordings (buffer usage ... /clearing).
Interesting. So there was just one channel recording and the FF card already run out of bandwidth?
Do you use a recent (like newer than 1 year) DVB driver and firmware?
You see, I want the the opposite than the original poster asked for. For me it is more important to get good recordings than to be able to switch to an encrypted channel why recording another one. So I want vdr to always use the Budget card for recordings.Can this be done in any way without patching vdr? Is there any solution I don`t see? (Of course I don´t want to hardcode every channel in channels.conf to the Budget card. I still want to be able to make two FTA-recordings on different frequencies.)
I think the best solution would be to make this configurable in DVB settings or in timer menu so that the user can select the DVB card he wants to use for the recording.
Unless Klaus comes up with something smart we didn't thought, there are few possibilities to resolve this by adding a config option: a) selection of the preferred card for recordings b) alternatively, a list of preferred cards in order of priority c) or a bool value to select whether to prefer Budget-CI or FF
The resulting new rule in GetDevice() should be placed between the "lowest priority" check and the "lowest CA" check.
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 programmed. All active timers were set for ARD. I had absolutely no plans to watch Premiere, I was not even at home :-) But all recordings were done with the FF card. vdr started with the ARD channel, and the well known performance problem of FF cards resulted in bad recordings (buffer usage ... /clearing).
Interesting. So there was just one channel recording and the FF card already run out of bandwidth?
Do you use a recent (like newer than 1 year) DVB driver and firmware?
@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.
Klaus
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, latest beta firmware f22623. 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.
Cheers,
Udo
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 kernel 2.6.16.19, latest beta firmware f22623. 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.
The driver I'm using is the Mercurial version 2006-02-05 (well, actually that's not _that_ recent, anyway) and the firmware version F12623 as of 2006-07-22. The size of my firmware file is 240044, and the md5sum is 099329687c91131e616b4dcd8a118a25. My CPU is an AMD K6/II 450.
Basically I do find it a good idea to preserve devices that provide more channels for live viewing, so before reverting to the old method or introducing YASO (Yet Another Setup Option) it might be a good idea to find out why this isn't working on your system.
Klaus
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:
20:37:17 dev=0 crd=0: chan=1 freq=11836 (Hi) pol=h GetDevice ch=1 dev=0 ndr=0 Receiving(true)=1 Receiving(false)=0 r[0] pri=-1 numPids=1 pid0=104 pid1=0 pid2=0 Impact=0001880B GetDevice ch=1 dev=1 ndr=0 Receiving(true)=0 Receiving(false)=0 Impact=00118804 20:37:29 dev=0 crd=0: chan=1 freq=11836 (Hi) pol=h
(The line with the clock is from cStatus::ChannelSwitch, the GetDevice is from the loop in cDevice::GetDevice, r[..] is a receiver on this device, Impact the final result of that device)
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.
The counter-proof without osdteletext running:
20:35:47 dev=0 crd=0: chan=1 freq=11836 (Hi) pol=h GetDevice ch=1 dev=0 ndr=0 Receiving(true)=0 Receiving(false)=0 Impact=0011880B GetDevice ch=1 dev=1 ndr=0 Receiving(true)=0 Receiving(false)=0 Impact=00118804 20:35:55 dev=1 crd=1: chan=1 freq=11836 (Hi) pol=h
... and VDR uses the budget card for recording.
Well, thats the reason, but I'm far from suggesting any fix for it.
Cheers,
Udo
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 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 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.
Cheers,
Udo
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 because it ignores the original intention of this thread. 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.
If it's really of general interest to reserve a FF card as long as possible (it looks this feature was requested to workaround very specific hardware problems), I'd vote for a new VDR preference setting to control the device priority, instead of any hardcoded recipe.
Regards,
Joern
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.
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?
Cheers,
Udo
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?
Klaus
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 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 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.
And here's the patch.
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 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.
And here's the patch.
diff -Nurp -x '*~' vdr-1.4.1-5/device.c vdr-1.4.1-5-mod/device.c --- vdr-1.4.1-5/device.c 2006-08-20 21:59:20.000000000 +0300 +++ vdr-1.4.1-5-mod/device.c 2006-08-23 18:41:26.000000000 +0300 @@ -292,7 +292,7 @@ cDevice *cDevice::GetDevice(const cChann // to their individual severity, where the one listed first will make the most // difference, because it results in the most significant bit of the result. uint imp = 0;
imp <<= 1; imp |= !device[i]->Receiving(true) || ndr; // use receiving devices if we don't need to detach existing receivers
imp <<= 1; imp |= !device[i]->Receiving() && device[i] != cTransferControl::ReceiverDevice() || ndr; // use receiving devices if we don't need to detach existing receivers imp <<= 1; imp |= device[i]->Receiving(); // avoid devices that are receiving imp <<= 1; imp |= device[i] == cTransferControl::ReceiverDevice(); // avoid the Transfer Mode receiver device imp <<= 8; imp |= min(max(device[i]->Priority() + MAXPRIORITY, 0), 0xFF); // use the device with the lowest priority (+MAXPRIORITY to assure that values -99..99 can be used)
Wouldn't this also avoid a non-primary device if the transfer mode is coming from there? I don't think that would be good...
Klaus
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 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.
And here's the patch.
diff -Nurp -x '*~' vdr-1.4.1-5/device.c vdr-1.4.1-5-mod/device.c --- vdr-1.4.1-5/device.c 2006-08-20 21:59:20.000000000 +0300 +++ vdr-1.4.1-5-mod/device.c 2006-08-23 18:41:26.000000000 +0300 @@ -292,7 +292,7 @@ cDevice *cDevice::GetDevice(const cChann // to their individual severity, where the one listed first will make the most // difference, because it results in the most significant bit of the result. uint imp = 0;
imp <<= 1; imp |= !device[i]->Receiving(true) ||ndr; // use receiving devices if we don't need to detach existing receivers
imp <<= 1; imp |= !device[i]->Receiving() && device[i] !=cTransferControl::ReceiverDevice() || ndr; // use receiving devices if we don't need to detach existing receivers imp <<= 1; imp |= device[i]->Receiving(); // avoid devices that are receiving imp <<= 1; imp |= device[i] == cTransferControl::ReceiverDevice(); // avoid the Transfer Mode receiver device imp <<= 8; imp |= min(max(device[i]->Priority() + MAXPRIORITY, 0), 0xFF); // use the device with the lowest priority (+MAXPRIORITY to assure that values -99..99 can be used)
Wouldn't this also avoid a non-primary device if the transfer mode is coming from there? I don't think that would be good...
I don't understand what you mean. It just modifies the algorithm to prefer receiving devices on the same transponder that have priority>=0 receivers or transfer mode receivers. Before the patch it would prefer any receiving devices on the same transponder, causing osdteletext receiver to make a difference.
Consider scenario - user watches transponder 1 channel 1 through primary FF - recording starts on transponder 1 channel 2
Before this patch: - if osdteletext has a receiver on FF, the recording is made via FF (Receiving(true) is true), otherwise via budget card
After this patch: - recording is made via budget card (same behaviour as VDR 1.4.1)
The alternative (more logical) fix would be to prefer transponder-tuned primary devices too, so that the recording in above example would be made by FF as it is tuned in the same transponder. But this would probably not be a good idea (at least without YASO) due to the apparent problems with recording via FF.
However, one possibility is to prefer the FF for recording in this situation by default (which would leave the budget card free), and also in the original situation (in which the budget has CAM), and have a setup option for Avoiding primary device for recording at all cost.
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.c 2006-08-20 21:59:20.000000000 +0300 +++ vdr-1.4.1-5-mod/device.c 2006-08-23 18:41:26.000000000 +0300 @@ -292,7 +292,7 @@ cDevice *cDevice::GetDevice(const cChann // to their individual severity, where the one listed first will make the most // difference, because it results in the most significant bit of the result. uint imp = 0;
imp <<= 1; imp |= !device[i]->Receiving(true) ||ndr; // use receiving devices if we don't need to detach existing receivers
imp <<= 1; imp |= !device[i]->Receiving() && device[i] !=cTransferControl::ReceiverDevice() || ndr; // use receiving devices if we don't need to detach existing receivers imp <<= 1; imp |= device[i]->Receiving(); // avoid devices that are receiving imp <<= 1; imp |= device[i] == cTransferControl::ReceiverDevice(); // avoid the Transfer Mode receiver device imp <<= 8; imp |= min(max(device[i]->Priority() + MAXPRIORITY, 0), 0xFF); // use the device with the lowest priority (+MAXPRIORITY to assure that values -99..99 can be used)
Wouldn't this also avoid a non-primary device if the transfer mode is coming from there? I don't think that would be good...
I don't understand what you mean. It just modifies the algorithm to prefer receiving devices on the same transponder that have priority>=0 receivers or transfer mode receivers. Before the patch it would prefer any receiving devices on the same transponder, causing osdteletext receiver to make a difference.
Consider scenario
- user watches transponder 1 channel 1 through primary FF
- recording starts on transponder 1 channel 2
Before this patch:
- if osdteletext has a receiver on FF, the recording is made via FF
(Receiving(true) is true), otherwise via budget card
After this patch:
- recording is made via budget card (same behaviour as VDR 1.4.1)
The alternative (more logical) fix would be to prefer transponder-tuned primary devices too, so that the recording in above example would be made by FF as it is tuned in the same transponder. But this would probably not be a good idea (at least without YASO) due to the apparent problems with recording via FF.
However, one possibility is to prefer the FF for recording in this situation by default (which would leave the budget card free), and also in the original situation (in which the budget has CAM), and have a setup option for Avoiding primary device for recording at all cost.
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 free) if AvoidPrimaryDevice is not set.
Also if AvoidPrimaryDevice is set, budget with CAM would be preferred over non-CAM FF for recording FTA channels in the original situation.
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 free) if
AvoidPrimaryDevice is not set.
Also if AvoidPrimaryDevice is set, budget with CAM would be preferred over non-CAM FF for recording FTA channels in the original situation.
As I said I don't like introducing additional setup options for this. We already have the infamous "Primary limit", which was introduced at a time where the FF cards were unable to receive and record at the same time (this option will be removed in version 1.5, BTW).
I'll probably take another look at your first patch - maybe I missed something when I asked whether it would also avoid a non-primary device if the transfer mode is coming from there.
At any rate, this certainly requires more testing, so I'll do as suggested by Udo Richter and revoke this change altogether and release version 1.4.2 tomorrow.
Just so that people can check this out, I have attached this final modification.
Klaus
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 requires a primary DVB card to switch to transfer mode for live viewing? At the end, thats the only thing that stops us from using the primary device for recording, or?
By the way: If this issue is the only thing that stops you from finalizing 1.4.2, I'd suggest reverting GetDevice to the 1.4.1 / 1.4.1-1 code, and continue to solve the remaining issues in 1.4.2-1.
Cheers,
Udo
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 receiving a channel requires a primary DVB card to switch to transfer mode for live viewing? At the end, thats the only thing that stops us from using the primary device for recording, or?
The primary device only needs to go into transfer mode if the channel that shall be recorded is the same as the one that is currently being viewed. That's because otherwise the user could not switch to a different channel any more.
By the way: If this issue is the only thing that stops you from finalizing 1.4.2, I'd suggest reverting GetDevice to the 1.4.1 / 1.4.1-1 code, and continue to solve the remaining issues in 1.4.2-1.
I was considering that, too. I guess that's what I'm going to do.
Klaus
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 one with the CAM?
Doesn't matter. If a CAM is not needed for a particular recording, than any card not having a CAM should be preferred, regardless whether it's a budget or FF card.
Regards,
Joern
-
Anssi Hannula -
Jörn Reder -
Klaus Schmidinger -
Martin Dauskardt -
Udo Richter