[vdr] receive data with low prio, so user-action can detach the receiver

Klaus Schmidinger Klaus.Schmidinger at cadsoft.de
Mon Nov 21 18:08:48 CET 2005


Patrick Fischer wrote:
> Klaus Schmidinger schrieb:
> 
>> Patrick Fischer wrote:
>>
>>> By the way...
>>> -how to realize that a receiver was detached?
>>> -how to ask if ANY cDevice can ProvidesChannel?
>>>
>>> I know if I create a receiver with prio -1 vdr can detach it if vdr 
>>> needs the device.
>>>
>>> My Problem is:
>>> If I create a receiver with prio -1 then vdr can detach it. Thats OK. 
>>> But if I want to know if a device can handle my new receiver(on an 
>>> defined channel) then cDevice->ProvideChannel() show me allways that 
>>> the first device can handle my receiver. Thats because my first 
>>> receiver has prio -1.
>>>
>>> If I create my receiver with prio 1 then cDevice->ProvideChannel() 
>>> tells me that the device is used. Thats better but in this case vdr 
>>> don't detach my receiver.
>>
>>
>>
>> Calling ProvidesChannel(-1) tells you whether the device can pricipally
>> provide this channel, no matter what receivers it currently has attached
>> to it. Why don't you just skip your first device if you already know
>> that you don't want to use that one?
>>
>>> It would be nice if vdr can detach all receiver with prio <50.
>>
>>
>>
>> What would that be good for?
>>
>> Klaus
> 
> 
> 
> -I want always receive Channel X
> -The user should switch if he want to
> -And I want to allot some receiver for some channels(vpids)
> But this needs some management.
> 
> It's difficult to explane, but I try:
> 
> 
> //some defines:
> Userreceiver(int channel)                : the user want to see or 
> record some channel
> myreceiver(int channel, int vpid)    : I want to receive some data from 
> channel
> staticreceiver(int channel, int vpid): this receiver should always 
> receive the vpid from channel
> 
> Same Transponder {1,2,3,4}{5,6,7,8}{9,10,11,12}{13,14,15,16}
> ********
> Getting started:
> Device 0: Userreceiver(4)
> Device 1:
> Device 2: staticreceiver(14,42)
> ------
> ->Add new myreceiver(5,213): can be attached to Device 1
> 
> Device 0: Userreceiver(4)
> Device 1: myreceiver(5,11)
> Device 2: staticreceiver(14,42)
> ------
> ->Add new myreceiver(2,113): can be attached to Device 0
> 
> Device 0: Userreceiver(4),myreceiver(2,113)
> Device 1: myreceiver(5,11)
> Device 2: staticreceiver(14,42)
> ------
> ->Add new myreceiver(7,413): can be attached to Device 1
> 
> Device 0: Userreceiver(4),myreceiver(2,113)
> Device 1: myreceiver(5,11),myreceiver(7,413)
> Device 2: staticreceiver(14,42)
> ------
> ->Add new myreceiver(16,515): can be attached to Device 2
> 
> Device 0: Userreceiver(4),myreceiver(2,113)
> Device 1: myreceiver(5,11),myreceiver(7,413)
> Device 2: staticreceiver(14,42),myreceiver(16,515)
> ------
> ->User want to switch to Channel(11): myreceiver(2,113) must be detached
> 
> Device 0: Userreceiver(11)
> Device 1: myreceiver(5,11),myreceiver(7,413)
> Device 2: staticreceiver(14,42),myreceiver(16,515)
> ------
> 
> If I want to add a new myreceiver, the i must find a device where to 
> attach it.
> How I do that?:
> I ask each device if it can handle it.
> ->Add new myreceiver(16,515){
>     for all devices
>       if(cDevice->ProvideChannel(16))
>          attach myreceiver(16,515)
> }
> 
> so I can find: device0 , device1, device2 or nodevice
> 
> If I use prio-1 the always device0 will be found.
> If I use prio>0 then the user can't switch to other channels if a 
> myreceiver is also attached to device0,device1, device2.
> 
> 
> maybe I don't understand the prio management of vdr.
> device0->attachReceiver(myreceiver,Prio10)
> if(device0->ProvideChannel(channel1,11))
>    device0->switchToChannel(channel1): that ought detach myreceiver!
> 
> wouldn't it be good if the switchToChannel can have a prio? Maybe 50.

Wouldn't it be enough to simply give your receiver a priority
of -2 (anything less than -1 would do)? That way any recording
and even a Transfer Mode (which uses priority -1) could detach your
receiver.

Klaus



More information about the vdr mailing list