| Message ID | 42C1F492.3050303@gmail.com |
|---|---|
| State | New |
| Headers |
Received: from fep19.inet.fi ([194.251.242.244]) by www.linuxtv.org with esmtp (Exim 4.34) id 1DnR4D-0001lh-Is for vdr@linuxtv.org; Wed, 29 Jun 2005 03:08:41 +0200 Received: from posti.hopto.org ([80.223.77.223]) by fep19.inet.fi with ESMTP id <20050629010837.EWKA1914.fep19.inet.fi@posti.hopto.org> for <vdr@linuxtv.org>; Wed, 29 Jun 2005 04:08:37 +0300 Received: from [10.0.0.3] (kone [10.0.0.3]) by posti.hopto.org (Postfix) with ESMTP id EA94437F800D for <vdr@linuxtv.org>; Wed, 29 Jun 2005 04:08:36 +0300 (EEST) Message-ID: <42C1F492.3050303@gmail.com> Date: Wed, 29 Jun 2005 04:08:34 +0300 From: Anssi Hannula <anssi.hannula@gmail.com> User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050322) X-Accept-Language: en-us, en MIME-Version: 1.0 To: vdr@linuxtv.org Content-Type: multipart/mixed; boundary="------------000809060903060902040609" Subject: [vdr] [PATCH] Priority of transfer-mode should not be -1 X-BeenThere: vdr@linuxtv.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Klaus Schmidinger's VDR <vdr@linuxtv.org> List-Id: Klaus Schmidinger's VDR <vdr.linuxtv.org> List-Unsubscribe: <http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr>, <mailto:vdr-request@linuxtv.org?subject=unsubscribe> List-Archive: <http://www.linuxtv.org/pipermail/vdr> List-Post: <mailto:vdr@linuxtv.org> List-Help: <mailto:vdr-request@linuxtv.org?subject=help> List-Subscribe: <http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr>, <mailto:vdr-request@linuxtv.org?subject=subscribe> X-List-Received-Date: Wed, 29 Jun 2005 01:08:41 -0000 Status: O X-Status: X-Keywords: X-UID: 3295 |
Commit Message
Anssi Hannula
June 29, 2005, 1:08 a.m. UTC
Hi! The transfer-mode uses always priority -1. That presents a problem: If I connect to that vdr using streamdev, it switches the first budget device off from the multiplex transfered to the FF card, although there is a second identical budget device available. Also, if I had DVB-S FF and only one DVB-T budget and had a DVB-T recording with priority 10 and Primary Limit at 20, live DVB-T video would (wouldn't it?) be severed. Klaus, shouldn't transfer-mode be also using the Primary Limit value, so that recordings with priority less than Primary Limit couldn't distract the output of primary device? Patch attached.
Comments
Anssi Hannula wrote: > The transfer-mode uses always priority -1. > > That presents a problem: If I connect to that vdr using streamdev, it > switches the first budget device off from the multiplex transfered to > the FF card, although there is a second identical budget device available. > > Also, if I had DVB-S FF and only one DVB-T budget and had a DVB-T > recording with priority 10 and Primary Limit at 20, live DVB-T video > would (wouldn't it?) be severed. > > Klaus, shouldn't transfer-mode be also using the Primary Limit value, so > that recordings with priority less than Primary Limit couldn't distract > the output of primary device? > > Patch attached. This bug is still present in 1.3.29. Klaus, I know that your day is only 24 hours long and that I'm bringing this patch up the third time, but could this be either applied or replied?
Anssi Hannula wrote: > Anssi Hannula wrote: > >> The transfer-mode uses always priority -1. >> >> That presents a problem: If I connect to that vdr using streamdev, it >> switches the first budget device off from the multiplex transfered to >> the FF card, although there is a second identical budget device >> available. >> >> Also, if I had DVB-S FF and only one DVB-T budget and had a DVB-T >> recording with priority 10 and Primary Limit at 20, live DVB-T video >> would (wouldn't it?) be severed. >> >> Klaus, shouldn't transfer-mode be also using the Primary Limit value, >> so that recordings with priority less than Primary Limit couldn't >> distract the output of primary device? >> >> Patch attached. > > > This bug is still present in 1.3.29. > Klaus, I know that your day is only 24 hours long and that I'm bringing > this patch up the third time, but could this be either applied or replied? Sorry, your original posting was during my vacation, so I must have overlooked it. I guess you're right with this and will make it so in the next version. Klaus
Klaus Schmidinger wrote: > > Sorry, your original posting was during my vacation, so I must > have overlooked it. > > I guess you're right with this and will make it so in the next version. > Okay :)
Hi, Anssi Hannula wrote: > The transfer-mode uses always priority -1. > > That presents a problem: If I connect to that vdr using streamdev, it > switches the first budget device off from the multiplex transfered to > the FF card, although there is a second identical budget > device available. > > Also, if I had DVB-S FF and only one DVB-T budget and had a DVB-T > recording with priority 10 and Primary Limit at 20, live DVB-T video > would (wouldn't it?) be severed. > > Klaus, shouldn't transfer-mode be also using the Primary > Limit value, so > that recordings with priority less than Primary Limit > couldn't distract > the output of primary device? > > Patch attached. I think there is a problem with your patch. There is a reason for the priority -1. Imagine you have a channel which can only be received by one card and this card is used for transfer-mode. When you want to switch to this channel, the transfer-mode has, with your patch, e.g priority 0. But the new transfer-mode would have the same priority (but not a higher), so there would be no free device (channel not available). So when searching for a free device, vdr should consider that the device, which is used for transfer-mode, could be free, if transfer-mode for the current channel has ended. Thomas
Thomas Bergwinkl wrote: > Hi, > > Anssi Hannula wrote: > >>The transfer-mode uses always priority -1. >> >>That presents a problem: If I connect to that vdr using streamdev, it >>switches the first budget device off from the multiplex transfered to >>the FF card, although there is a second identical budget >>device available. >> >>Also, if I had DVB-S FF and only one DVB-T budget and had a DVB-T >>recording with priority 10 and Primary Limit at 20, live DVB-T video >>would (wouldn't it?) be severed. >> >>Klaus, shouldn't transfer-mode be also using the Primary >>Limit value, so >>that recordings with priority less than Primary Limit >>couldn't distract >>the output of primary device? >> >>Patch attached. > > > I think there is a problem with your patch. There is a reason for the > priority -1. Imagine you have a channel which can only be received by > one card and this card is used for transfer-mode. When you want to > switch to this channel, the transfer-mode has, with your patch, e.g > priority 0. But the new transfer-mode would have the same priority (but > not a higher), so there would be no free device (channel not available). > So when searching for a free device, vdr should consider that the > device, which is used for transfer-mode, could be free, if transfer-mode > for the current channel has ended. Oh, I just assumed VDR takes that into account. If not, then of course it either has to be implemented or the patch not applied. I have 3 DVB-T cards in my system, so I can use the patch anyway.
Thomas Bergwinkl wrote: > Hi, > > Anssi Hannula wrote: > > >>The transfer-mode uses always priority -1. >> >>That presents a problem: If I connect to that vdr using streamdev, it >>switches the first budget device off from the multiplex transfered to >>the FF card, although there is a second identical budget >>device available. >> >>Also, if I had DVB-S FF and only one DVB-T budget and had a DVB-T >>recording with priority 10 and Primary Limit at 20, live DVB-T video >>would (wouldn't it?) be severed. >> >>Klaus, shouldn't transfer-mode be also using the Primary >>Limit value, so >>that recordings with priority less than Primary Limit >>couldn't distract >>the output of primary device? >> >>Patch attached. > > > I think there is a problem with your patch. There is a reason for the > priority -1. Imagine you have a channel which can only be received by > one card and this card is used for transfer-mode. When you want to > switch to this channel, the transfer-mode has, with your patch, e.g > priority 0. But the new transfer-mode would have the same priority (but > not a higher), so there would be no free device (channel not available). > So when searching for a free device, vdr should consider that the > device, which is used for transfer-mode, could be free, if transfer-mode > for the current channel has ended. Thanks, I didn't think of this when I said I would adopt that change. Actually, the PrimaryLimit was implemented at a time where the FF DVB cards were unable to record and replay at the same time. In that case, when a timer needed to use the primary device, it was no longer possible to switch to a different channel. These times are long gone, so I would instead tend to remove the PrimaryLimit altogether. It would make things simpler instead of more complex ;-) If somebody has programmed so many timers that all of the DVB cards are needed to record them, so be it. Comments? Klaus
Klaus Schmidinger wrote: >> Anssi Hannula wrote: >> >>> The transfer-mode uses always priority -1. >>> >>> That presents a problem: If I connect to that vdr using streamdev, it >>> switches the first budget device off from the multiplex transfered to >>> the FF card, although there is a second identical budget >>> device available. >>> > Actually, the PrimaryLimit was implemented at a time where the FF DVB > cards were unable to record and replay at the same time. In that case, > when a timer needed to use the primary device, it was no longer possible > to switch to a different channel. These times are long gone, so I would > instead tend to remove the PrimaryLimit altogether. It would make things > simpler instead of more complex ;-) > > If somebody has programmed so many timers that all of the DVB cards > are needed to record them, so be it. > > Comments? > How exactly would that resolve the situation I described above?
Anssi Hannula wrote: > Klaus Schmidinger wrote: > >>> Anssi Hannula wrote: >>> >>>> The transfer-mode uses always priority -1. >>>> >>>> That presents a problem: If I connect to that vdr using streamdev, it >>>> switches the first budget device off from the multiplex transfered to >>>> the FF card, although there is a second identical budget >>>> device available. >>>> > >> Actually, the PrimaryLimit was implemented at a time where the FF DVB >> cards were unable to record and replay at the same time. In that case, >> when a timer needed to use the primary device, it was no longer possible >> to switch to a different channel. These times are long gone, so I would >> instead tend to remove the PrimaryLimit altogether. It would make things >> simpler instead of more complex ;-) >> >> If somebody has programmed so many timers that all of the DVB cards >> are needed to record them, so be it. >> >> Comments? >> > > How exactly would that resolve the situation I described above? Well, it wouldn't. Apparently I overread that this was a streamdev issue. But then again, it's of course the same problem if you are in Transfer-Mode and a recording starts and selects the receiver device, even though an other device would be free. I'll think over this again... Klaus
Klaus Schmidinger wrote: > Anssi Hannula wrote: > > Klaus Schmidinger wrote: > > > >>> Anssi Hannula wrote: > >>> > >>>> The transfer-mode uses always priority -1. > >>>> > >>>> That presents a problem: If I connect to that vdr using > streamdev, it > >>>> switches the first budget device off from the multiplex > transfered to > >>>> the FF card, although there is a second identical budget > >>>> device available. > >>>> > > > >> Actually, the PrimaryLimit was implemented at a time where > the FF DVB > >> cards were unable to record and replay at the same time. > In that case, > >> when a timer needed to use the primary device, it was no > longer possible > >> to switch to a different channel. These times are long > gone, so I would > >> instead tend to remove the PrimaryLimit altogether. It > would make things > >> simpler instead of more complex ;-) > >> > >> If somebody has programmed so many timers that all of the DVB cards > >> are needed to record them, so be it. > >> > >> Comments? > >> > > > > How exactly would that resolve the situation I described above? > > Well, it wouldn't. Apparently I overread that this was a > streamdev issue. > But then again, it's of course the same problem if you are in > Transfer-Mode > and a recording starts and selects the receiver device, even > though an other > device would be free. > > I'll think over this again... What do you think about the attached patch? Thomas
Thomas Bergwinkl wrote: > Klaus Schmidinger wrote: > >>Anssi Hannula wrote: >> >>>Klaus Schmidinger wrote: >>> >>> >>>>>Anssi Hannula wrote: >>>>> >>>>> >>>>>>The transfer-mode uses always priority -1. >>>>>> >>>>>>That presents a problem: If I connect to that vdr using >> >>streamdev, it >> >>>>>>switches the first budget device off from the multiplex >> >>transfered to >> >>>>>>the FF card, although there is a second identical budget >>>>>>device available. >>>>>> >>> >>>>Actually, the PrimaryLimit was implemented at a time where >> >>the FF DVB >> >>>>cards were unable to record and replay at the same time. >> >>In that case, >> >>>>when a timer needed to use the primary device, it was no >> >>longer possible >> >>>>to switch to a different channel. These times are long >> >>gone, so I would >> >>>>instead tend to remove the PrimaryLimit altogether. It >> >>would make things >> >>>>simpler instead of more complex ;-) >>>> >>>>If somebody has programmed so many timers that all of the DVB cards >>>>are needed to record them, so be it. >>>> >>>>Comments? >>>> >>> >>>How exactly would that resolve the situation I described above? >> >>Well, it wouldn't. Apparently I overread that this was a >>streamdev issue. >>But then again, it's of course the same problem if you are in >>Transfer-Mode >>and a recording starts and selects the receiver device, even >>though an other >>device would be free. >> >>I'll think over this again... > > > What do you think about the attached patch? > > Thomas @Anssi: have you had a chance to test this patch yet? Klaus
Klaus Schmidinger wrote: > Thomas Bergwinkl wrote: > > Klaus Schmidinger wrote: > > > >>Anssi Hannula wrote: > >> > >>>Klaus Schmidinger wrote: > >>> > >>> > >>>>>Anssi Hannula wrote: > >>>>> > >>>>> > >>>>>>The transfer-mode uses always priority -1. > >>>>>> > >>>>>>That presents a problem: If I connect to that vdr using > >> > >>streamdev, it > >> > >>>>>>switches the first budget device off from the multiplex > >> > >>transfered to > >> > >>>>>>the FF card, although there is a second identical budget > >>>>>>device available. > >>>>>> > >>> > >>>>Actually, the PrimaryLimit was implemented at a time where > >> > >>the FF DVB > >> > >>>>cards were unable to record and replay at the same time. > >> > >>In that case, > >> > >>>>when a timer needed to use the primary device, it was no > >> > >>longer possible > >> > >>>>to switch to a different channel. These times are long > >> > >>gone, so I would > >> > >>>>instead tend to remove the PrimaryLimit altogether. It > >> > >>would make things > >> > >>>>simpler instead of more complex ;-) > >>>> > >>>>If somebody has programmed so many timers that all of the DVB cards > >>>>are needed to record them, so be it. > >>>> > >>>>Comments? > >>>> > >>> > >>>How exactly would that resolve the situation I described above? > >> > >>Well, it wouldn't. Apparently I overread that this was a > >>streamdev issue. > >>But then again, it's of course the same problem if you are in > >>Transfer-Mode > >>and a recording starts and selects the receiver device, even > >>though an other > >>device would be free. > >> > >>I'll think over this again... > > > > > > What do you think about the attached patch? > > > > Thomas > > @Anssi: have you had a chance to test this patch yet? Meanwhile I realised that in cDevice::SetChannel GetDevice is called with priority 0. So the 'Priority >= 0' in the patch is always true (and therefore could be replaced be 'true') . This will lead to a 'sideeffect' if more than one device is able to provide this channel: When zapping through the channels always the other device will be choosen. Another effect with this patch is, that when a recording on the same transponder starts, which currently is received via transfermode, then the receiving device will be prefered for the recording be GetDevice(). So I am not really happy with this patch anymore and think a better solution is neccessary. Thomas
Thomas Bergwinkl wrote: > Klaus Schmidinger wrote: > >>Thomas Bergwinkl wrote: >> >>>Klaus Schmidinger wrote: >>> >>>>Well, it wouldn't. Apparently I overread that this was a >>>>streamdev issue. >>>>But then again, it's of course the same problem if you are in >>>>Transfer-Mode >>>>and a recording starts and selects the receiver device, even >>>>though an other >>>>device would be free. >>>> >>>>I'll think over this again... >>> >>> >>>What do you think about the attached patch? >>> >>>Thomas >> >>@Anssi: have you had a chance to test this patch yet? Oops, sorry I didn't notice this new patch at all. Is this meant to be used with or without my initial patch? > Meanwhile I realised that in cDevice::SetChannel GetDevice is called with > priority 0. So the 'Priority >= 0' in the patch is always true (and > therefore could be replaced be 'true') . This will lead to a 'sideeffect' if > more than one device is able to provide this channel: When zapping through > the channels always the other device will be choosen. Another effect with > this patch is, that when a recording on the same transponder starts, which > currently is received via transfermode, then the receiving device will be > prefered for the recording be GetDevice(). > So I am not really happy with this patch anymore and think a better solution > is neccessary. > Hmm, too complicated for me to understand right now... BTW, with my original patch, the channel switching in DVB-T seems to be faster. When switching multiplex, VDR also switches to second device. When I switch back to the previous multiplex, I believe the first card (which VDR changes back to) is still tuned to that and retuning is not necessary. However this same thing is the problem also, as Thomas said, because you need always an extra free card for multiplex switching (which is not a problem for me, because number of multiplexes = number of cards).
--- transfer.c.old 2005-06-29 03:50:18.000000000 +0300 +++ transfer.c 2005-06-29 03:59:26.000000000 +0300 @@ -15,7 +15,7 @@ // --- cTransfer ------------------------------------------------------------- cTransfer::cTransfer(int VPid, const int *APids, const int *DPids, const int *SPids) -:cReceiver(0, -1, VPid, APids, Setup.UseDolbyDigital ? DPids : NULL, SPids) +:cReceiver(0, Setup.PrimaryLimit, VPid, APids, Setup.UseDolbyDigital ? DPids : NULL, SPids) ,cThread("transfer") { ringBuffer = new cRingBufferLinear(TRANSFERBUFSIZE, TS_SIZE * 2, true, "Transfer");