Re: [vdr] VDR and Hybrid DVB Cards ( was "HVR 4000 drivers broken - adapter0/frontend1 busy" in linux-media list )
On 19.11.2011 17:15, L. Hanisch wrote: Am 18.11.2011 19:03, schrieb Klaus Schmidinger: On 16.11.2011 23:59, L. Hanisch wrote: Am 16.11.2011 23:26, schrieb Klaus Schmidinger: On 16.11.2011 19:16, L. Hanisch wrote: Am 16.11.2011 00:08, schrieb Klaus Schmidinger: 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 you don't mind I would try to prefabricate something. On a first guess: would you combine the multiple frontends of an adapter in one cDvbDevice? I think this would be better than having multiple cDvbDevices which must interact somehow with each other. Sure there will be one cDvbDevice per adapter for a multi-frontend device where only one frontend can be active at any time. If (like on the TT-S2 6400) there are several frontends that can be active simultaneously, then there shall be separate adapters for each frontend, and thus a separate cDvbDevice for each adapter. Here's a first "quick'n'dirty" patch. Since my hardware hasn't arrived yet I tested with a DVB-T and DVB-C stick and sym-linked the devices within one adapter. I have no ca-devices in this setup. Switching between C and T channels works here, but it's not really tested with timers/recordings etc. I don't have a FF card, so the patches for the plugins are more of "remove compiler warnings" only. One have to think about cDvbDeviceProbe and the parameters. A frontend argument doesn't make much sense now. Note, though, that support for such devices will most likely not go into VDR for version 2. I'm trying to wrap things up in order to make a stable version 2, and after that will address new things like this. I'm fine with this and looking forward to it. A new stable release would be fine! Xmas is next door... :) I've received an email from Manu Abraham, informing me that he intends to change the driver in such a way that there will always be only *one* frontend, even if it can handle multiple delivery systems. So every frontend an adapter will provide will always be useable independent of all other frontends of that adapter. Personally, I like this method more than having separate frontends for each delivery system, and having to manage access between them. Just wanted to let you know that the official implementation in VDR (most likely after version 2.0) will go a different way than your patch. I followed the discussion on linux-media. But since it's a new ioctl some kind of backport would be needed and also a workaround for drivers which doesn't provide the new ioctl. One frontend per adapter would be very nice. And in case of dual tuner cards I would expect two adapters since they are independent from each other. If they are combined in one adapter they cannot be distinguished from "old" adapters with mutually exclusive frontends - and things would be dirtier as is. :) Right now VDR considers every frontend to be available independently of any other, be it an adapter with only a single frontend or one with several ones. There is no handling for frontends with different delivery systems (except for DVB-S/DVB-S2, but that's pretty much the same). Support for frontends with several delivery systems will become available once the driver supports them in the way Manu described. There is no need for any backwards compatibility ;-) Those who want to use devices with multi-delivery-system frontends will just have to use the new driver. Of course VDR will continue to work with the current driver, but only by considering all frontends "single delivery-system". Klaus ___ 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 18.11.2011 19:03, schrieb Klaus Schmidinger: On 16.11.2011 23:59, L. Hanisch wrote: Am 16.11.2011 23:26, schrieb Klaus Schmidinger: On 16.11.2011 19:16, L. Hanisch wrote: Am 16.11.2011 00:08, schrieb Klaus Schmidinger: 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 you don't mind I would try to prefabricate something. On a first guess: would you combine the multiple frontends of an adapter in one cDvbDevice? I think this would be better than having multiple cDvbDevices which must interact somehow with each other. Sure there will be one cDvbDevice per adapter for a multi-frontend device where only one frontend can be active at any time. If (like on the TT-S2 6400) there are several frontends that can be active simultaneously, then there shall be separate adapters for each frontend, and thus a separate cDvbDevice for each adapter. Here's a first "quick'n'dirty" patch. Since my hardware hasn't arrived yet I tested with a DVB-T and DVB-C stick and sym-linked the devices within one adapter. I have no ca-devices in this setup. Switching between C and T channels works here, but it's not really tested with timers/recordings etc. I don't have a FF card, so the patches for the plugins are more of "remove compiler warnings" only. One have to think about cDvbDeviceProbe and the parameters. A frontend argument doesn't make much sense now. Note, though, that support for such devices will most likely not go into VDR for version 2. I'm trying to wrap things up in order to make a stable version 2, and after that will address new things like this. I'm fine with this and looking forward to it. A new stable release would be fine! Xmas is next door... :) I've received an email from Manu Abraham, informing me that he intends to change the driver in such a way that there will always be only *one* frontend, even if it can handle multiple delivery systems. So every frontend an adapter will provide will always be useable independent of all other frontends of that adapter. Personally, I like this method more than having separate frontends for each delivery system, and having to manage access between them. Just wanted to let you know that the official implementation in VDR (most likely after version 2.0) will go a different way than your patch. I followed the discussion on linux-media. But since it's a new ioctl some kind of backport would be needed and also a workaround for drivers which doesn't provide the new ioctl. One frontend per adapter would be very nice. And in case of dual tuner cards I would expect two adapters since they are independent from each other. If they are combined in one adapter they cannot be distinguished from "old" adapters with mutually exclusive frontends - and things would be dirtier as is. :) In the meantime I will polish my patch a bit and rework on the changes which breaks existing plugins. It was just a first try anyway. Lars. Klaus ___ 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 )
On Sat, 19 Nov 2011 00:40:30 +0200 Mika Laitio wrote: > > I've received an email from Manu Abraham, informing > > me that he intends to change the driver in such a way that there > > will always > > be only *one* frontend, even if it can handle multiple delivery > > systems. So every frontend an adapter will provide will always be > > useable independent > > of all other frontends of that adapter. > > Personally, I like this method more than having separate frontends > > for each delivery system, and having to manage access between them. > > > > Just wanted to let you know that the official implementation in VDR > > (most likely after version 2.0) will go a different way than your > > patch. > > I am wondering what's the reason of breaking this current rule as it > sounded so clear...So if cards all delivery systems are mapped as an > adapters under same frontend, there must be a some method for querying > which of those adapters are tied together. Did Manu say whether that > info can be get via dev tree, via sysfs or by using some new ioctl? If Manu is successful in what he is trying (and existing driver following other rules will be ported) then that sounds fine to me. I dont care what solution , but i care for having one. > And if the patch wont go in, it means that hvr-4000 owners needs to > maintain in addition of the vdr-patch, also a patches for all plugins > that the patch breaks :-(. On the other hand, if the patch would be > accepted to vdr before 2.0, I am sure that all plugi-ns would be > adapter to work in couple of weeks to work with the new interfaces. Its not a drama if on the other hand above happens. If above happens than vdr needs only to adapt to shared ca devices (which are implemented as i.e. caio0 & ca0 and need some special handling from vdr side. ___ 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 )
On 18.11.2011 23:40, Mika Laitio wrote: I've received an email from Manu Abraham, informing me that he intends to change the driver in such a way that there will always be only *one* frontend, even if it can handle multiple delivery systems. So every frontend an adapter will provide will always be useable independent of all other frontends of that adapter. Personally, I like this method more than having separate frontends for each delivery system, and having to manage access between them. Just wanted to let you know that the official implementation in VDR (most likely after version 2.0) will go a different way than your patch. I am wondering what's the reason of breaking this current rule as it sounded so clear...So if cards all delivery systems are mapped as an adapters under same frontend, there must be a some method for querying which of those adapters are tied together. Did Manu say whether that info can be get via dev tree, via sysfs or by using some new ioctl? That was my misunderstanding in the beginning, too, and it resulted in a lengthy discussion with Manu ;-) From what I understood, every physical device (i.e. a DVB PCI card, a USB receiver or whatever) will be exactly *one* adapter. If an adapter provides several delivery systems (like, for instance, DVB-S and DVB-T) and only one of these can be used at a time, there will be *one* frontend that needs to be switched to the desired delivery system before tuning to a transponder. A new ioctl() will allow the application to query which and how many delivery systems a frontend provides. If the adapter has like two DVB-S tuners that can be used simultaneously, then it will have two separate frontends. And if the patch wont go in, it means that hvr-4000 owners needs to maintain in addition of the vdr-patch, also a patches for all plugins that the patch breaks :-(. On the other hand, if the patch would be accepted to vdr before 2.0, I am sure that all plugi-ns would be adapter to work in couple of weeks to work with the new interfaces. From what I understand at this time I don't see why implementing multi-frontend support would break any plugins. Lars' patch apparently does, but my goal would be to make this totally seemless, so plugins wouldn't even notice. Right now I have only very little (if any) time to work on VDR, because my daytime job requires all my attention. This will change by the end of the year, and then we'll see whether Manu's patch has made it into the driver and whether this can be used for VDR 2.0. Personally I hope Manu's implementation gets adopted, because I find it very straightforward. Klaus ___ 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 )
> I've received an email from Manu Abraham, informing > me that he intends to change the driver in such a way that there will > always > be only *one* frontend, even if it can handle multiple delivery systems. > So every frontend an adapter will provide will always be useable > independent > of all other frontends of that adapter. > Personally, I like this method more than having separate frontends for > each delivery system, and having to manage access between them. > > Just wanted to let you know that the official implementation in VDR > (most likely after version 2.0) will go a different way than your patch. I am wondering what's the reason of breaking this current rule as it sounded so clear...So if cards all delivery systems are mapped as an adapters under same frontend, there must be a some method for querying which of those adapters are tied together. Did Manu say whether that info can be get via dev tree, via sysfs or by using some new ioctl? And if the patch wont go in, it means that hvr-4000 owners needs to maintain in addition of the vdr-patch, also a patches for all plugins that the patch breaks :-(. On the other hand, if the patch would be accepted to vdr before 2.0, I am sure that all plugi-ns would be adapter to work in couple of weeks to work with the new interfaces. Mika ___ 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 )
On 16.11.2011 23:59, L. Hanisch wrote: Am 16.11.2011 23:26, schrieb Klaus Schmidinger: On 16.11.2011 19:16, L. Hanisch wrote: Am 16.11.2011 00:08, schrieb Klaus Schmidinger: 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 you don't mind I would try to prefabricate something. On a first guess: would you combine the multiple frontends of an adapter in one cDvbDevice? I think this would be better than having multiple cDvbDevices which must interact somehow with each other. Sure there will be one cDvbDevice per adapter for a multi-frontend device where only one frontend can be active at any time. If (like on the TT-S2 6400) there are several frontends that can be active simultaneously, then there shall be separate adapters for each frontend, and thus a separate cDvbDevice for each adapter. Here's a first "quick'n'dirty" patch. Since my hardware hasn't arrived yet I tested with a DVB-T and DVB-C stick and sym-linked the devices within one adapter. I have no ca-devices in this setup. Switching between C and T channels works here, but it's not really tested with timers/recordings etc. I don't have a FF card, so the patches for the plugins are more of "remove compiler warnings" only. One have to think about cDvbDeviceProbe and the parameters. A frontend argument doesn't make much sense now. Note, though, that support for such devices will most likely not go into VDR for version 2. I'm trying to wrap things up in order to make a stable version 2, and after that will address new things like this. I'm fine with this and looking forward to it. A new stable release would be fine! Xmas is next door... :) I've received an email from Manu Abraham, informing me that he intends to change the driver in such a way that there will always be only *one* frontend, even if it can handle multiple delivery systems. So every frontend an adapter will provide will always be useable independent of all other frontends of that adapter. Personally, I like this method more than having separate frontends for each delivery system, and having to manage access between them. Just wanted to let you know that the official implementation in VDR (most likely after version 2.0) will go a different way than your patch. Klaus ___ 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 )
My apologies - the dvbhddevice and dvbsddevice plugins are OK, I was using versions I copied across and were unpatched. Mark. -Original Message- From: Hawes, Mark Sent: Friday, 18 November 2011 5:54 PM To: 'VDR Mailing List' Subject: RE: [vdr] VDR and Hybrid DVB Cards ( was "HVR 4000 drivers broken - adapter0/frontend1 busy" in linux-media list ) Hi Lars, Some results from further testing: - "live viewing with switching channels between frontends": Works OK, with about a 3 second delay switching from terrestrial to satellite and about 10 seconds going the other way. The timings are pretty consistent and I put the difference down to the time to lock being significantly longer for satellite. - "timer recording starts while viewing live TV on the other frontend": Seems to behave reasonably. The screen goes blank and eventually the picture is replaced with what appears to be that of the first channel on the transponder that we are now recording. It stays there even after the recording completes. The same behaviour is experienced when going either way, e.g. viewing terrestrial when satellite recording starts or viewing satellite when terrestrial recording starts. Have not played with timer conflicts yet. Now, the problem: It's broken a number of plugins which no longer compile. These include dvbhddevice, dvbsddevice, dvd, osdpip, Rotorng, sc and upnp which I use but I'm sure a number of others will be affected. The primary reason appears to be the redefinition of cDvbDevice, but some other errors are also reported. Is this redefinition the 'dirty' part of this initial attempt, or is it fundamental to the approach? If it's the latter I suspect it will be very problematic for many users of affected plugins as these will need to be modified to conform. Regards, Mark. -Original Message- From: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] On Behalf Of L. Hanisch Sent: Friday, 18 November 2011 4:44 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 ) Hi, Am 17.11.2011 11:02, schrieb Hawes, Mark: > Hi Lars, > > Thanks for the patch. > Basically, it seems to work for the HVR 4000. Both front ends are > detected successfully, and both can be used. I'm using it with the > xineliboutput plugin and it seems to co-exist OK. Nice to hear. > Starting a recording on one prevents a channel switch to the other > with the "Channel not available message". However, when doing so the > screen goes black and its necessary to retune the recorded channel to > get the picture back. Not a big issue, more an annoyance. Ok, I will try to reproduce this. It may be (since the device hasn't changed) vdr is thinking that it's showing an available channel or something like this. > I'll be playing with it in the next couple of days including > introducing a SD premium card into the mix to see what happens. Is > there anything in particular that you would like me to try? I haven't made too much thoughts about tests. Maybe we can work on a checklist together. use cases: - live viewing with switching channels between frontends - timer recording starts while viewing live tv on the other frontend - timer conflicts with different priorities on the different frontends - streamdev-client/-server? - ...? It looks like the HVR 4000 has no CI. At the moment I don't have access to cards with decryption hardware, too. And I'm not too familiar with this part of the vdr (ci/cam etc.). Lars. > > Thanks, > > Mark. > -Original Message- > From: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] On > Behalf Of L. Hanisch > Sent: Thursday, 17 November 2011 9:59 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 16.11.2011 23:26, schrieb Klaus Schmidinger: >> On 16.11.2011 19:16, L. Hanisch wrote: >>> Am 16.11.2011 00:08, schrieb Klaus Schmidinger: >>>> 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 you don't mind I would try to prefabricate some
Re: [vdr] VDR and Hybrid DVB Cards ( was "HVR 4000 drivers broken - adapter0/frontend1 busy" in linux-media list )
Hi Lars, Some results from further testing: - "live viewing with switching channels between frontends": Works OK, with about a 3 second delay switching from terrestrial to satellite and about 10 seconds going the other way. The timings are pretty consistent and I put the difference down to the time to lock being significantly longer for satellite. - "timer recording starts while viewing live TV on the other frontend": Seems to behave reasonably. The screen goes blank and eventually the picture is replaced with what appears to be that of the first channel on the transponder that we are now recording. It stays there even after the recording completes. The same behaviour is experienced when going either way, e.g. viewing terrestrial when satellite recording starts or viewing satellite when terrestrial recording starts. Have not played with timer conflicts yet. Now, the problem: It's broken a number of plugins which no longer compile. These include dvbhddevice, dvbsddevice, dvd, osdpip, Rotorng, sc and upnp which I use but I'm sure a number of others will be affected. The primary reason appears to be the redefinition of cDvbDevice, but some other errors are also reported. Is this redefinition the 'dirty' part of this initial attempt, or is it fundamental to the approach? If it's the latter I suspect it will be very problematic for many users of affected plugins as these will need to be modified to conform. Regards, Mark. -Original Message- From: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] On Behalf Of L. Hanisch Sent: Friday, 18 November 2011 4:44 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 ) Hi, Am 17.11.2011 11:02, schrieb Hawes, Mark: > Hi Lars, > > Thanks for the patch. > Basically, it seems to work for the HVR 4000. Both front ends are > detected successfully, and both can be used. I'm using it with the > xineliboutput plugin and it seems to co-exist OK. Nice to hear. > Starting a recording on one prevents a channel switch to the other > with the "Channel not available message". However, when doing so the > screen goes black and its necessary to retune the recorded channel to > get the picture back. Not a big issue, more an annoyance. Ok, I will try to reproduce this. It may be (since the device hasn't changed) vdr is thinking that it's showing an available channel or something like this. > I'll be playing with it in the next couple of days including > introducing a SD premium card into the mix to see what happens. Is > there anything in particular that you would like me to try? I haven't made too much thoughts about tests. Maybe we can work on a checklist together. use cases: - live viewing with switching channels between frontends - timer recording starts while viewing live tv on the other frontend - timer conflicts with different priorities on the different frontends - streamdev-client/-server? - ...? It looks like the HVR 4000 has no CI. At the moment I don't have access to cards with decryption hardware, too. And I'm not too familiar with this part of the vdr (ci/cam etc.). Lars. > > Thanks, > > Mark. > -Original Message- > From: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] On > Behalf Of L. Hanisch > Sent: Thursday, 17 November 2011 9:59 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 16.11.2011 23:26, schrieb Klaus Schmidinger: >> On 16.11.2011 19:16, L. Hanisch wrote: >>> Am 16.11.2011 00:08, schrieb Klaus Schmidinger: >>>> 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 you don't mind I would try to prefabricate something. >>> On a first guess: would you combine the multiple frontends of an >>> adapter in one cDvbDevice? I think this would be better than having > multiple cDvbDevices which must interact somehow with each other. >> >> Sure there will be one cDvbDevice per adapter for a multi-frontend >> device where only one frontend can be active at
Re: [vdr] VDR and Hybrid DVB Cards ( was "HVR 4000 drivers broken - adapter0/frontend1 busy" in linux-media list )
Hi, Am 17.11.2011 11:02, schrieb Hawes, Mark: Hi Lars, Thanks for the patch. Basically, it seems to work for the HVR 4000. Both front ends are detected successfully, and both can be used. I'm using it with the xineliboutput plugin and it seems to co-exist OK. Nice to hear. Starting a recording on one prevents a channel switch to the other with the "Channel not available message". However, when doing so the screen goes black and its necessary to retune the recorded channel to get the picture back. Not a big issue, more an annoyance. Ok, I will try to reproduce this. It may be (since the device hasn't changed) vdr is thinking that it's showing an available channel or something like this. I'll be playing with it in the next couple of days including introducing a SD premium card into the mix to see what happens. Is there anything in particular that you would like me to try? I haven't made too much thoughts about tests. Maybe we can work on a checklist together. use cases: - live viewing with switching channels between frontends - timer recording starts while viewing live tv on the other frontend - timer conflicts with different priorities on the different frontends - streamdev-client/-server? - ...? It looks like the HVR 4000 has no CI. At the moment I don't have access to cards with decryption hardware, too. And I'm not too familiar with this part of the vdr (ci/cam etc.). Lars. Thanks, Mark. -Original Message- From: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] On Behalf Of L. Hanisch Sent: Thursday, 17 November 2011 9:59 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 16.11.2011 23:26, schrieb Klaus Schmidinger: On 16.11.2011 19:16, L. Hanisch wrote: Am 16.11.2011 00:08, schrieb Klaus Schmidinger: 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 you don't mind I would try to prefabricate something. On a first guess: would you combine the multiple frontends of an adapter in one cDvbDevice? I think this would be better than having multiple cDvbDevices which must interact somehow with each other. Sure there will be one cDvbDevice per adapter for a multi-frontend device where only one frontend can be active at any time. If (like on the TT-S2 6400) there are several frontends that can be active simultaneously, then there shall be separate adapters for each frontend, and thus a separate cDvbDevice for each adapter. Here's a first "quick'n'dirty" patch. Since my hardware hasn't arrived yet I tested with a DVB-T and DVB-C stick and sym-linked the devices within one adapter. I have no ca-devices in this setup. Switching between C and T channels works here, but it's not really tested with timers/recordings etc. I don't have a FF card, so the patches for the plugins are more of "remove compiler warnings" only. One have to think about cDvbDeviceProbe and the parameters. A frontend argument doesn't make much sense now. Note, though, that support for such devices will most likely not go into VDR for version 2. I'm trying to wrap things up in order to make a stable version 2, and after that will address new things like this. I'm fine with this and looking forward to it. A new stable release would be fine! Xmas is next door... :) Lars. ___ 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 )
Hi Lars, Thanks for the patch. Basically, it seems to work for the HVR 4000. Both front ends are detected successfully, and both can be used. I'm using it with the xineliboutput plugin and it seems to co-exist OK. Starting a recording on one prevents a channel switch to the other with the "Channel not available message". However, when doing so the screen goes black and its necessary to retune the recorded channel to get the picture back. Not a big issue, more an annoyance. I'll be playing with it in the next couple of days including introducing a SD premium card into the mix to see what happens. Is there anything in particular that you would like me to try? Thanks, Mark. -Original Message- From: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] On Behalf Of L. Hanisch Sent: Thursday, 17 November 2011 9:59 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 16.11.2011 23:26, schrieb Klaus Schmidinger: > On 16.11.2011 19:16, L. Hanisch wrote: >> Am 16.11.2011 00:08, schrieb Klaus Schmidinger: >>> 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 you don't mind I would try to prefabricate something. >> On a first guess: would you combine the multiple frontends of an >> adapter in one cDvbDevice? I think this would be better than having multiple cDvbDevices which must interact somehow with each other. > > Sure there will be one cDvbDevice per adapter for a multi-frontend > device where only one frontend can be active at any time. > If (like on the TT-S2 6400) there are several frontends that can be > active simultaneously, then there shall be separate adapters for each > frontend, and thus a separate cDvbDevice for each adapter. Here's a first "quick'n'dirty" patch. Since my hardware hasn't arrived yet I tested with a DVB-T and DVB-C stick and sym-linked the devices within one adapter. I have no ca-devices in this setup. Switching between C and T channels works here, but it's not really tested with timers/recordings etc. I don't have a FF card, so the patches for the plugins are more of "remove compiler warnings" only. One have to think about cDvbDeviceProbe and the parameters. A frontend argument doesn't make much sense now. > Note, though, that support for such devices will most likely not go > into VDR for version 2. I'm trying to wrap things up in order to make > a stable version 2, and after that will address new things like this. I'm fine with this and looking forward to it. A new stable release would be fine! Xmas is next door... :) 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 )
On Thu, 17 Nov 2011 10:10:34 +0530 Manu Abraham wrote: > On Wed, Nov 16, 2011 at 6:30 PM, Steffen Barszus > > To my understanding the mentioned use case would have - according to > > linux-media project logic of how to handle this - would look like > > > > /dev/dvb/adapter0/frontend0 > > /dev/dvb/adapter0/frontend1 > > /dev/dvb/adapter0/demux0 > > ... > > /dev/dvb/adapter0/ca0 > > /dev/dvb/adapter1/frontend0 > > /dev/dvb/adapter1/frontend1 > > /dev/dvb/adapter1/demux0 > > ... > > /dev/dvb/adapter1/ca0 > > > > so it would be 2 adapter with 4 frontends. If for some reason they > > should be in one adapter how to distinguish between the different > > cases ? Maybe i did not understand properly the issue. > > > The very same driver can have 4 real frontends too. By now the issue > got complicated too far by the logic mentioned above: So, how will you > distinguish between real functional and independant adapters, then > (when having multiple adapters) ? Listen Manu, i'm not proposing anything here - i try only to reflect what i read on linux-media mailinglist. If you have different opinion/suggestion/understanding i would be thankful if you could provide some better input on how vdr needs to handle this. ___ 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 )
On Wed, Nov 16, 2011 at 6:30 PM, Steffen Barszus wrote: > 2011/11/16 Manu Abraham : >> 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. > > To my understanding the mentioned use case would have - according to > linux-media project logic of how to handle this - would look like > > /dev/dvb/adapter0/frontend0 > /dev/dvb/adapter0/frontend1 > /dev/dvb/adapter0/demux0 > ... > /dev/dvb/adapter0/ca0 > /dev/dvb/adapter1/frontend0 > /dev/dvb/adapter1/frontend1 > /dev/dvb/adapter1/demux0 > ... > /dev/dvb/adapter1/ca0 > > so it would be 2 adapter with 4 frontends. If for some reason they > should be in one adapter how to distinguish between the different > cases ? Maybe i did not understand properly the issue. The very same driver can have 4 real frontends too. By now the issue got complicated too far by the logic mentioned above: So, how will you distinguish between real functional and independant adapters, then (when having multiple adapters) ? Manu ___ 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 16.11.2011 23:26, schrieb Klaus Schmidinger:
On 16.11.2011 19:16, L. Hanisch wrote:
Am 16.11.2011 00:08, schrieb Klaus Schmidinger:
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 you don't mind I would try to prefabricate something.
On a first guess: would you combine the multiple frontends of an adapter in one
cDvbDevice? I think this would be
better than having multiple cDvbDevices which must interact somehow with each
other.
Sure there will be one cDvbDevice per adapter for a multi-frontend device
where only one frontend can be active at any time.
If (like on the TT-S2 6400) there are several frontends that can be
active simultaneously, then there shall be separate adapters for each
frontend, and thus a separate cDvbDevice for each adapter.
Here's a first "quick'n'dirty" patch. Since my hardware hasn't arrived yet I tested with a DVB-T and DVB-C stick and
sym-linked the devices within one adapter. I have no ca-devices in this setup.
Switching between C and T channels works here, but it's not really tested with
timers/recordings etc.
I don't have a FF card, so the patches for the plugins are more of "remove compiler warnings" only. One have to think
about cDvbDeviceProbe and the parameters. A frontend argument doesn't make much sense now.
Note, though, that support for such devices will most likely not
go into VDR for version 2. I'm trying to wrap things up in order
to make a stable version 2, and after that will address new things
like this.
I'm fine with this and looking forward to it. A new stable release would be
fine! Xmas is next door... :)
Lars.
diff --git a/PLUGINS/src/dvbhddevice/dvbhdffdevice.c
b/PLUGINS/src/dvbhddevice/dvbhdffdevice.c
index ff3f953..e7fb935 100644
--- a/PLUGINS/src/dvbhddevice/dvbhdffdevice.c
+++ b/PLUGINS/src/dvbhddevice/dvbhdffdevice.c
@@ -26,7 +26,8 @@
int cDvbHdFfDevice::devHdffOffset = -1;
cDvbHdFfDevice::cDvbHdFfDevice(int Adapter, int Frontend)
-:cDvbDevice(Adapter, Frontend)
+:cDvbDevice(Adapter)
+,frontend(Frontend)
{
spuDecoder = NULL;
audioChannel = 0;
diff --git a/PLUGINS/src/dvbhddevice/dvbhdffdevice.h
b/PLUGINS/src/dvbhddevice/dvbhdffdevice.h
index 4dcfb6a..62540da 100644
--- a/PLUGINS/src/dvbhddevice/dvbhdffdevice.h
+++ b/PLUGINS/src/dvbhddevice/dvbhdffdevice.h
@@ -17,12 +17,13 @@
class cDvbHdFfDevice : public cDvbDevice {
private:
+ int frontend;
int fd_osd, fd_audio, fd_video;
protected:
virtual void MakePrimaryDevice(bool On);
public:
static bool Probe(int Adapter, int Frontend);
- cDvbHdFfDevice(int Adapter, int Frontend);
+ cDvbHdFfDevice(int Adapter, int Frontend = 0);
virtual ~cDvbHdFfDevice();
virtual bool HasDecoder(void) const;
diff --git a/PLUGINS/src/dvbsddevice/dvbsdffdevice.c
b/PLUGINS/src/dvbsddevice/dvbsdffdevice.c
index 17f842b..68031b5 100644
--- a/PLUGINS/src/dvbsddevice/dvbsdffdevice.c
+++ b/PLUGINS/src/dvbsddevice/dvbsdffdevice.c
@@ -24,7 +24,8 @@
int cDvbSdFfDevice::devVideoOffset = -1;
cDvbSdFfDevice::cDvbSdFfDevice(int Adapter, int Frontend, bool OutputOnly)
-:cDvbDevice(Adapter, Frontend)
+:cDvbDevice(Adapter)
+,frontend(Frontend)
{
spuDecoder = NULL;
digitalAudio = false;
diff --git a/PLUGINS/src/dvbsddevice/dvbsdffdevice.h
b/PLUGINS/src/dvbsddevice/dvbsdffdevice.h
index bd74cde..c060859 100644
--- a/PLUGINS/src/dvbsddevice/dvbsdffdevice.h
+++ b/PLUGINS/src/dvbsddevice/dvbsdffdevice.h
@@ -16,6 +16,7 @@
class cDvbSdFfDevice : public cDvbDevice {
private:
+ int frontend;
int fd_osd, fd_audio, fd_video, fd_stc;
bool outputOnly;
protected:
diff --git a/dvbci.c b/dvbci.c
index 5289bbd..66dddc8 100644
--- a/dvbci.c
+++ b/dvbci.c
@@ -10,15 +10,18 @@
#include "dvbci.h"
#include
#include
-#include "device.h"
+#include "dvbdevice.h"
// --- cDvbCiAdapter -
-cDvbCiAdapter::cDvbCiAdapter(cDevice *Device, int Fd)
+cDvbCiAdapter::cDvbCiAdapter(cDevice *Device, int Fd, int Adapter, int Ca)
{
device = Device;
SetDescription("CI adapter on device %d", device->DeviceNumber());
fd = Fd;
+ adapter = Adapter;
+ ca = Ca;
+ OpenCa();
ca_caps_t Caps;
if (ioctl(fd, CA_GET_CAP, &Caps) == 0) {
if ((Caps.slot_type & CA_CI_LINK) != 0) {
@@ -41,10 +44,29 @@ cDvbCiAdapter::cDvbCiAdapter(cDevice *Device, int Fd)
cDvbCiAdapter::~cDvbCiAdapter()
{
Cancel(3);
+ CloseCa();
+}
+
+bool cDvbCiAdapter::OpenCa(void)
+{
+ if (fd >= 0)
+ return true;
+ fd = cDvbDevice::DvbOpen(DEV_DVB_CA, adapter, ca, O_RDWR);
+ return (fd >= 0);
+}
+
+void cDvbCiAdapter::CloseCa(void)
+{
+ if (fd < 0)
+ r
Re: [vdr] VDR and Hybrid DVB Cards ( was "HVR 4000 drivers broken - adapter0/frontend1 busy" in linux-media list )
On 16.11.2011 19:16, L. Hanisch wrote: Am 16.11.2011 00:08, schrieb Klaus Schmidinger: 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 you don't mind I would try to prefabricate something. On a first guess: would you combine the multiple frontends of an adapter in one cDvbDevice? I think this would be better than having multiple cDvbDevices which must interact somehow with each other. Sure there will be one cDvbDevice per adapter for a multi-frontend device where only one frontend can be active at any time. If (like on the TT-S2 6400) there are several frontends that can be active simultaneously, then there shall be separate adapters for each frontend, and thus a separate cDvbDevice for each adapter. Note, though, that support for such devices will most likely not go into VDR for version 2. I'm trying to wrap things up in order to make a stable version 2, and after that will address new things like this. Klaus ___ 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 16.11.2011 00:08, schrieb Klaus Schmidinger: 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 you don't mind I would try to prefabricate something. On a first guess: would you combine the multiple frontends of an adapter in one cDvbDevice? I think this would be better than having multiple cDvbDevices which must interact somehow with each other. And I excuse the pun... ;-) 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 )
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@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 ___ 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 )
2011/11/16 Manu Abraham : > 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. To my understanding the mentioned use case would have - according to linux-media project logic of how to handle this - would look like /dev/dvb/adapter0/frontend0 /dev/dvb/adapter0/frontend1 /dev/dvb/adapter0/demux0 ... /dev/dvb/adapter0/ca0 /dev/dvb/adapter1/frontend0 /dev/dvb/adapter1/frontend1 /dev/dvb/adapter1/demux0 ... /dev/dvb/adapter1/ca0 so it would be 2 adapter with 4 frontends. If for some reason they should be in one adapter how to distinguish between the different cases ? Maybe i did not understand properly the issue. Anyhow - if such a case exist - it needs to be discussed how it will be handled at driver side and how applications need to talk to the driver - it doesnt help to implement the perfect driver, if nobody can use it. The multi frontend approach for multi-standard devices as described here, should logically anyway only be used if more then one receiption possibility can be connected at the same time. (i.e. if sattelite cable also can contain the DVB-T signal or both can be connected same time) Reading linux-media mailing list doesn't give a clear picture on the rules on one hand , but on the other hand implementations like the mentioned one exist. Preferably the API would describe how to handle it and rules exist for the drivers to be followed, so that applications dont get broken if following the API. ___ 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 all, I have HVR-4000 in my htpc together with Nova HD S2, and I'm willing to help as tester. It would be nice to finally getting dvb+t and dvb-s/s2 working together with VDR. -- Pozdrawiam, Tomasz Bubel ___ 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 )
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
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
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 '
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 )
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 )
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 )
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
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 )
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. 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. > 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.551788] i915 :00:02.0: setting latency timer to 64 > > [7.564218] i915 :00:02.0: irq 41 for MSI/MSI-X > > [7.564399] vgaarb: device changed decodes: > PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem > > [7.564825] [drm] initialized overlay support > > [7.579830] cx88/0: cx2388x v4l2 driver version 0.0.9 loaded > > [7.583007] No connectors reported connected with modes > > [7.583077] [drm] Cannot find any crtc or sizes - going 1024x768 > > [7.588874] Console: switching to colour frame buffer device > > 128x48 [7.591121] fb0: inteldrmfb frame buffer device > > [7.591144] drm: registered panic notifier > > [7.591174] No ACPI video bus found > > [7.591316] [drm] Initialized i915 1.6.0 20080730 for > > :00:02.0 > on minor 0 > >
[vdr] VDR and Hybrid DVB Cards ( was "HVR 4000 drivers broken - adapter0/frontend1 busy" in linux-media list )
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. 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.551788] i915 :00:02.0: setting latency timer to 64 > [7.564218] i915 :00:02.0: irq 41 for MSI/MSI-X > [7.564399] vgaarb: device changed decodes: PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem > [7.564825] [drm] initialized overlay support > [7.579830] cx88/0: cx2388x v4l2 driver version 0.0.9 loaded > [7.583007] No connectors reported connected with modes > [7.583077] [drm] Cannot find any crtc or sizes - going 1024x768 > [7.588874] Console: switching to colour frame buffer device 128x48 > [7.591121] fb0: inteldrmfb frame buffer device > [7.591144] drm: registered panic notifier > [7.591174] No ACPI video bus found > [7.591316] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0 > [7.617097] cx88[0]: i2c init: enabling analog demod on HVR1300/3000/4000 tuner > [7.702578] IR RC5(x) protocol handler initialized > [7.728589] IR RC6 protocol handler initialized > [7.730628] cx2388x alsa driver version 0.0.9 loaded > [7.746096] IR JVC protocol handler initialized > [7.749962] IR Sony protocol handler initialized > [7.918601] IR MCE Keyboard/mouse protocol handler initialized > [7.980484] lirc_dev: IR Remote Control driver registered, major 243 > [7.994039] IR LIRC bridge handler initialized > [7.994767] tda9887 15-0043: creating new instance > [7.994795] tda9887 15-0043: tda988[5/6/7] found > [7.995608] tuner 15-0043: Tuner 74 found with type(s) Radio TV. > [7.997560] tuner 15-0061: Tuner -1 found with type(s) Radio TV. > [
