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