[vdr] priorities 0
Hi, i have a question regarding receivers with priority 0. I have taken a look at cDvbDevice::ProvidesChannel (1.7.15). When priority is 0 hasPriority gets set to true even if there are other receivers for a different channel. In this case NeedsDetachReceivers is set to false. If cDvbDevice::ProvidesChannel is called with a priority 0, then the Channel parameter has to be the Channel currently receiving on the device. Why: If the cDvbDevice::ProvidesChannel is called with priority 0 and a channel other than the current receiving, needsDetachReceived would be kept to false, the receiver would be added the the list of receivers, but the channel doesn't get switched. Or does the Channel doesn't matter if the priority is 0 ? My question: is my assumption correct ? Regards, Rainer ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] priorities 0
Hi Rainer, On Thu, 23 Sep 2010 11:11:35 +0200, Rainer Blickle wrote i have a question regarding receivers with priority 0. I have taken a look at cDvbDevice::ProvidesChannel (1.7.15). When priority is 0 hasPriority gets set to true even if there are other receivers for a different channel. In this case NeedsDetachReceivers is set to false. If cDvbDevice::ProvidesChannel is called with a priority 0, then the Channel parameter has to be the Channel currently receiving on the device. Why: If the cDvbDevice::ProvidesChannel is called with priority 0 and a channel other than the current receiving, needsDetachReceived would be kept to false, the receiver would be added the the list of receivers, but the channel doesn't get switched. Or does the Channel doesn't matter if the priority is 0 ? My question: is my assumption correct ? I stumbled across this a while ago, too. A negative priority changes the semantics of this function. From the documentation of ProvidesChannel in device.h: The special Priority value -1 will tell the caller whether this device is principally able to provide the given Channel, regardless of any attached cReceivers. The only place in VDR where ProvidesChannel is called is from GetDevice. As a consequence GetDevice should never be called with a negative priority (even though GetDevice support priorities down to -99). This is somewhat unexpected. Negative priorities are used for receivers which may be detached anytime. If I'd been looking for an idle device for tuning some channel and attaching a receiver with negative priority, I would have used a GetDevice call with negative priority... Regards, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] Add support for shared frondends cards
-- Initial Header --- From : vdr-boun...@linuxtv.org To : VDR Mailing List vdr@linuxtv.org Cc : Date : Wed, 22 Sep 2010 21:41:01 +0100 Subject : Re: [vdr] [PATCH] Add support for shared frondends cards On 21 Sep 2010, at 16:06, support.intranet wrote: The attached patch (for VDR 1.7.16) implements support for multituner cards where only one tuner can be active at one time, the so called shared frontend cards (notably the HVR-4000 and its derivatives). Currently VDR tries to open all the frontends on startup, with the result that the first frontend (usually DVB-S) works, but the second (usually DVB-T) fails with Device or resource busy error. The patch adds a new configuration option to setup.conf, called OnDemand; it defaults to 0 (exactly the current behaviour). If set to 1, tuners will be appropriately opened and closed when switching channels. I've tested it with the vnsi plugin and XBMC. I'd be happy if someone could review it and tell me if there is anything to correct and if it is possible to mainline it. Alberto aod.diff___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr Ciao Alberto, Interesting work. I live in the UK and have an HVR4000 for DVB-S. Unfortunately DVB-T reception is poor where I live (hence the satellite solution - additional multilnb to point at 28.2E and 13.0E for L'Eridita) so I cannot fully test this past patching and compiling which I assume will work as you state you have tested. Looking at the patch, there is something about inhibit epgscan. I do not know much about vdr internals. Would patching vdr and enabling the ondemand option stop epg from updating? A slight negative if this is the case. Ian. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr Hi Ian, thanks for your answer. The problem with background epg scan is that it tries to access the device you are not using to watch/record as it thinks it is free, so if I don't disable it your favourite program would be stopped every few moments because the scan is taking place (and it closes down all other devices to access its one). I'm currently working on a better approach to this, so that if VDR is opened but you are not using it epg scan is allowed to work. Alberto ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
