Am 15.11.2011 23:29, schrieb Hawes, Mark:
http://projects.vdr-developer.org/projects/plg-dynamite
https://github.com/flensrocker/vdr-plugin-dynamite
I had a look at the readme. The approach of making all devices hot
pluggable is an interesting one and provides for a flexible solution.
How important it is to get plugins to adapt to the approach is still
unclear to me. Presumably if they are in the plugin list prior to the
dynamite plugin they will be 'immune' as they will declare their own
devices to the pool first.
This is right. But just like the cDvbDeviceProbe there's a cDynamicDeviceProbe class which plugins can use to add
hotplugging features to their devices. pvrinput is an example for this.
While the approach has its merits I believe that it is probably overkill
in this case. I believe that VDR should be able to cater for hybrid
cards natively alongside existing cards with more conventional adapter
layouts and any patch should ultimately have that as its goal.
What I tried to communicate is, that I have some work done which is part of the problem: closing the handles and the
right places. I will try to reuse some of the code to extend the cDvbDevice for multiple frontends.
Difficult to explain, please let me do some code first. ;-)
I will post it on the list when I have something to show.
As I see it there are two possible approaches: try to bolt on support
for hybrid cards as exception cases to the current code, or redesign the
handling of the devices from the ground up to also cater for the more
exotic adapter layouts. There could be a third 'hybrid' solution which
sits somewhere between the two.
I think there are cards which have a digital and an analog tuner. But they are only interesting if they support
hardware encoding of the analog material like the Hauppauge PVRx50 cards. I don't think it would be needed to support
such cards (iow the analog part of those cards). But one should keep this at the back of one's head.
The comment above from Steffen seems to make some sense ' if the device
nodes are created within one adapter an application needs to assume that
the devices cannot be used concurrently and needs to close one "device
node group" before opening the other one'. As I understand it this would
mean that VDR should register all front ends on initialisation and then
only try to open them when required. If another frontend is found to be
open on the same device hierarchy a decision is then made to see if it
can be closed, e.g. no recordings on it etc. If it can't then the
attempt to switch channel fails with 'Channel not available". I may be
simplifying things a bite here but that is as I see it. Happy to be
corrected.
Yes, that's the way I want to try to go.
Lars.
Mark.
_______________________________________________
vdr mailing list
vdr@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
_______________________________________________
vdr mailing list
vdr@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
_______________________________________________
vdr mailing list
vdr@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr