Re: [vdr] Vdr 1.7.15 and vdradmin
Hi, there is a bug in epgsearch which leaks file descriptors if epgsearch cannot connect to the SVDRP port. Everything works well for a while until all file descriptor slots are in use and process cannot open any file anymore. Then VDR will either stop showing live TV, stop recording, crash or do something else weird. Or any combination of the following. I lost couple of recordings because of this bug, as I wasn't careful enough to check what was changed between 1.7.14 and 1.7.15... The fix can be found from the following patch: http://tvr.dy.fi/vdr/epgsearch-0.9.25-beta16-leakingfiledescriptors.diff Hoping to see the fix in 0.9.25-beta17 :-) Teemu 2010/6/15 Seppo Ingalsuo > Hi, > > Has anyone noticed problems with vdradmin-am, epgsearch and new vdr > 1.7.15? > > Since upgrade from vdr 1.7.14 VDRadmin web interface dones not work. Web > browser shows this error: > > "Can't connect to VDR at localhost:2001 > > Please check if VDR is running and if VDR's svdrphosts.conf is > configured correctly." > > In the vdr log I see messages "EPGSearch: error connecting to socket!". > My svdrphosts.conf is like with the previous version. Has something > changed? > > Eventually I seem to loose also tuners. The log files shows e.g. "ERROR: > can't open filter handle on '/dev/dvb/adapter1/demux0'". There are > finnish messages "ERROR (svdrp.c,126): Liian monta avointa tiedostoa" > that translates to too many open files. > > BR, > Seppo > > > > ___ > 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] Restricting a particular dvb card from tuning to channels with a selected modulation
Hi, the right way, of course, is to fix the driver, and make vdr check what device can do. I'm glad Petri had time to test it, and I hope to see the patch in next version of vdr. But I couldn't use the driver patch even if I wanted to patch kernel myself, as I actually have 3 devices with TDA10023 frontend, and only one of them is "reddo" :-) But i'm afraid my time for this project just run out. I'll continue later if/when the reddo driver patch arrives, I will test it, but until then I'll have to manage with the plugin, even if it crashes or not at exit(). I'll make an empty plugin with an empty hook, and if it still crashes at exit() it's not my fault :-) One more thought. Would it be possible to add vendor/product id as a method for cDevice (as well as the utility method for filename->id). And would it be possible (for a plugin) to manage device feature list and remove QAM256 from the reddo device. This way the plugin wouldn't have to actually do anything anymore when vdr is running, only fix this one time at plugin startup, and everything else would work 100% the same way before/after the driver is changed. Even though this isn't the right way, but we aren't living in a perfect world :-) And thanks, Teemu 2010/4/5 Klaus Schmidinger > > Well, then the driver needs to make a finer distinction and *properly* > set FE_CAN_QAM256. > > ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Restricting a particular dvb card from tuning to channels with a selected modulation
Ok, so the sysfs names of vendor/product are driver-dependent... All my usb devices have idVendor/idProduct even though only one of them is "Reddo". Tried to create the hook on Initialize(), still crashes on exit(). Haven't tried your patch, because as far as I know the driver claims it can do QAM256, and even if that was disabled today it would take some time to get into all linux distributions... Btw it even claims to support QAM256 on the product package, but it still doesn't work. I guess that's the reason they are so inexpensive here... Teemu 2010/4/5 Klaus Schmidinger > On 05.04.2010 12:43, Teemu Rantanen wrote: > > Hi, > > > > I tried also without delete cDeviceHook but it still crashed... > > Please try creating the cReddoDeviceHook in > cPluginDisableReddoQAM256::Initialize(), > as suggested in PLUGINS.html. > > > Well, the fixes are basically available in the plugin, as I copied the > > probe method (and modified slightly to suit the plugin). Those are: > > - The sysfs filenames are idVendor (subsystem_vendor) and idProduct > > (subsystem_device) > > This is what I get here: > > r...@video:/home/kls/vdr/VDR > ls -l > /sys/class/dvb/dvb0.frontend0/device/subsystem_* > -r--r--r-- 1 root root 4096 2010-04-05 16:25 > /sys/class/dvb/dvb0.frontend0/device/subsystem_device > -r--r--r-- 1 root root 4096 2010-04-05 16:25 > /sys/class/dvb/dvb0.frontend0/device/subsystem_vendor > > r...@video:/home/kls/vdr/VDR > ls -l > /sys/class/dvb/dvb0.frontend0/device/id* > ls: cannot access /sys/class/dvb/dvb0.frontend0/device/id*: No such file or > directory > > Maybe a bug in the driver? > > > - You need to set strtoul() base as 16 as the files don't have 0x in > > front of the hex > > r...@video:/home/kls/vdr/VDR > cat > /sys/class/dvb/dvb0.frontend0/device/subsystem_device > 0x > r...@video:/home/kls/vdr/VDR > cat > /sys/class/dvb/dvb0.frontend0/device/subsystem_vendor > 0x13c2 > > Maybe the "reddo" driver behaves differently than the FuSi driver? > > > What about making this an utility method in VDR? Give device file name > > and return id... > > Will do. > > > Have you tried whether it works with my patch? > In that case you wouldn't even need the whole plugin. > > Klaus > > ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Restricting a particular dvb card from tuning to channels with a selected modulation
Hi, I tried also without delete cDeviceHook but it still crashed... Well, the fixes are basically available in the plugin, as I copied the probe method (and modified slightly to suit the plugin). Those are: - The sysfs filenames are idVendor (subsystem_vendor) and idProduct (subsystem_device) - You need to set strtoul() base as 16 as the files don't have 0x in front of the hex What about making this an utility method in VDR? Give device file name and return id... Teemu 2010/4/5 Klaus Schmidinger > From PLUGINS.html: > > A plugin that creates a derived cDeviceHook ... > shall not delete this object. It will be automatically deleted when the > program ends > > I have added a similar note to device.h now. > > > ... > > - The sysfs probe code in full feature card plugin is buggy :-) > > Would you mind posting a patch that fixes this? > > Klaus > > ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Restricting a particular dvb card from tuning to channels with a selected modulation
Hi, There's a new version of the patch implemented as a plugin. It seems to work, but there are few things to notice: - Plugin does not cache which devices are Reddo devices, instead it probes sysfs every time QAM256 channel is being tuned into (on any device). It would be nice if cDeviceHook added a mechanism for a hook to store context for each device. Hooking into device probe (like full feature card plugin does) would be much nicer way, but it would interfere with other plugins which need the same mechanism. - VDR crashes at very late in exit() when clearing some list (most likely cDeviceHook list), but I couldn't find a way to avoid that - You may get syslog messages about trying to tune into QAM256 channel if/when EPG is being updated on the background. - The sysfs probe code in full feature card plugin is buggy :-) The plugin is available here: http://tvr.dy.fi/vdr/vdr-disablereddoqam256-0.0.1.tgz Teemu 2010/4/3 VDR User > Klaus added the ability to limit satellites to certain dvb card in > VDR-1.7.13. However, a lot of users have the need to do device > limiting at the transponder level, which VDR still can't do (and > likely will never do I think, unfortunately). But, Klaus also added > device hooks in VDR-1.7.13 as well: > > - Implemented cDeviceHook to allow plugins more control over which device > can > provide which transponder (thanks to Reinhard Nissl). > > This means that a plugin can be written that DOES provide device > limiting at the transponder level! Rnissl, as a test for the device > hook patch, threw together a quick skeleton plugin using hardcoded > values and it worked great. To finish the plugin, it would just need > support for a conf file where you define which > transponder:polarity:satellite & devices you want to limit them to. I > assume this file would be read into a table stored in memory, and then > referenced during a channel change for live tv or recording. > > If Rnissl see's this, maybe he'll elaborate further. > > Cheers, > Derek > > ___ > 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] Restricting a particular dvb card from tuning to channels with a selected modulation
I see... I actually noticed cDeviceHook but couldn't figure out if it could be used or not as there was no reference anywhere for it. This patch could be very nicely implemented fully in a plugin. I'll try that... Thanks, Teemu 2010/4/3 VDR User > Klaus added the ability to limit satellites to certain dvb card in > VDR-1.7.13. However, a lot of users have the need to do device > limiting at the transponder level, which VDR still can't do (and > likely will never do I think, unfortunately). But, Klaus also added > device hooks in VDR-1.7.13 as well: > > - Implemented cDeviceHook to allow plugins more control over which device > can > provide which transponder (thanks to Reinhard Nissl). > > This means that a plugin can be written that DOES provide device > limiting at the transponder level! Rnissl, as a test for the device > hook patch, threw together a quick skeleton plugin using hardcoded > values and it worked great. To finish the plugin, it would just need > support for a conf file where you define which > transponder:polarity:satellite & devices you want to limit them to. I > assume this file would be read into a table stored in memory, and then > referenced during a channel change for live tv or recording. > > If Rnissl see's this, maybe he'll elaborate further. > > Cheers, > Derek > > ___ > 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] DVB (usb) device hotswapping?
Hi, now that I've moved from pci dvb-c cards to usb dvb-c cards, I started to think what happens if dvb-devices are inserted/ejected when vdr is running. I haven't actually tried what happens, but it looks like hotswapping isn't supported? I guess adding a new device could be done quite easily e.g. by probing new cards. But ejecting a device might not be that easy I guess as there may be device pointers around vdr? This also leads to another problem with (linux and vdr) device numbering, as the nature of usb devices is lot less constant as with pci devices. I noticed that e.g. if you insert 3 devices (and have adapters 0,1,2) and remove the second adapter, then you only have (in linux) adapters 0 and 2. Even if the device is ejected when vdr is not running, it looks like to me (by reading cDvbDevice::Initialize()) that only adapter 0 is detected by vdr, as the initialize loop stops after adapter 1 is not found... Even though this isn't really a problem for most installations, I wanted to start a thread to give this some thought. Teemu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Restricting a particular dvb card from tuning to channels with a selected modulation
Hi, I bought a Reddo dvb-c usb card last week and wanted to make it a backup card without a risk of it accidentally tuning into QAM256 channel and spitting out garbage. It seems to be quite good value for money in Finland if you want dvb-c usb card and don't need QAM256. I followed this conversation through but as it seems there is no support for not using QAM256 in the driver nor in the VDR I decided to make a short patch for VDR. **WARNING** This patch was written in quite short time and it's not a good example of clean code, but it works (for me) and will be useful for anyone with Reddo card having QAM256 channels. It will be obsolete if/when QAM256 disable is done "the right way" (by asking the driver), but until then... Please try it out and let me know if there is a problem with it. The patch is available here: http://tvr.dy.fi/vdr/vdr-1.7.14-DisableReddoQAM256.diff Teemu 2009/10/29 Petri Helin > Hi, > > I have an USB DVB-C card (Reddo dvb-c, actually a relabelled Tongshi box), > which works very well with the current Linux driver excluding channels with > QAM-256 modulation. Would it be easy to check FE_CAN_QAM_256 in vdr before > trying to use a device to tune to a particular channel? In such a case I > could deactivate FE_CAN_QAM_256 in the drivers. I am using VDR 1.7.9, if it > makes a difference. > > Of course at the moment the proper solution would be to modify the > channels.conf to se a preselected card to tune to a particular channel, but > in this case there are two drawbacks with it. 1) I have more than one card > that I can use for QAM-256 channels and would like to use them all, and 2) > channels woth QAM-256 are also encrypted and I have yet to figure out how to > set both the CA code and the number of the card in the "Conditional access" > parameter in the channels.conf. > > Actually now that I think of it... How about separating the explicit card > selection and conditional access by introducing a new paremeter in the > channels.conf that could be used to preselect the card(s) that can tune to > the selected channel? > > > -Petri > > ___ > 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
