Re: [vdr] VDR and Hybrid DVB Cards ( was "HVR 4000 drivers broken - adapter0/frontend1 busy" in linux-media list )
On Tue, 15 Nov 2011 14:08:24 +1100 "Hawes, Mark" wrote: >> Lars, >> >> Thanks for the reply. >> >> Output of ls -la /dev/dvb/adapter0: >> >> root@Nutrigrain:/home/digitalTV/vdr-1.7.21# ls -la /dev/dvb/adapter0/* >> crw-rw 1 root video 212, 1 Nov 14 19:20 /dev/dvb/adapter0/demux0 >> crw-rw 1 root video 212, 5 Nov 14 19:20 /dev/dvb/adapter0/demux1 >> crw-rw 1 root video 212, 2 Nov 14 19:20 /dev/dvb/adapter0/dvr0 >> crw-rw 1 root video 212, 6 Nov 14 19:20 /dev/dvb/adapter0/dvr1 >> crw-rw 1 root video 212, 0 Nov 14 >> 19:20 /dev/dvb/adapter0/frontend0 crw-rw 1 root video 212, 4 Nov >> 14 19:20 /dev/dvb/adapter0/frontend1 crw-rw 1 root video 212, 3 >> Nov 14 19:20 /dev/dvb/adapter0/net0 crw-rw 1 root video 212, 7 Nov >> 14 19:20 /dev/dvb/adapter0/net1 >> root@Nutrigrain:/home/digitalTV/vdr-1.7.21# >> >> As you can see there is a demux1 and dvr1 but all hung off adapter0 >> which is presumably the problem.> >> > >Not that on itself, but possibly the implications. Can you try to start the vdr with -D 1 to start the vdr only at the second card ? Assumption would >be, that you can use each individually, if you not filter for a device you get a busy device on the second. > Have done so and yes, the DVB-T device is now recognised instead of the DVB-S2 device (and it works). > >What i got from previous discussions on linux-media is, that if the device nodes are created within one adapter, an application needs to assume that >the devices can not be used concurrently and needs to close one "device node group" before opening the other one. > This suggests a constraint in the current design of the way VDR handles the detection and use of DVB devices in that it cannot handle so called 'hybrid' cards where two (or more!) frontends are attached via a single adaptor without restarting VDR and identifying which frontend to use. As already mentioned I wish to use both cards on my system and I'd be interested and happy to help in developing a patch to overcome this constraint. However I would need some VDR architectural guidance to suggest how this might be done with minimal disruption to the current DVB device handling. Any direction would be much appreciated. >> I actually want to use both the DVB-S2 and the DVB-T frontends, though >> not concurrently. >> >> Happy to work with you on developing the required patch. >> >> If as you suggest that this is actually a VDR problem then I'll also >> post this reply in the VDR mailing list and we can take it from there. >> >> Regards, >> >> Mark. >> > -Original Message- > From: linux-media-ow...@vger.kernel.org > [mailto:linux-media-ow...@vger.kernel.org] On Behalf Of L. Hanisch > Sent: Tuesday, 15 November 2011 5:35 AM > To: linux-me...@vger.kernel.org > Subject: Re: HVR 4000 drivers broken - adapter0/frontend1 busy > > Hi, > > Am 14.11.2011 04:14, schrieb Hawes, Mark: > > Hi, > > > > I have just acquired a Hauppauge HVR 4000 hybrid DVB-S2 / DVB-T / > > Analogue card > > which I am trying to use with VDR 1.7.21 on the latest Slackware > stable release > using kernel 2.6.37.6. > > vdr doesn't know anything about hybrid cards where you can access > only one frontend at the same time. > On startup vdr opens all frontends, so when accessing the second one > this is blocked. > > Since I don't know this card exactly, what devices does it create? > Is there also a demux[01] and dvr[01] or just a > demux0 and dvr0? Which frontend do you want to use? For now you have > to choose one and start vdr with the "-D" parameter to tell it which > to use. > If there's no demux1 and dvr1 and you want to use frontend1 you'll > have the next problem since vdr asumes that every frontend has its own > demux/dvr. I wrote a patch, so vdr uses demux0 with frontend1. > > http://linuxtv.org/pipermail/vdr/2011-November/025411.html > > Soon I will have some DVB-C/T hybrid device so I will try to extend > the patch so both frontends can be used (not at the same time of > course). > > It would be nice if you can send me the output of "ls -la > /dev/dvb/adapter0/*". > > I don't know exactly what the dvb/v4l spec is saying about hybrid > devices and how they should expose their capabilities but it seems to > me there's some discussion about this topic from time to time. > > After all this is a problem at application level, not driver level. > If I'm wrong please correct me. > And maybe you want to read the vdr mailing list... > > Regards, > Lars. > > > > > The drivers seem to detect the card OK as seen in dmesg output: > > > > [7.501729] cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.9 > loaded > > [7.503174] cx88[0]: subsystem: 0070:6902, board: Hauppauge > WinTV-HVR4000 DVB-S/S2/T/Hybrid [card=68,autodetected], frontend(s): 2 > > [7.503373] cx88[0]: TV tuner type 63, Radio tuner type -1 > > [7.551718] i915 :00:02.0: PCI INT A -> GSI 16 (level, low) > > -> > IRQ 16 > > [7.5517
Re: [vdr] VDR and Hybrid DVB Cards ( was "HVR 4000 drivers broken - adapter0/frontend1 busy" in linux-media list )
2011/11/15 Hawes, Mark : >>What i got from previous discussions on linux-media is, that if the >> device nodes are created within one adapter, an application needs to >> assume that >> the devices can not be used concurrently and needs to close >> one "device node group" before opening the other one. >> > This suggests a constraint in the current design of the way VDR handles > the detection and use of DVB devices in that it cannot handle so called > 'hybrid' cards where two (or more!) frontends are attached via a single > adaptor without restarting VDR and identifying which frontend to use. > > As already mentioned I wish to use both cards on my system and I'd be > interested and happy to help in developing a patch to overcome this > constraint. However I would need some VDR architectural guidance to > suggest how this might be done with minimal disruption to the current > DVB device handling. Any direction would be much appreciated. What i said above is AFAIK more or less undocumented up to now. But it seems to be a consensus between most driver developers now. Yes vdr needs to change to handle this devices properly based on the previous assumptions, i think soneone else can be more helpful than me ;). ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr-xine-plugin and LATM AAC
hello, is there a patch for vdr-xine-plugin to do the repack LATM AAC audio as e-ac3 patch. xine-lib-1.2 already supports and works very well in my recordings with LATM HE-AAC but not live tv. how can I do a debug, has changed on vdr172remux.c / / Set this to 'true' for debug output: DebugPatPmt static bool = true; but does not report anything unusual, just send the audio as an MPEG audio layer 2 (lib: MAD) for xine-ui. just see this: [v] VMAMMbuffered -214.2 frames (v:111.4, a:-214.2) < DiscontinuityDetected: triggering soft start [v] VAbuffered 56.6 frames (v:86.4, a:56.6) buffered -35.6 frames (v:146.0, a:-35.6) < DiscontinuityDetected: triggering soft start [VM] MMAMMbuffered 105.9 frames (v:243.7, a:105.9) < DiscontinuityDetected: triggering soft start best regards ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR and Hybrid DVB Cards ( was "HVR 4000 drivers broken - adapter0/frontend1 busy" in linux-media list )
Hi, I am an HVR4000 owner too. Re: VDR internals I'm no expert but the basic assumption is that all devices are available at all time. This assumption has implications for e.g. timers, epg scans, multi-clients etc. This assumption breaks with the HVR4000. Basic use to watch one channel at a time with VDR switching between T and S devices as appropriate is the most simple case. But a corner case considering wider use-cases of VDR. Practical advice Get a dedicated T or S receiver to be able to receive T and S with vanilla VDR. To exercise the HVR4000 re: integration of multi-frontends may involve a long wait for development. Existing patches There had been some work a while ago reported in this forum (search this forum for something like 'multi frontends'), don't know current status. Regards, Ian. Sent from my HTC - Reply message - From: "Steffen Barszus" Date: Tue, Nov 15, 2011 10:52 Subject: [vdr] VDR and Hybrid DVB Cards ( was "HVR 4000 drivers broken - adapter0/frontend1 busy" in linux-media list ) To: "VDR Mailing List" 2011/11/15 Hawes, Mark : >>What i got from previous discussions on linux-media is, that if the >> device nodes are created within one adapter, an application needs to >> assume that >> the devices can not be used concurrently and needs to close >> one "device node group" before opening the other one. >> > This suggests a constraint in the current design of the way VDR handles > the detection and use of DVB devices in that it cannot handle so called > 'hybrid' cards where two (or more!) frontends are attached via a single > adaptor without restarting VDR and identifying which frontend to use. > > As already mentioned I wish to use both cards on my system and I'd be > interested and happy to help in developing a patch to overcome this > constraint. However I would need some VDR architectural guidance to > suggest how this might be done with minimal disruption to the current > DVB device handling. Any direction would be much appreciated. What i said above is AFAIK more or less undocumented up to now. But it seems to be a consensus between most driver developers now. Yes vdr needs to change to handle this devices properly based on the previous assumptions, i think soneone else can be more helpful than me ;). ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR and Hybrid DVB Cards ( was "HVR 4000 drivers broken - adapter0/frontend1 busy" in linux-media list )
This is starting to sound like a big overhaul. If that's the case, maybe it should go one step further and compartmentalize all the settings so VDR can take the next step and provide a true server/client option. ;) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR and Hybrid DVB Cards ( was "HVR 4000 drivers broken - adapter0/frontend1 busy" in linux-media list )
Am 15.11.2011 11:52, schrieb Steffen Barszus: 2011/11/15 Hawes, Mark: What i got from previous discussions on linux-media is, that if the device nodes are created within one adapter, an application needs to assume that the devices can not be used concurrently and needs to close one "device node group" before opening the other one. This suggests a constraint in the current design of the way VDR handles the detection and use of DVB devices in that it cannot handle so called 'hybrid' cards where two (or more!) frontends are attached via a single adaptor without restarting VDR and identifying which frontend to use. As already mentioned I wish to use both cards on my system and I'd be interested and happy to help in developing a patch to overcome this constraint. However I would need some VDR architectural guidance to suggest how this might be done with minimal disruption to the current DVB device handling. Any direction would be much appreciated. What i said above is AFAIK more or less undocumented up to now. But it seems to be a consensus between most driver developers now. Yes vdr needs to change to handle this devices properly based on the previous assumptions, i think soneone else can be more helpful than me ;). I'm just preparing a test environment for extending the vdr to use multi-frontend devices. Good to know that there are drivers which behaves different in creating device nodes. The Cine-C/T cards for example creates only one demux/dvr node and two frontends. Soon I will have my hands on such a device. If I can get a patch working for this card it's only a small step to support the HVR 4000, two. I have already dealt with vdr devices and have some knowledge about the concepts. I developed the dynamite plugin which extends vdr with some device hotplugging capabilities. It also requires patching the vdr. But with this you can use both devices without restarting vdr and affecting timers and recordings. But for now there's no automatism so that the right device for the watched/recorded channel is attached. Please have a look at the README if you're interested. If you have questions, just ask. http://projects.vdr-developer.org/projects/plg-dynamite https://github.com/flensrocker/vdr-plugin-dynamite If you want to develop something on your own, start reading device.[hc] and dvbdevice.[hc] at the vdr source. I definitly will try to develop a "multi-frontend-patch" but spare time is always rare. I will reserve one evening per week for this. And I hope to finish it till christmas. ;-) If you have ideas please let me know. I'm looking for some inspiration for storing the different frontend capabilities at the cDvbDevice and how to maintain the different cDvbTuner objects. My experience while working on dynamite will help me in particular since I invested some time on closing/reopening the file handles at the right places. Hotplugging "single frontend" devices seems to be a good first step towards the solution of this problem. Lars. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR and Hybrid DVB Cards ( was "HVR 4000 drivers broken - adapter0/frontend1 busy" in linux-media list )
-Original Message- From: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] On Behalf Of L. Hanisch Sent: Wednesday, 16 November 2011 5:51 AM To: vdr@linuxtv.org Subject: Re: [vdr] VDR and Hybrid DVB Cards ( was "HVR 4000 drivers broken - adapter0/frontend1 busy" in linux-media list ) >Am 15.11.2011 11:52, schrieb Steffen Barszus: >> 2011/11/15 Hawes, Mark: What i got from previous discussions on linux-media is, that if the device nodes are created within one adapter, an application needs to assume that the devices can not be used concurrently and needs to close one "device node group" before opening the other one. >>> This suggests a constraint in the current design of the way VDR >>> handles the detection and use of DVB devices in that it cannot handle >>> so called 'hybrid' cards where two (or more!) frontends are attached >>> via a single adaptor without restarting VDR and identifying which frontend to use. >>> >>> As already mentioned I wish to use both cards on my system and I'd be >>> interested and happy to help in developing a patch to overcome this >>> constraint. However I would need some VDR architectural guidance to >>> suggest how this might be done with minimal disruption to the current >>> DVB device handling. Any direction would be much appreciated. >> >> What i said above is AFAIK more or less undocumented up to now. But it > >seems to be a consensus between most driver developers now. >> >> Yes vdr needs to change to handle this devices properly based on the >> previous assumptions, i think soneone else can be more helpful than me > >;). > > I'm just preparing a test environment for extending the vdr to use multi-frontend devices. Good to know that there are drivers which behaves >different in creating device nodes. The Cine-C/T cards for example creates only one demux/dvr node and two frontends. Soon I will have my hands >on such a device. If I can get a patch working for this card it's only a small step to support the HVR 4000, two. > I agree that any such solution should not be card specific but apply in general to cards with various adapter 'architectures'. I can offer my system as a HVR 4000 testbed for such a development. > > I have already dealt with vdr devices and have some knowledge about the concepts. I developed the dynamite plugin which extends vdr with some >device hotplugging capabilities. It also requires patching the vdr. But with this you can use both devices without restarting vdr and affecting timers >and recordings. But for now there's no automatism so that the right device for the watched/recorded channel is attached. Please have a look at the >README if you're interested. If you have questions, just ask. > > 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. 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. > > If you want to develop something on your own, start reading device.[hc] and dvbdevice.[hc] at the vdr source. > I definitly will try to develop a "multi-frontend-patch" but spare time is always rare. I will reserve one evening per week for this. And I hope to >finish it till christmas. ;-) > As indicated above I'd be happy to test anything you come up with. > > If you have ideas please let me know. I'm looking for some inspiration for storing the different frontend capabilities at the cDvbDevice and how to >maintain the different cDvbTuner objects. My experience while working on dynamite will help me in particular since I invested some time on >closing/reopening the file handles at the right places. Hotplugging "single frontend" devices seems to be a good first step towards the solution of >this problem. > >Lars. 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. 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
Re: [vdr] VDR and Hybrid DVB Cards ( was "HVR 4000 drivers broken - adapter0/frontend1 busy" in linux-media list )
On 15.11.2011, at 23:29, "Hawes, Mark" wrote: > -Original Message- > From: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] On Behalf > Of L. Hanisch > Sent: Wednesday, 16 November 2011 5:51 AM > To: vdr@linuxtv.org > Subject: Re: [vdr] VDR and Hybrid DVB Cards ( was "HVR 4000 drivers > broken - adapter0/frontend1 busy" in linux-media list ) > >> Am 15.11.2011 11:52, schrieb Steffen Barszus: >>> 2011/11/15 Hawes, Mark: > What i got from previous discussions on linux-media is, that if the > > device nodes are created within one adapter, an application needs > to > assume that the devices can not be used concurrently and needs to > close one "device node group" before opening the other one. > This suggests a constraint in the current design of the way VDR handles the detection and use of DVB devices in that it cannot > handle so called 'hybrid' cards where two (or more!) frontends are attached > via a single adaptor without restarting VDR and identifying which > frontend to use. As already mentioned I wish to use both cards on my system and I'd > be interested and happy to help in developing a patch to overcome this constraint. However I would need some VDR architectural guidance to suggest how this might be done with minimal disruption to the > current DVB device handling. Any direction would be much appreciated. >>> >>> What i said above is AFAIK more or less undocumented up to now. But > it >>> seems to be a consensus between most driver developers now. >>> >>> Yes vdr needs to change to handle this devices properly based on the >>> previous assumptions, i think soneone else can be more helpful than > me >>> ;). >> >> I'm just preparing a test environment for extending the vdr to use > multi-frontend devices. Good to know that there are drivers which > behaves >different in creating device nodes. The Cine-C/T cards for > example creates only one demux/dvr node and two frontends. Soon I will > have my hands >on such a device. If I can get a patch working for this > card it's only a small step to support the HVR 4000, two. >> > I agree that any such solution should not be card specific but apply in > general to cards with various adapter 'architectures'. I can offer my > system as a HVR 4000 testbed for such a development. >> >> I have already dealt with vdr devices and have some knowledge about > the concepts. I developed the dynamite plugin which extends vdr with > some >device hotplugging capabilities. It also requires patching the > vdr. But with this you can use both devices without restarting vdr and > affecting timers >and recordings. But for now there's no automatism so > that the right device for the watched/recorded channel is attached. > Please have a look at the >README if you're interested. If you have > questions, just ask. >> >> 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. > > 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. >> >> If you want to develop something on your own, start reading > device.[hc] and dvbdevice.[hc] at the vdr source. >> I definitly will try to develop a "multi-frontend-patch" but spare > time is always rare. I will reserve one evening per week for this. And I > hope to >finish it till christmas. ;-) >> > As indicated above I'd be happy to test anything you come up with. >> >> If you have ideas please let me know. I'm looking for some > inspiration for storing the different frontend capabilities at the > cDvbDevice and how to >maintain the different cDvbTuner objects. My > experience while working on dynamite will help me in particular since I > invested some time on >closing/reopening the file handles at the right > places. Hotplugging "single frontend" devices seems to be a good first > step towards the solution of >this problem. >> >> Lars. > > 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. > > The comment above from Steffen seems to make some sense ' if the device > nodes are created within one adapter an
Re: [vdr] VDR and Hybrid DVB Cards ( was "HVR 4000 drivers broken - adapter0/frontend1 busy" in linux-media list )
On Wed, Nov 16, 2011 at 4:38 AM, Klaus Schmidinger wrote: > > That is also my understanding of multi frontend devices. > If an "adapter" has several "frontends" only one of them can > be active at any given time. This has nothing to do with > any "explosives" (excuse the pun ;-) and will be implemented > in the core VDR code as time permits. Right now I'm cleaning up > the "lnb sharing" (aka "device bonding") stuff and will hopefully > find more time for VDR development by the end of the year (and > thereafter). If I am following you correctly, There is one issue however. If an adapter can have only a single frontend, then there will exist another issue: - Card has dual multi standard frontend(s). - Card has CI cards on both the paths (2 CI controllers) - Card provides scrambled stream as well as descrambled stream (4 simultaneous streams) - Card needs to swap between the CI modules to take advantage of the different modules, rather than reconnecting antenna inputs/manually swapping the CI modules. Eventually, to handle such a situation: all the nodes exposed to the application has to be under the "same" adapter, rather than as 4 different adapters, of which 2 of them won't have any frontend or ca devices. Regards, Manu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
