Re: [vdr] [ANNOUNCE] VDR developer version 1.7.23
Hi, I have updated my current build taken from the Media Build Tree last Tuesday with the contents of the linux media tarball dated 22/01/2012 and rebuilt my drivers. I still get the same results. As the system initialises the following lines appear in the syslog: Jan 23 12:16:44 Nutrigrain kernel: [9.338720] tuner-simple 16-0061: couldn't set type to 63. Using 78 (Philips FMD1216MEX MK3 Hybrid Tuner) instead Jan 23 12:16:44 Nutrigrain kernel: [9.346240] DVB: registering adapter 1 frontend 0 (Conexant CX24116/CX24118)... Jan 23 12:16:44 Nutrigrain kernel: [9.349110] DVB: registering adapter 1 frontend 1 (Conexant CX22702 DVB-T)... Subsequently when starting VDR the following is logged: Jan 23 13:10:13 Nutrigrain vdr: [2704] registered source parameters for 'A - ATSC' Jan 23 13:10:13 Nutrigrain vdr: [2704] registered source parameters for 'C - DVB-C' Jan 23 13:10:13 Nutrigrain vdr: [2704] registered source parameters for 'S - DVB-S' Jan 23 13:10:13 Nutrigrain vdr: [2704] registered source parameters for 'T - DVB-T' Jan 23 13:10:13 Nutrigrain vdr: [2704] probing /dev/dvb/adapter0/frontend0 Jan 23 13:10:13 Nutrigrain vdr: [2704] new device number 1 Jan 23 13:10:13 Nutrigrain vdr: [2704] frontend 0/0 provides DVB-S with QPSK (ST STV0299 DVB-S) Jan 23 13:10:13 Nutrigrain vdr: [2708] tuner on frontend 0/0 thread started (pid=2704, tid=2708) Jan 23 13:10:13 Nutrigrain vdr: [2709] section handler thread started (pid=2704, tid=2709) Jan 23 13:10:13 Nutrigrain vdr: [2704] probing /dev/dvb/adapter1/frontend0 Jan 23 13:10:13 Nutrigrain vdr: [2704] new device number 2 Jan 23 13:10:14 Nutrigrain vdr: [2706] video directory scanner thread ended (pid=2704, tid=2706) Jan 23 13:10:14 Nutrigrain vdr: [2705] video directory scanner thread ended (pid=2704, tid=2705) Jan 23 13:10:19 Nutrigrain vdr: [2704] frontend 1/0 provides DVB-S,DVB-S2 with QPSK (Conexant CX24116/CX24118) Jan 23 13:10:19 Nutrigrain vdr: [2712] tuner on frontend 1/0 thread started (pid=2704, tid=2712) Jan 23 13:10:19 Nutrigrain vdr: [2713] section handler thread started (pid=2704, tid=2713) Jan 23 13:10:24 Nutrigrain vdr: [2704] ERROR (dvbdevice.c,1087): /dev/dvb/adapter1/frontend1: Device or resource busy Jan 23 13:10:24 Nutrigrain vdr: [2704] found 2 DVB devices I'm sure that I have the latest drivers loaded now, but still the same issue. The only conclusion that I can come to is that the necessary changes to the drivers have not (yet) been made. Has anyone else tried VDR 1.7.23 with a HVR 4000 hybrid card and if so, do you get the same results? Thanks, Mark. -Original Message- From: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] On Behalf Of Steffen Barszus Sent: Wednesday, 18 January 2012 5:47 PM To: vdr@linuxtv.org Subject: Re: [vdr] [ANNOUNCE] VDR developer version 1.7.23 On Wed, 18 Jan 2012 09:58:16 +1100 Hawes, Mark mark.ha...@au.fujitsu.com wrote: Hi, I have tried using my hybrid HVR 4000 card ( DVB-S2 and DVB-T frontends on one adapter ) against 1.7.23 and a new set of V4L-DVB drivers built on Monday. DVB-S channels work fine. However, any attempt to select a DVB-T channel results in channel not available. The Syslog trace during VDR initialisation follows: It looks like VDR is not picking up the second frontend on the hybrid card as a result of the 'Device or resource busy' result which is due to frontend 0 being open on it. If you are using new dvb driver you should only have 1 frontend which has all of the delivery systems. The DVBv3 message also looks suspicious. Can you double check that new drivers are loaded and you have indeed only 1 frontend for that card ? (Not saying that there is not a bug) Regards, -Original Message- From: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] On Behalf Of Klaus Schmidinger Sent: Monday, 16 January 2012 2:11 AM To: vdr@linuxtv.org Subject: [vdr] [ANNOUNCE] VDR developer version 1.7.23 VDR developer version 1.7.23 is now available at ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.23.tar.bz2 A 'diff' against the previous version is available at ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.22-1.7.23.diff MD5 checksums: de136f7be28c4b6f1fa0e2218b4acc11 vdr-1.7.23.tar.bz2 2977b75cd8dacad187d11c10b867d56a vdr-1.7.22-1.7.23.diff WARNING: This is a *developer* version. Even though *I* use it in my productive environment. I strongly recommend that you only use it under controlled conditions and for testing and debugging. The changes since version 1.7.22: - Removed the '.pl' suffix from svdrpsend.pl (sorry, I missed that one). - Fixed bonding more than two devices. - Fixed handling symbolic links in cRecordings::ScanVideoDir() (reported by Sundararaj Reel). - Fixed a memory leak in cRecordings::ScanVideoDir() in case there are too many link levels (reported by Sundararaj Reel). - Removed redundant memset() in the ctor of cSatCableNumbers
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.23
Hi, The drivers I am using I downloaded from the media build tree using git clone git://linuxtv.org/media_build.git as suggested on the Linuxtv.org site. However, these appear to be 'old' drivers as I am still getting 2 frontend devices created for my card when I load them. Can anyone suggest how I can get the latest set of Manu Abraham's drivers which I believe may contain some later patches. Thanks, Mark. -Original Message- From: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] On Behalf Of Steffen Barszus Sent: Wednesday, 18 January 2012 5:47 PM To: vdr@linuxtv.org Subject: Re: [vdr] [ANNOUNCE] VDR developer version 1.7.23 On Wed, 18 Jan 2012 09:58:16 +1100 Hawes, Mark mark.ha...@au.fujitsu.com wrote: Hi, I have tried using my hybrid HVR 4000 card ( DVB-S2 and DVB-T frontends on one adapter ) against 1.7.23 and a new set of V4L-DVB drivers built on Monday. DVB-S channels work fine. However, any attempt to select a DVB-T channel results in channel not available. The Syslog trace during VDR initialisation follows: It looks like VDR is not picking up the second frontend on the hybrid card as a result of the 'Device or resource busy' result which is due to frontend 0 being open on it. If you are using new dvb driver you should only have 1 frontend which has all of the delivery systems. The DVBv3 message also looks suspicious. Can you double check that new drivers are loaded and you have indeed only 1 frontend for that card ? (Not saying that there is not a bug) Regards, -Original Message- From: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] On Behalf Of Klaus Schmidinger Sent: Monday, 16 January 2012 2:11 AM To: vdr@linuxtv.org Subject: [vdr] [ANNOUNCE] VDR developer version 1.7.23 VDR developer version 1.7.23 is now available at ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.23.tar.bz2 A 'diff' against the previous version is available at ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.22-1.7.23.diff MD5 checksums: de136f7be28c4b6f1fa0e2218b4acc11 vdr-1.7.23.tar.bz2 2977b75cd8dacad187d11c10b867d56a vdr-1.7.22-1.7.23.diff WARNING: This is a *developer* version. Even though *I* use it in my productive environment. I strongly recommend that you only use it under controlled conditions and for testing and debugging. The changes since version 1.7.22: - Removed the '.pl' suffix from svdrpsend.pl (sorry, I missed that one). - Fixed bonding more than two devices. - Fixed handling symbolic links in cRecordings::ScanVideoDir() (reported by Sundararaj Reel). - Fixed a memory leak in cRecordings::ScanVideoDir() in case there are too many link levels (reported by Sundararaj Reel). - Removed redundant memset() in the ctor of cSatCableNumbers (triggered by Ville Skyttä pointing out that the argument sequence in the call was wrong). - Removed a redundant NULL check in cDvbSpuDecoder::setTime() (thanks to Ville Skyttä). - Added HasSnr to the DEBUG_SIGNALQUALITY output in cDvbTuner::GetSignalQuality() (triggered by Ville Skyttä pointing out that the variable HasSnr was unused). - Updated the Finnish OSD texts (thanks to Rolf Ahrenberg). - Added support for HbbTV to libsi (thanks to Christoph Haubrich). - Added support for devices with more than one delivery system per frontend. This requires a DVB driver with version 5.5 or higher that can handle the DTV_ENUM_DELSYS call. With older drivers it will fall back to one delivery system per frontend. - Updated the Hungarian language texts (thanks to István Füley). - cDvbTuner::ExecuteDiseqc() now makes sure only one tuner sends SCR commands at any given time (reported by Frank Neumann). - cEvent::FixEpgBugs() now replaces any newline characters in stream component descriptions with blanks (thanks to Torsten Lang for reporting a problem with EPG data from BSkyB's MTV MUSIC, S28.2E-2-2010-7012). - Fixed cDvbSubtitleConverter::SetOsdData() (thanks to Rolf Ahrenberg). - Fixed cListBase::Move() in case From and To are equal (reported by Sundararaj Reel). - Added support for DVB-T2 to libsi (thanks to Rolf Ahrenberg). - Added support for handling DVB-T2 transponders. This requires a DVB driver with version 5.3 or higher that can handle the DTV_DVBT2_PLP_ID call (thanks to Rolf Ahrenberg). - Fixed cConfig::Load() for g++ version 4.7.0 (thanks to Ville Skyttä). - Fixed a possible memory corruption in cTsToPes::GetPes() in case of broken TS packets, e.g. when switching channels. - Fixed the SVDRP command CLRE for a single channel in case there are events that have a timer (thanks to Timo Eskola). - BIDI support now checks at runtime whether the system runs with UTF-8 (suggested by Torsten Lang). - Added member functions Adapter() and Frontend() to cDvbDevice (suggested by Rolf Ahrenberg). - The parameters that are only used by second generation delivery systems (DVB-S2 and DVB-T2
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.23
Hi, I have tried using my hybrid HVR 4000 card ( DVB-S2 and DVB-T frontends on one adapter ) against 1.7.23 and a new set of V4L-DVB drivers built on Monday. DVB-S channels work fine. However, any attempt to select a DVB-T channel results in channel not available. The Syslog trace during VDR initialisation follows: Jan 17 18:44:05 Nutrigrain vdr: [2587] video directory scanner thread started (pid=2586, tid=2587) Jan 17 18:44:05 Nutrigrain vdr: [2588] video directory scanner thread started (pid=2586, tid=2588) Jan 17 18:44:05 Nutrigrain vdr: [2586] reading EPG data from /home/digitalTV/video/epg.data Jan 17 18:44:05 Nutrigrain vdr: [2586] registered source parameters for 'A - ATSC' Jan 17 18:44:05 Nutrigrain vdr: [2586] registered source parameters for 'C - DVB-C' Jan 17 18:44:05 Nutrigrain vdr: [2586] registered source parameters for 'S - DVB-S' Jan 17 18:44:05 Nutrigrain vdr: [2586] registered source parameters for 'T - DVB-T' Jan 17 18:44:05 Nutrigrain vdr: [2586] probing /dev/dvb/adapter0/frontend0 Jan 17 18:44:05 Nutrigrain vdr: [2586] new device number 1 Jan 17 18:44:05 Nutrigrain kernel: [ 150.671847] dvb_frontend_ioctl_legacy: doesn't know how to handle a DVBv3 call to delivery system 0 Jan 17 18:44:05 Nutrigrain vdr: [2586] frontend 0/0 provides DVB-S with QPSK (ST STV0299 DVB-S) Jan 17 18:44:05 Nutrigrain vdr: [2591] section handler thread started (pid=2586, tid=2591) Jan 17 18:44:05 Nutrigrain vdr: [2590] tuner on frontend 0/0 thread started (pid=2586, tid=2590) Jan 17 18:44:05 Nutrigrain vdr: [2586] probing /dev/dvb/adapter1/frontend0 Jan 17 18:44:05 Nutrigrain vdr: [2586] new device number 2 Jan 17 18:44:06 Nutrigrain vdr: [2588] video directory scanner thread ended (pid=2586, tid=2588) Jan 17 18:44:06 Nutrigrain vdr: [2587] video directory scanner thread ended (pid=2586, tid=2587) Jan 17 18:44:10 Nutrigrain kernel: [ 155.838763] dvb_frontend_ioctl_legacy: doesn't know how to handle a DVBv3 call to delivery system 0 Jan 17 18:44:10 Nutrigrain vdr: [2586] frontend 1/0 provides DVB-S,DVB-S2 with QPSK (Conexant CX24116/CX24118) Jan 17 18:44:10 Nutrigrain vdr: [2594] tuner on frontend 1/0 thread started (pid=2586, tid=2594) Jan 17 18:44:10 Nutrigrain vdr: [2595] section handler thread started (pid=2586, tid=2595) Jan 17 18:44:15 Nutrigrain vdr: [2586] ERROR (dvbdevice.c,1051): /dev/dvb/adapter1/frontend1: Device or resource busy Jan 17 18:44:15 Nutrigrain vdr: [2586] found 2 DVB devices Note that there is also a DVB-S premium card in the mix which works OK. It looks like VDR is not picking up the second frontend on the hybrid card as a result of the 'Device or resource busy' result which is due to frontend 0 being open on it. Any suggestions: Regards, -Original Message- From: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] On Behalf Of Klaus Schmidinger Sent: Monday, 16 January 2012 2:11 AM To: vdr@linuxtv.org Subject: [vdr] [ANNOUNCE] VDR developer version 1.7.23 VDR developer version 1.7.23 is now available at ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.23.tar.bz2 A 'diff' against the previous version is available at ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.22-1.7.23.diff MD5 checksums: de136f7be28c4b6f1fa0e2218b4acc11 vdr-1.7.23.tar.bz2 2977b75cd8dacad187d11c10b867d56a vdr-1.7.22-1.7.23.diff WARNING: This is a *developer* version. Even though *I* use it in my productive environment. I strongly recommend that you only use it under controlled conditions and for testing and debugging. The changes since version 1.7.22: - Removed the '.pl' suffix from svdrpsend.pl (sorry, I missed that one). - Fixed bonding more than two devices. - Fixed handling symbolic links in cRecordings::ScanVideoDir() (reported by Sundararaj Reel). - Fixed a memory leak in cRecordings::ScanVideoDir() in case there are too many link levels (reported by Sundararaj Reel). - Removed redundant memset() in the ctor of cSatCableNumbers (triggered by Ville Skyttä pointing out that the argument sequence in the call was wrong). - Removed a redundant NULL check in cDvbSpuDecoder::setTime() (thanks to Ville Skyttä). - Added HasSnr to the DEBUG_SIGNALQUALITY output in cDvbTuner::GetSignalQuality() (triggered by Ville Skyttä pointing out that the variable HasSnr was unused). - Updated the Finnish OSD texts (thanks to Rolf Ahrenberg). - Added support for HbbTV to libsi (thanks to Christoph Haubrich). - Added support for devices with more than one delivery system per frontend. This requires a DVB driver with version 5.5 or higher that can handle the DTV_ENUM_DELSYS call. With older drivers it will fall back to one delivery system per frontend. - Updated the Hungarian language texts (thanks to István Füley). - cDvbTuner::ExecuteDiseqc() now makes sure only one tuner sends SCR commands at any given time (reported by Frank Neumann). - cEvent::FixEpgBugs() now replaces any newline characters in stream component descriptions with
Re: [vdr] [PATCH v2] multi-frontend-support for vdr 1.7.21
Hi Lars, I have got the sc plugin working with your hybrid patch v2 and introduced the premium card and all is working well. Are you planning any more revisions to the patch? Or at least a 1.7.22 version? Thanks, Mark. -Original Message- From: Hawes, Mark Sent: Thursday, 1 December 2011 10:08 PM To: 'VDR Mailing List' Subject: RE: [vdr] [PATCH v2] multi-frontend-support for vdr 1.7.21 Hi Lars, First reports on v2 of your multi-frontend patch with HVR 4000 card: - can switch between both frontends successfully and very stable with repetitive tests - timer behaviour as expected - switching response seems quicker than before - Streamdev and xineliboutput plugins compile OK. Xlo tested OK, will look at Sd later - Have modified Rotor plugin to fit (maintaining personal version) and all seems OK - Working through sc plugin changes to fit. If I can get the sc plugin working I'll move across a sd premium card into the mix and see how it behaves, watch this space ... While this is all good obviously things will no doubt change when Klaus releases 2.x with the new multi-frontend adapter handling. However, reading between the lines this may not be in the immediate future so an interim workaround for these cards is appreciated by me and I expect others ... Thanks and keep up the good work. Mark. -Original Message- From: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] On Behalf Of L. Hanisch Sent: Thursday, 1 December 2011 10:50 AM To: VDR Mailing List Subject: [vdr] [PATCH v2] multi-frontend-support for vdr 1.7.21 Hi, Here's version 2 of my multi-frontend-patch. It's still dirty, since it changes the constructor of cDvbDevice which will break compilation of some plugins. But I think it might be necessary to look at the relevant plugins since they might need to react on frontend changes. I haven't tested any of those plugins but will have a look at some that I'm using. Maybe there have to be some virtual functions like BeforeFrontendSwitch and AfterFrontendSwitch so the plugins are even able to know about it. Assumption for this patch: All frontends within one adapter have to be used mutually exclusive. All cards I know behave in this way. If there are cards with multiple frontends which can be used simultaneously I'd like to hear about it. Whenever the dvb-api-changes are upstream (the ENUM_DELSYS thingy) I think my patch can easily be converted to use that. I'm still working on this patch, it's not finished yet... :-) Have fun, Lars. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH v2] multi-frontend-support for vdr 1.7.21
Hi Lars, First reports on v2 of your multi-frontend patch with HVR 4000 card: - can switch between both frontends successfully and very stable with repetitive tests - timer behaviour as expected - switching response seems quicker than before - Streamdev and xineliboutput plugins compile OK. Xlo tested OK, will look at Sd later - Have modified Rotor plugin to fit (maintaining personal version) and all seems OK - Working through sc plugin changes to fit. If I can get the sc plugin working I'll move across a sd premium card into the mix and see how it behaves, watch this space ... While this is all good obviously things will no doubt change when Klaus releases 2.x with the new multi-frontend adapter handling. However, reading between the lines this may not be in the immediate future so an interim workaround for these cards is appreciated by me and I expect others ... Thanks and keep up the good work. Mark. -Original Message- From: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] On Behalf Of L. Hanisch Sent: Thursday, 1 December 2011 10:50 AM To: VDR Mailing List Subject: [vdr] [PATCH v2] multi-frontend-support for vdr 1.7.21 Hi, Here's version 2 of my multi-frontend-patch. It's still dirty, since it changes the constructor of cDvbDevice which will break compilation of some plugins. But I think it might be necessary to look at the relevant plugins since they might need to react on frontend changes. I haven't tested any of those plugins but will have a look at some that I'm using. Maybe there have to be some virtual functions like BeforeFrontendSwitch and AfterFrontendSwitch so the plugins are even able to know about it. Assumption for this patch: All frontends within one adapter have to be used mutually exclusive. All cards I know behave in this way. If there are cards with multiple frontends which can be used simultaneously I'd like to hear about it. Whenever the dvb-api-changes are upstream (the ENUM_DELSYS thingy) I think my patch can easily be converted to use that. I'm still working on this patch, it's not finished yet... :-) Have fun, 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 )
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 frontends that can be active simultaneously, then there shall be separate adapters for each frontend
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 )
-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, Markmark.ha...@au.fujitsu.com: What i got from previous discussions on linux-media is, that if the device nodes are created within one adapter, an application needs to assume that the devices can not be used concurrently and needs to close one device node group before opening the other one. This suggests a constraint in the current design of the way VDR handles the detection and use of DVB devices in that it cannot handle so called 'hybrid' cards where two (or more!) frontends are attached via a single adaptor without restarting VDR and identifying which frontend to use. As already mentioned I wish to use both cards on my system and I'd be interested and happy to help in developing a patch to overcome this constraint. However I would need some VDR architectural guidance to suggest how this might be done with minimal disruption to the current DVB device handling. Any direction would be much appreciated. What i said above is AFAIK more or less undocumented up to now. But it seems to be a consensus between most driver developers now. Yes vdr needs to change to handle this devices properly based on the previous assumptions, i think soneone else can be more helpful than me ;). I'm just preparing a test environment for extending the vdr to use multi-frontend devices. Good to know that there are drivers which behaves different in creating device nodes. The Cine-C/T cards for example creates only one demux/dvr node and two frontends. Soon I will have my hands on such a device. If I can get a patch working for this card it's only a small step to support the HVR 4000, two. I agree that any such solution should not be card specific but apply in general to cards with various adapter 'architectures'. I can offer my system as a HVR 4000 testbed for such a development. I have already dealt with vdr devices and have some knowledge about the concepts. I developed the dynamite plugin which extends vdr with some device hotplugging capabilities. It also requires patching the vdr. But with this you can use both devices without restarting vdr and affecting timers and recordings. But for now there's no automatism so that the right device for the watched/recorded channel is attached. Please have a look at the README if you're interested. If you have questions, just ask. http://projects.vdr-developer.org/projects/plg-dynamite https://github.com/flensrocker/vdr-plugin-dynamite I had a look at the readme. The approach of making all devices hot pluggable is an interesting one and provides for a flexible solution. How important it is to get plugins to adapt to the approach is still unclear to me. Presumably if they are in the plugin list prior to the dynamite plugin they will be 'immune' as they will declare their own devices to the pool first. While the approach has its merits I believe that it is probably overkill in this case. I believe that VDR should be able to cater for hybrid cards natively alongside existing cards with more conventional adapter layouts and any patch should ultimately have that as its goal. If you want to develop something on your own, start reading device.[hc] and dvbdevice.[hc] at the vdr source. I definitly will try to develop a multi-frontend-patch but spare time is always rare. I will reserve one evening per week for this. And I hope to finish it till christmas. ;-) As indicated above I'd be happy to test anything you come up with. If you have ideas please let me know. I'm looking for some inspiration for storing the different frontend capabilities at the cDvbDevice and how to maintain the different cDvbTuner objects. My experience while working on dynamite will help me in particular since I invested some time on closing/reopening the file handles at the right places. Hotplugging single frontend devices seems to be a good first step towards the solution of this problem. Lars. As I see it there are two possible approaches: try to bolt on support for hybrid cards as exception cases to the current code, or redesign the handling of the devices from the ground up to also cater for the more exotic adapter layouts. There could be a third 'hybrid' solution which sits somewhere between the two. The comment above from Steffen seems to make some sense ' if the device nodes are created within one adapter an application needs to assume that the devices cannot be used concurrently and needs to close one device node group before opening the other one'. As I understand it this would mean that VDR should register all front ends on initialisation and then only try to open them when required. If another
[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. [8.035897] tveeprom 15-0050: Hauppauge
Re: [vdr] Diseqc problems with VDR1.7.19
I've done some further investigation and as far as I can tell the problem appears to be with the value returned by cDiseqc::Codes in diseqc.c. The return value changed from 'uchar' to 'const uchar' between 1.7.18 and 1.7.19 and the returned value now always points to the last diseqc code in the string. The following trace from 1.7.19 shows the problem: Diseqc command list found = t V [E0 10 38 F4] W500 [E0 31 6B 01] W250 [E1 31 6B 01] W15 T Entered cDiseqc::Codes pointing at : E0 10 38 F4] In cDiseqc::Codes - returning a pointer 137345561 to : W500 [E0 31 Received from diseqc-Codes(n) a pointer 137345509 to : E1 31 6B 01 Sending Diseqc command: E1 31 6B 01 Entered cDiseqc::Codes pointing at : E0 31 6B 01] In cDiseqc::Codes - returning a pointer 137345580 to : W250 [E1 31 Received from diseqc-Codes(n) a pointer 137345509 to : E1 31 6B 01 Sending Diseqc command: E1 31 6B 01 Entered cDiseqc::Codes pointing at : E1 31 6B 01] In cDiseqc::Codes - returning a pointer 137345599 to : W15 T Received from diseqc-Codes(n) a pointer 137345509 to : E1 31 6B 01 Sending Diseqc command: E1 31 6B 01 The identical trace from 1.7.18 which works correctly looks like this: Diseqc command list found = t V [E0 10 38 F4] W500 [E0 31 6B 01] W250 [E1 31 6B 01] W15 T Entered cDiseqc::Codes pointing at : E0 10 38 F4] In cDiseqc::Codes - returning a pointer 137333177 to : W500 [E0 31 Received from diseqc-Codes(n) a pointer 137333125 to : E0 10 38 F4 Sending Diseqc command: E0 10 38 F4 Entered cDiseqc::Codes pointing at : E0 31 6B 01] In cDiseqc::Codes - returning a pointer 137333196 to : W250 [E1 31 Received from diseqc-Codes(n) a pointer 137333125 to : E0 31 6B 01 Sending Diseqc command: E0 31 6B 01 Entered cDiseqc::Codes pointing at : E1 31 6B 01] In cDiseqc::Codes - returning a pointer 137333215 to : W15 T Received from diseqc-Codes(n) a pointer 137333125 to : E1 31 6B 01 Sending Diseqc command: E1 31 6B 01 I have tried to revert cDiseqc::Codes in 1.7.19 to the 1.7.18 version but the extent of the changes introduced to 1.7.19 in this area eventually defeated my limited C++ skills. In doing so I have learnt and read a lot and it appears that there are some pitfalls in returning 'const' values. I suspect that this is the problem here but can't be sure. If someone could have a look at this and suggest how to fix it, it would be much appreciated. Thanks, Mark. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Diseqc problems with VDR1.7.19
Thanks Udo, that seems to have done the trick.
I guess Klaus will pick this up as a matter of course ...
Regards,
Mark.
-Original Message-
From: Udo Richter [mailto:udo_rich...@gmx.de]
Sent: Tuesday, 26 July 2011 5:19 AM
To: VDR Mailing List
Subject: Re: [vdr] Diseqc problems with VDR1.7.19
Am 25.07.2011 13:12, schrieb Hawes, Mark:
I've done some further investigation and as far as I can tell the
problem appears to be with the value returned by cDiseqc::Codes in
diseqc.c.
The following trace from 1.7.19 shows the problem:
Received from diseqc-Codes(n) a pointer 137345509 to : E1 31 6B 01
[..]
Received from diseqc-Codes(n) a pointer 137345509 to : E1 31 6B 01
[..]
Received from diseqc-Codes(n) a pointer 137345509 to : E1 31 6B 01
The identical trace from 1.7.18 which works correctly looks like this:
Received from diseqc-Codes(n) a pointer 137333125 to : E0 10 38 F4
[..]
Received from diseqc-Codes(n) a pointer 137333125 to : E0 31 6B 01
[..]
Received from diseqc-Codes(n) a pointer 137333125 to : E1 31 6B 01
Without further trying, my wild guess is that the bug is in the
following code fragment of const char *cDiseqc::Codes(const char *s)
const:
int n = strtol(t, p, 16);
if (!errno p != t 0 = n n = 255) {
if (parsing) {
codes[NumCodes++] = uchar(n);
numCodes = NumCodes;
My guess is that it must be if (!parsing) instead. The switch seems to
be true for syntax checking from cDiseqc::Parse() (the conf file
parser), and false otherwise. The way it is, the values in codes[] only
change when called from the file parser, and then stay at the last code
sequence that has been parsed forever.
Cheers,
Udo
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Diseqc problems with VDR1.7.19
Hi, Since upgrading to VDR 1.7.19 I have experienced problems with Diseqc. My diseqc configuration uses command strings which contain 3 code sets: a diseqc switch command, a diseqc go to command, and a repeat goto command. Since upgrading to VDR 1.7.19 it appears that the only code set sent is the last one, but it's sent three times. To demonstrate this I have put some trace in cDvbTuner::SetFrontend within dvbdevice.c which traces the complete diseqc string, the diseqc action, and for diseqc codes - the actual diseqc code sent. It produces the following output: Diseqc command list found = t v [E0 10 38 F4] W500 [E0 31 6B 04] W250 [E0 31 6B 04] W15 T Diseqc action = 1 Diseqc action = 3 Diseqc action = 7 Sending Diseqc command: E0 31 6B 04 Wrong, should be E0 10 38 F4 Diseqc action = 7 Sending Diseqc command: E0 31 6B 04 Wrong, should be E0 31 6B 04 Diseqc action = 7 Sending Diseqc command: E0 31 6B 04 Diseqc action = 2 The same trace in vdr 1.7.18 shows the correct codes being sent in the correct sequence. I note that some work was done in this area for 1.7.19 but my C++ skills are a little weak to diagnose the problem any further. Can anybody throw some more light on what's going on? Thanks, Mark. Mark Hawes Senior Project Manager Fujitsu Australia Limited 825 Bourke Street, Docklands VIC 3008, Australia T +61 3 9924 3240 M +61 416 140 218 F +61 3 9924 3001 mark.ha...@au.fujitsu.com mailto:mark.ha...@au.fujitsu.com au.fujitsu.com http://au.fujitsu.com image001.gif___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Diseqc problems with VDR1.7.19
Just looked at the trace I sent in my initial post and realised that I had selected a Diseqc command that I had modified while trying to diagnose the situation so my annotations were a bit misleading. The following should be less confusing: Diseqc command list found = t v [E0 10 38 F4] W500 [E0 31 6B 04] W250 [E1 31 6B 04] W15 T Diseqc action = 1 Diseqc action = 3 Diseqc action = 7 Sending Diseqc command: E1 31 6B 04 Wrong, should be E0 10 38 F4 Diseqc action = 7 Sending Diseqc command: E1 31 6B 04 Wrong, should be E0 31 6B 04 Diseqc action = 7 Sending Diseqc command: E1 31 6B 04 Diseqc action = 2 Again, the final Diseqc command has been sent three times, not the three commands in the sequence they appear in the command list. Apologies for the confusion. Mark. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR 1.7.16 FF card crashes
I'm have been using a Technotrend FF sat card on 1.7.16 without a problem. Check you are using the latest firmware. MD. I upgraded my VDr system from 1.6.0 to 1.7.16. After upgrade, I found that my FF card (fujitsu-siemens dvb-c) crashes almost every time when I exit from a recording playback. It won't tune anymore. Usually OSD still works but sometimes it also crashes. Only way to recover is to restart VDR and reload kernel module. I'm using latest fw for ff card. Hi, Same issue here. I was thinking it was an issue with the card, the firmware, the motherboard or pci latency. In the end I stopped using it... I'm even considering giving it to someone else. The only plugins i'm using are xineliboutput and streamdev and I'm able to make it crash by just changing channels. Dish and signal are ok, no errors and my budget and dvb-s2 card are both working perfectly. That's a very good thing i read your message, i'll try to use 1.6.0 and see if it's ok with it :) Cheers. -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Instability with recordings on VDR-1.7.4 when recording to a NTFS partition
One question (OT): is it normal that replaying a PES record causes in a very high CPU load on 1.7.2 and higher? - 80-90% on a P4/2400 Replaying TS produces no CPU load. Forget it! This seems to be fixed too since your patch. Could that be possible? I don't think so. The modified code is not involved in replaying, only in recording. Klaus I too can confirm that this has fixed my problem recording to an NTFS Partition. With the patches applied I have successfully recorded two streams simultaneously while playing a third. Thanks. Mark. This is an email from Fujitsu Australia Limited, ABN 19 001 011 427. It is confidential to the ordinary user of the email address to which it was addressed and may contain copyright and/or legally privileged information. No one else may read, print, store, copy or forward all or any of it or its attachments. If you receive this email in error, please return to sender. Thank you. If you do not wish to receive commercial email messages from Fujitsu Australia Limited, please email unsubscr...@au.fujitsu.com ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Instability with recordings on VDR-1.7.4 when recording to a NTFS partition
If I pause live video then restart it starts in slo-mo i.e. judders, and then eventually freezes, but may then start again, still juddering and freezing ... Well, then I have no idea why it wouldn't work with an NTFS partition, while it does work with others. Klaus Hi Klaus, I have similar problems using a NFS share under some circumstances: The general problem is that the index file stops growing after a few seconds, while the 1.ts file growing normally. 1. Using a local HDD with ReiserFS for recording, everything works well. 2. Using NFS V3 with the mount options tcp,hard,sync the index file stops growing. 3. Using NFS V3 with the mount options tcp,soft,async the index file keeps growing. I was happy figured that out, but there seems to be another problem. While having heavy network load this problem occurs again. An example: Cutting a movie on my NFS share, while recording a new movie to the same NFS share causes in the same problem, the index file stops growing. And... it does not start growing again, after the cutting has finished. This means that I have to stop/start the recording to get a correct index file again. Could it be possible, that the process which is writing the index dies in some kind? I've never had a problem like this in older VDR versions, and I often do cutting and recording at the same time. BTW: Is the a way to (re)create a new index file for TS like genvdr for VDR file did? -Günter Hi, I have checked the recording directory and sure enough, the index file stops growing after a short while (seconds). I have tried mounting the NTFS partition with the async option but to no avail, i.e. problem is still there. BTW: How do I respond to an already open thread? All I seem to be able to do is start a new one. Mark. This is an email from Fujitsu Australia Limited, ABN 19 001 011 427. It is confidential to the ordinary user of the email address to which it was addressed and may contain copyright and/or legally privileged information. No one else may read, print, store, copy or forward all or any of it or its attachments. If you receive this email in error, please return to sender. Thank you. If you do not wish to receive commercial email messages from Fujitsu Australia Limited, please email unsubscr...@au.fujitsu.com ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Instability with recordings on VDR-1.7.4 when recording to a NTFS partition
A TS recording is only marginally more data than the same length recording in PES. I don't think that recording in TS should require so much more bandwidth than PES. That's clear to me. There must be an other problem that's causing this, but since this doesn't happen here on my system, I'm afraid you'll need to do the debugging ;-) No problem, I'll try debugging the problem with my tools :-), but I have no chance debugging in the code. :-( Further investigation reveals ringbuffer overflows reported in syslog as soon as recording starts. I can put some trace into the code as Klaus has suggested. Assuming that what I am experiencing with NTFS is another manifestation of the problem Gunter is seeing with NFS - What would be useful? Just to be sure: this *is* an unpatched version 1.7.4. we're talking about, right? Yes, of course. It's installed from a fresh download, also 1.7.3 and 1.7.2 Mine is also a clean 1.7.4 install. Note that I am using the latest Liplianin drivers with two patches applied - av7110_ts_replay_1.diff and av7110_v4ldvb_api5_audiobuff_test_1.diff applied. Mark. -Günter -- This message was scanned by ESVA and is believed to be clean. This is an email from Fujitsu Australia Limited, ABN 19 001 011 427. It is confidential to the ordinary user of the email address to which it was addressed and may contain copyright and/or legally privileged information. No one else may read, print, store, copy or forward all or any of it or its attachments. If you receive this email in error, please return to sender. Thank you. If you do not wish to receive commercial email messages from Fujitsu Australia Limited, please email unsubscr...@au.fujitsu.com ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Instability with recordings on VDR-1.7.4 when recording to a NTFS partition
Hi, Since upgrading to VDR-1.7.4 I have experienced some instability when recording to an NTFS partition. The recording itself seems to proceed OK, but the recorded programs will generally only play for a few seconds before freezing. Pausing live video and then resuming play will also trigger the problem. Subsequently rewinding a recording that has been so paused will only rewind to the pause point, not the beginning of the recording. All works well when using vdr-1.7.2 to record on the same system to the same partition, and when I placed my recording directory on a reiserfs partition all worked well too. So it appears to be a problem recording on NTFS partitions introduced with the switch to .ts file recording. Any help appreciated. Mark. This is an email from Fujitsu Australia Limited, ABN 19 001 011 427. It is confidential to the ordinary user of the email address to which it was addressed and may contain copyright and/or legally privileged information. No one else may read, print, store, copy or forward all or any of it or its attachments. If you receive this email in error, please return to sender. Thank you. If you do not wish to receive commercial email messages from Fujitsu Australia Limited, please email unsubscr...@au.fujitsu.com ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Instability with recordings on VDR-1.7.4 when recording to a NTFS partition
On 20.03.2009 13:11, Hawes, Mark wrote: Since upgrading to VDR-1.7.4 I have experienced some instability when recording to an NTFS partition. The recording itself seems to proceed OK, but the recorded programs will generally only play for a few seconds before freezing. Pausing live video and then resuming play will also trigger the problem. Subsequently rewinding a recording that has been so paused will only rewind to the pause point, not the beginning of the recording. All works well when using vdr-1.7.2 to record on the same system to the same partition, and when I placed my recording directory on a reiserfs partition all worked well too. So it appears to be a problem recording on NTFS partitions introduced with the switch to .ts file recording. Does it make a difference if you comment out the line #define USE_FADVISE in VDR/tools.c? Klaus Hi Klaus, Commented out that line at line no 1442 in tools.c, and recompiled. No better. If I pause live video then restart it starts in slo-mo i.e. judders, and then eventually freezes, but may then start again, still juddering and freezing ... Mark This is an email from Fujitsu Australia Limited, ABN 19 001 011 427. It is confidential to the ordinary user of the email address to which it was addressed and may contain copyright and/or legally privileged information. No one else may read, print, store, copy or forward all or any of it or its attachments. If you receive this email in error, please return to sender. Thank you. If you do not wish to receive commercial email messages from Fujitsu Australia Limited, please email unsubscr...@au.fujitsu.com ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Streamdev Server and the Mediagate 800
The MG 800 successfully plays streamed content from the internet, but has problems with a stream from the streamdev server. The URL I am using from the player is identical to one that mplayer can play, e.g. 'http://192.168.0.4:3000/1'. PCH is not very good on recognizing media formats on FOURCC codes. So it needs URL with correct prefix. So could you check with URL and report: http://192.168.0.4:3000/TS/1.ts Above URL is submitted if you use Streamdev's channel selection interface (drop /1 from the end) - Jori Thanks for the response Jori. I have tried as you suggested but it still didn't work. I am also following this up with Frank Schmirler and have made some progress - the negotiation seems to proceed further and streamdev attempts to start streaming, but the Mediagate disconnects and the retries a number of times to establish similar connections, each which streamdev accepts, but the Mediagate never seems satisfied and eventually gives up. I have notified the problem to Mediagate but I am note hopeful of any response soon. Can you suggest any thing else I should try? I can provide streamdev debug trace if it would help. Thanks, Mark. Email: mark.ha...@au.fujitsu.com This is an email from Fujitsu Australia Limited, ABN 19 001 011 427. It is confidential to the ordinary user of the email address to which it was addressed and may contain copyright and/or legally privileged information. No one else may read, print, store, copy or forward all or any of it or its attachments. If you receive this email in error, please return to sender. Thank you. If you do not wish to receive commercial email messages from Fujitsu Australia Limited, please email unsubscr...@au.fujitsu.com ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] iptv plugin - hardware scaling
Timothy,
The channels.conf entry I'm using is:
Nasa TV;IPTV:1:IPTV|S0P0|EXT|iptvstream.sh|1:P:0:2:3:0:0:1:0:0:0
The URL line in iptvstream.sh is:
URL=http://www.nasa.gov/55644main_NASATV_Windows.asx
WIDTH=352
HEIGHT=288
And I've added width=${WIDTH},height=${HEIGHT} to the transcode
statement.
Hope that helps.
Mark
This is an email from Fujitsu Australia Limited, ABN 19 001 011 427. It is
confidential to the ordinary user of the email address to which it was
addressed and may contain copyright and/or legally privileged information. No
one else may read, print, store, copy or forward all or any of it or its
attachments. If you receive this email in error, please return to sender. Thank
you.
If you do not wish to receive commercial email messages from Fujitsu Australia
Limited, please email [EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] VDR SC - Problem with Irdeto 1 provider id
Hi, I am trying to use SC version 8.7 to decrypt an Irdeto 1 stream using a valid set of card credentials. I have placed these credentials in my IRD-BETA.KID file using the format specified in the examples. Specifically for the provider ID field I have used the value 10. However, SC does not see the keys for these credentials, although they are clearly being provided as can be seen in an EMM log, and ProgDVB / Fenrir are able to use this IRD-BETA.KID file to successfully provide plain keys in windows. After some playing around I discovered that I could get SC to recognise the keys if I set the provider ID field to 01. The ca.cache file is updated accordingly with the plain keys in the cache also having the value 01 for the provider ID, but SC does not attempt to use them. Manually changing the provider ID back to 10 in the cache file gives me pictures while the plain keys remain current. After some more playing I finally got things to work by patching cPlainKeys::NewKey in data.c to multiply the provided Id by 16 immediately on entry, but this is now using a non-standard IRD-BETA.KID file. I believe that the problem may reside in cProviderIrdeto::MatchEMM which is returning false unless I use the modified .KID file. However, I am not sure how this code in parse.c is supposed to work. While I now have pictures it would be nice not to have to use a non-standard IRD-BETA.KID and a home grown patch. Any one have any ideas? Thanks, Mark Hawes. This is an email from Fujitsu Australia Limited, ABN 19 001 011 427. It is confidential to the ordinary user of the email address to which it was addressed and may contain copyright and/or legally privileged information. No one else may read, print, store, copy or forward all or any of it or its attachments. If you receive this email in error, please return to sender. Thank you. If you do not wish to receive commercial email messages from Fujitsu Australia Limited, please email [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Plugin to play streaming video
I am looking for a plugin to play steaming video from the net, and specifically at the moment NASA TV. I have the MP3/Mplayer plugin installed, and also played with the VOD plugin about a year ago, but still can't work out how to achieve what I want. Any help would be much appreciated. This is an email from Fujitsu Australia Limited, ABN 19 001 011 427. It is confidential to the ordinary user of the email address to which it was addressed and may contain copyright and/or legally privileged information. No one else may read, print, store, copy or forward all or any of it or its attachments. If you receive this email in error, please return to sender. Thank you. If you do not wish to receive commercial email messages from Fujitsu Australia Limited, please email [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
