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
