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 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 fro
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 )
> 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 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 )
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
