Re: [vdr] [ANNOUNCE] epgfixer-plugin 0.1.0
On 09.05.2012 00:39, Richard Scobie wrote: Hi, On 05/08/2012 07:30 PM, Marx wrote: because I see no changes in EPG whatever I put in /etc/vdr/plugins/charset.conf Marx I may be way off the mark here - I have come in halfway through the thread and do not use this plugin, but wouldn't the path above be: /etc/vdr/plugins/epgfixer/charset.conf ? it may be true, doc shows only cp command: cp -R PLUGINS/src/epgfixer/epgfixer /path/to/vdrconf/plugins/ I will try with subdirectory Marx ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] LNB sharing interrupts recordings with Twinhan DVBS
Am 08.05.2012 11:57, schrieb Klaus Schmidinger: On 07.05.2012 14:34, Midas wrote: Am 06.05.2012 12:20, schrieb Klaus Schmidinger: On 06.05.2012 11:59, Midas wrote: Am 06.05.2012 11:51, schrieb Klaus Schmidinger: On 06.05.2012 01:29, Midas wrote: Am 05.05.2012 16:31, schrieb Klaus Schmidinger: On 05.05.2012 09:22, Midas wrote: Hi there, i have two satellite devices in an lnb-sharing setup. As said in the topic since update to vdr 1.7.27 recordings do not put data on the disk anymore and AV liveview with the vdr-sxfe frontend freezes if bonding sets the Twinhan Card to master. The setup is Technisat Skystar HD and KWorld DVBS Satellite Card (clone of Twinhan VP1020), so it is DVBS2 and DVBS mixed. VDR is 1.7.27. I have been using vdr 1.7.21 before with lnb-sharing applied. In the old setup there was a similar problem in that switching to vertical didn't work reliably or at all respectively. I managed to overcome this behaviour by patching the Twinhan driver to eliminate _any_ voltage output on the card. Once i found a working patch vdr has been running for months without any problems anymore. Note that the 'new' issue occurs with the vanilla Twinhan driver and my patched version as well. Is it maybe possible to force the use of one card as Master bonding device or does anyone have other ideas to overcome the problems? If the master of a set of bonded devices doesn't get a signal, VDR should automatically switch the master to the next of the bonded devices. See cDvbTuner::Action(), case tsTuned: if (bondedTunerbondedMaster) bondedMasterFailed = true; // give an other tuner a chance in case the sat cable was disconnected Of course, making sure the devices work properly in the first place might be a good idea ;-) Do i get the term Master wrong? Master in my assumption should be the device where the liveview signal comes from unless there is a recording in which case the device tuned to the recording transponder should be Master. In the context of device bonding master means the device that actually controls the LNB (either trough voltage/tone or DiSEqC). It has nothing to do with whether this device is used for live view or recording. In the first case the slave cannot steal the tuning parameters to prevent breaking liveview whereas in the second the liveview slave cannot interefere with the ongoing recording. Concerning my issue the ongoing search for transponders on the non-liveview device seems to break with the liveview device which should not happen. Yet in case of recordings i am bit unsure what interferes with what. I am also still unsure if it is a driver or lnb sharing issue though the v/h issue in my former setup points to the first case at least for a certain kind. Do i conclude right, setting the bondedMasterFailed to false in the switch construct would be a dirty hack to workaround my bogus setup? I'm not sure about that. I would suggest you use VDR with only one single device at a time and make sure it can receive all polarizations and bands. If a device or driver fails to deliver that, you should try to fix it. VDR assumes that a device actually works ;-) Just to add this missing info: Both devices work perfectly in a single device setup. Both devices were even capable in the former 1.7.21 dual device setup (with my patch). Well, then please post your exact setup together with a step-by-step set of instructions on how to reproduce the problem. Maybe I can reproduce it here on my system. Klaus Thank you Klaus for your offer and your effort. I guess this is one of the bugs (not necessarily a vdr one!) which are relativley hard to track. Yesterday i have reproduced the issue with a vanilla vdr 1.7.27 and the only plugin being xineliboutput to minimize potential bug sources. I did not observe any changes, the issue still appears. My setup: debian squeeze self-built Kernel 3.0.4 media-build git20120504 vdr 1.7.27 Technisat Skystar HD (PCI DVB-S2) - clone of and recognized as Technotrend S-3200 (stb0899) KWorld DVB Satellite card - clone of Twinhan VP1020 (PCI DVB-S) WinTV Nova T-Stick (USB DVB-T) xineliboutput cvs20120415 vdr-sxfe with vdpau on a 8400 GS PCIE nvidia driver 295.40 Satellite setup: One satellite cable that is being distributed with a splitter (diode protected). No priority circuit afaik. In vdr both devices are set to be connected to cable 1. This is a Diseqc setup and Astra 19.2E and Hotbird 13.0E are receivable. The rest of the setup remains unclear yet most likely the cable goes to a switch or something though surely not directly into the lnb. Symptoms: AV signal sometimes stops while watching a DVB-S(2) channel (T not tested). Concerning the log this most likely happens when vdr fails to tune to a channel while scanning for new transponders in the background. Device bonding then tries to make another tuner tune to this
Re: [vdr] VDR form packages
On 8.5.2012 21:29, Tobi wrote: Make some suggestions what Plugins you would like to see in official Debian! I'm going to upload markad to Debian soon. http://projects.vdr-developer.org/projects/plg-ttxtsubs Ttxtsubs would be nice. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] LNB sharing interrupts recordings with Twinhan DVBS
On 09.05.2012 09:46, Midas wrote: Am 08.05.2012 11:57, schrieb Klaus Schmidinger: On 07.05.2012 14:34, Midas wrote: Am 06.05.2012 12:20, schrieb Klaus Schmidinger: On 06.05.2012 11:59, Midas wrote: Am 06.05.2012 11:51, schrieb Klaus Schmidinger: On 06.05.2012 01:29, Midas wrote: Am 05.05.2012 16:31, schrieb Klaus Schmidinger: On 05.05.2012 09:22, Midas wrote: Hi there, i have two satellite devices in an lnb-sharing setup. As said in the topic since update to vdr 1.7.27 recordings do not put data on the disk anymore and AV liveview with the vdr-sxfe frontend freezes if bonding sets the Twinhan Card to master. The setup is Technisat Skystar HD and KWorld DVBS Satellite Card (clone of Twinhan VP1020), so it is DVBS2 and DVBS mixed. VDR is 1.7.27. I have been using vdr 1.7.21 before with lnb-sharing applied. In the old setup there was a similar problem in that switching to vertical didn't work reliably or at all respectively. I managed to overcome this behaviour by patching the Twinhan driver to eliminate _any_ voltage output on the card. Once i found a working patch vdr has been running for months without any problems anymore. Note that the 'new' issue occurs with the vanilla Twinhan driver and my patched version as well. Is it maybe possible to force the use of one card as Master bonding device or does anyone have other ideas to overcome the problems? If the master of a set of bonded devices doesn't get a signal, VDR should automatically switch the master to the next of the bonded devices. See cDvbTuner::Action(), case tsTuned: if (bondedTuner bondedMaster) bondedMasterFailed = true; // give an other tuner a chance in case the sat cable was disconnected Of course, making sure the devices work properly in the first place might be a good idea ;-) Do i get the term Master wrong? Master in my assumption should be the device where the liveview signal comes from unless there is a recording in which case the device tuned to the recording transponder should be Master. In the context of device bonding master means the device that actually controls the LNB (either trough voltage/tone or DiSEqC). It has nothing to do with whether this device is used for live view or recording. In the first case the slave cannot steal the tuning parameters to prevent breaking liveview whereas in the second the liveview slave cannot interefere with the ongoing recording. Concerning my issue the ongoing search for transponders on the non-liveview device seems to break with the liveview device which should not happen. Yet in case of recordings i am bit unsure what interferes with what. I am also still unsure if it is a driver or lnb sharing issue though the v/h issue in my former setup points to the first case at least for a certain kind. Do i conclude right, setting the bondedMasterFailed to false in the switch construct would be a dirty hack to workaround my bogus setup? I'm not sure about that. I would suggest you use VDR with only one single device at a time and make sure it can receive all polarizations and bands. If a device or driver fails to deliver that, you should try to fix it. VDR assumes that a device actually works ;-) Just to add this missing info: Both devices work perfectly in a single device setup. Both devices were even capable in the former 1.7.21 dual device setup (with my patch). Well, then please post your exact setup together with a step-by-step set of instructions on how to reproduce the problem. Maybe I can reproduce it here on my system. Klaus Thank you Klaus for your offer and your effort. I guess this is one of the bugs (not necessarily a vdr one!) which are relativley hard to track. Yesterday i have reproduced the issue with a vanilla vdr 1.7.27 and the only plugin being xineliboutput to minimize potential bug sources. I did not observe any changes, the issue still appears. My setup: debian squeeze self-built Kernel 3.0.4 media-build git20120504 vdr 1.7.27 Technisat Skystar HD (PCI DVB-S2) - clone of and recognized as Technotrend S-3200 (stb0899) KWorld DVB Satellite card - clone of Twinhan VP1020 (PCI DVB-S) WinTV Nova T-Stick (USB DVB-T) xineliboutput cvs20120415 vdr-sxfe with vdpau on a 8400 GS PCIE nvidia driver 295.40 Satellite setup: One satellite cable that is being distributed with a splitter (diode protected). No priority circuit afaik. In vdr both devices are set to be connected to cable 1. This is a Diseqc setup and Astra 19.2E and Hotbird 13.0E are receivable. The rest of the setup remains unclear yet most likely the cable goes to a switch or something though surely not directly into the lnb. Symptoms: AV signal sometimes stops while watching a DVB-S(2) channel (T not tested). Concerning the log this most likely happens when vdr fails to tune to a channel while scanning for new transponders in the background. Device bonding then tries to make another tuner tune to this channel which in this case obviously is the liveview device.
Re: [vdr] LNB sharing interrupts recordings with Twinhan DVBS
Am 09.05.2012 10:38, schrieb Klaus Schmidinger: On 09.05.2012 09:46, Midas wrote: Am 08.05.2012 11:57, schrieb Klaus Schmidinger: On 07.05.2012 14:34, Midas wrote: Am 06.05.2012 12:20, schrieb Klaus Schmidinger: On 06.05.2012 11:59, Midas wrote: Am 06.05.2012 11:51, schrieb Klaus Schmidinger: On 06.05.2012 01:29, Midas wrote: Am 05.05.2012 16:31, schrieb Klaus Schmidinger: On 05.05.2012 09:22, Midas wrote: Hi there, i have two satellite devices in an lnb-sharing setup. As said in the topic since update to vdr 1.7.27 recordings do not put data on the disk anymore and AV liveview with the vdr-sxfe frontend freezes if bonding sets the Twinhan Card to master. The setup is Technisat Skystar HD and KWorld DVBS Satellite Card (clone of Twinhan VP1020), so it is DVBS2 and DVBS mixed. VDR is 1.7.27. I have been using vdr 1.7.21 before with lnb-sharing applied. In the old setup there was a similar problem in that switching to vertical didn't work reliably or at all respectively. I managed to overcome this behaviour by patching the Twinhan driver to eliminate _any_ voltage output on the card. Once i found a working patch vdr has been running for months without any problems anymore. Note that the 'new' issue occurs with the vanilla Twinhan driver and my patched version as well. Is it maybe possible to force the use of one card as Master bonding device or does anyone have other ideas to overcome the problems? If the master of a set of bonded devices doesn't get a signal, VDR should automatically switch the master to the next of the bonded devices. See cDvbTuner::Action(), case tsTuned: if (bondedTuner bondedMaster) bondedMasterFailed = true; // give an other tuner a chance in case the sat cable was disconnected Of course, making sure the devices work properly in the first place might be a good idea ;-) Do i get the term Master wrong? Master in my assumption should be the device where the liveview signal comes from unless there is a recording in which case the device tuned to the recording transponder should be Master. In the context of device bonding master means the device that actually controls the LNB (either trough voltage/tone or DiSEqC). It has nothing to do with whether this device is used for live view or recording. In the first case the slave cannot steal the tuning parameters to prevent breaking liveview whereas in the second the liveview slave cannot interefere with the ongoing recording. Concerning my issue the ongoing search for transponders on the non-liveview device seems to break with the liveview device which should not happen. Yet in case of recordings i am bit unsure what interferes with what. I am also still unsure if it is a driver or lnb sharing issue though the v/h issue in my former setup points to the first case at least for a certain kind. Do i conclude right, setting the bondedMasterFailed to false in the switch construct would be a dirty hack to workaround my bogus setup? I'm not sure about that. I would suggest you use VDR with only one single device at a time and make sure it can receive all polarizations and bands. If a device or driver fails to deliver that, you should try to fix it. VDR assumes that a device actually works ;-) Just to add this missing info: Both devices work perfectly in a single device setup. Both devices were even capable in the former 1.7.21 dual device setup (with my patch). Well, then please post your exact setup together with a step-by-step set of instructions on how to reproduce the problem. Maybe I can reproduce it here on my system. Klaus Thank you Klaus for your offer and your effort. I guess this is one of the bugs (not necessarily a vdr one!) which are relativley hard to track. Yesterday i have reproduced the issue with a vanilla vdr 1.7.27 and the only plugin being xineliboutput to minimize potential bug sources. I did not observe any changes, the issue still appears. My setup: debian squeeze self-built Kernel 3.0.4 media-build git20120504 vdr 1.7.27 Technisat Skystar HD (PCI DVB-S2) - clone of and recognized as Technotrend S-3200 (stb0899) KWorld DVB Satellite card - clone of Twinhan VP1020 (PCI DVB-S) WinTV Nova T-Stick (USB DVB-T) xineliboutput cvs20120415 vdr-sxfe with vdpau on a 8400 GS PCIE nvidia driver 295.40 Satellite setup: One satellite cable that is being distributed with a splitter (diode protected). No priority circuit afaik. In vdr both devices are set to be connected to cable 1. This is a Diseqc setup and Astra 19.2E and Hotbird 13.0E are receivable. The rest of the setup remains unclear yet most likely the cable goes to a switch or something though surely not directly into the lnb. Symptoms: AV signal sometimes stops while watching a DVB-S(2) channel (T not tested). Concerning the log this most likely happens when vdr fails to tune to a channel while scanning for
Re: [vdr] VDR form packages
On 09/05/12 00:54, Tony Houghton wrote: Make some suggestions what Plugins you would like to see in official Debian! I'm going to upload markad to Debian soon. I'd like eepg to be packaged, but only if the memory leak can be fixed and it's made to work on Freeview HD. The Huffman tables and marker bytes at the start of the strings are the same as for Freesat so it just needs changing to apply this decoding to the standard EIT pids if necessary, not only to Freesat's pids. I did fix a couple of memory leaks in my own local build of eepg, but I still find issues with it killing off my tuners after extended use, so I'm still not using it. Tbh, it would probably be better if someone coded it from scratch. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR form packages
On Wed, 09 May 2012 12:14:48 +0100 Dominic Evans oldma...@gmail.com wrote: On 09/05/12 00:54, Tony Houghton wrote: I'd like eepg to be packaged, but only if the memory leak can be fixed and it's made to work on Freeview HD. The Huffman tables and marker bytes at the start of the strings are the same as for Freesat so it just needs changing to apply this decoding to the standard EIT pids if necessary, not only to Freesat's pids. I did fix a couple of memory leaks in my own local build of eepg, but I still find issues with it killing off my tuners after extended use, so I'm still not using it. Tbh, it would probably be better if someone coded it from scratch. Or rework the alternative patch as a plugin. The patch seems quite stable to me. But it only supports Freesat and Freeview, not Sky and whatever else eepg supports. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] LNB sharing interrupts recordings with Twinhan DVBS
Am 09.05.2012 10:45, schrieb Midas: Am 09.05.2012 10:38, schrieb Klaus Schmidinger: On 09.05.2012 09:46, Midas wrote: Am 08.05.2012 11:57, schrieb Klaus Schmidinger: On 07.05.2012 14:34, Midas wrote: Am 06.05.2012 12:20, schrieb Klaus Schmidinger: On 06.05.2012 11:59, Midas wrote: Am 06.05.2012 11:51, schrieb Klaus Schmidinger: On 06.05.2012 01:29, Midas wrote: Am 05.05.2012 16:31, schrieb Klaus Schmidinger: On 05.05.2012 09:22, Midas wrote: Hi there, i have two satellite devices in an lnb-sharing setup. As said in the topic since update to vdr 1.7.27 recordings do not put data on the disk anymore and AV liveview with the vdr-sxfe frontend freezes if bonding sets the Twinhan Card to master. The setup is Technisat Skystar HD and KWorld DVBS Satellite Card (clone of Twinhan VP1020), so it is DVBS2 and DVBS mixed. VDR is 1.7.27. I have been using vdr 1.7.21 before with lnb-sharing applied. In the old setup there was a similar problem in that switching to vertical didn't work reliably or at all respectively. I managed to overcome this behaviour by patching the Twinhan driver to eliminate _any_ voltage output on the card. Once i found a working patch vdr has been running for months without any problems anymore. Note that the 'new' issue occurs with the vanilla Twinhan driver and my patched version as well. Is it maybe possible to force the use of one card as Master bonding device or does anyone have other ideas to overcome the problems? If the master of a set of bonded devices doesn't get a signal, VDR should automatically switch the master to the next of the bonded devices. See cDvbTuner::Action(), case tsTuned: if (bondedTuner bondedMaster) bondedMasterFailed = true; // give an other tuner a chance in case the sat cable was disconnected Of course, making sure the devices work properly in the first place might be a good idea ;-) Do i get the term Master wrong? Master in my assumption should be the device where the liveview signal comes from unless there is a recording in which case the device tuned to the recording transponder should be Master. In the context of device bonding master means the device that actually controls the LNB (either trough voltage/tone or DiSEqC). It has nothing to do with whether this device is used for live view or recording. In the first case the slave cannot steal the tuning parameters to prevent breaking liveview whereas in the second the liveview slave cannot interefere with the ongoing recording. Concerning my issue the ongoing search for transponders on the non-liveview device seems to break with the liveview device which should not happen. Yet in case of recordings i am bit unsure what interferes with what. I am also still unsure if it is a driver or lnb sharing issue though the v/h issue in my former setup points to the first case at least for a certain kind. Do i conclude right, setting the bondedMasterFailed to false in the switch construct would be a dirty hack to workaround my bogus setup? I'm not sure about that. I would suggest you use VDR with only one single device at a time and make sure it can receive all polarizations and bands. If a device or driver fails to deliver that, you should try to fix it. VDR assumes that a device actually works ;-) Just to add this missing info: Both devices work perfectly in a single device setup. Both devices were even capable in the former 1.7.21 dual device setup (with my patch). Well, then please post your exact setup together with a step-by-step set of instructions on how to reproduce the problem. Maybe I can reproduce it here on my system. Klaus Thank you Klaus for your offer and your effort. I guess this is one of the bugs (not necessarily a vdr one!) which are relativley hard to track. Yesterday i have reproduced the issue with a vanilla vdr 1.7.27 and the only plugin being xineliboutput to minimize potential bug sources. I did not observe any changes, the issue still appears. My setup: debian squeeze self-built Kernel 3.0.4 media-build git20120504 vdr 1.7.27 Technisat Skystar HD (PCI DVB-S2) - clone of and recognized as Technotrend S-3200 (stb0899) KWorld DVB Satellite card - clone of Twinhan VP1020 (PCI DVB-S) WinTV Nova T-Stick (USB DVB-T) xineliboutput cvs20120415 vdr-sxfe with vdpau on a 8400 GS PCIE nvidia driver 295.40 Satellite setup: One satellite cable that is being distributed with a splitter (diode protected). No priority circuit afaik. In vdr both devices are set to be connected to cable 1. This is a Diseqc setup and Astra 19.2E and Hotbird 13.0E are receivable. The rest of the setup remains unclear yet most likely the cable goes to a switch or something though surely not directly into the lnb. Symptoms: AV signal sometimes stops while watching a DVB-S(2) channel (T not tested). Concerning the log this most likely happens when vdr fails to tune to
Re: [vdr] Filesystem hierachy standard patch needs review.
Hello, what is the current status in this topic? Anyone working on this? Yours Manuel Klaus Schmidinger wrote: On 09.04.2012 15:18, Udo Richter wrote: Am 09.04.2012 11:54, schrieb Klaus Schmidinger: However, there is one thing in the current behavior that I would even consider a bug: if one starts VDR with vdr -v /mydir it uses /mydir as the video directory, but still uses /video for the configuration files. I believe that as long as there is no explicit -c option given, the config directory should follow what's given in the -v option. You're sure about -c following -v? It worked that way until 1.5.8, but has been dropped in favor of the final changes regarding CONFDIR in 1.5.11. I don't see any reason to change that. Or did you mess up --config with --cachedir? Happened to me too. I surely didn't mean --cachedir because my VDR doesn't have that option (yet) ;-). A while ago I ran a test and wanted to use a different video directory, so I started VDR with the -v option. I was surprised to see that it still loaded the config files from the default /video directory. In the latter case: In my patch, the cacheDirectory follows the VideoDirectory, even if the latter is set by --video, but only as long as CACHEDIR is un-set. (Same applies to --config and RESDIR.) I'm not sure whether this should also be the case if VDR is compiled to be FHS compliant. In that case users should know about the various folders, and setting a --video directory should not have precedence over CACHEDIR=/var/lib/vdr. The only thing I could think of is to check whether CACHEDIR==VIDEODIR, and only then let cacheDirectory follow --video, but I would prefer to not use such hacks. Currently VDR has only two directories, 'video' and 'config'. The idea is that by default the video directory is /video, and the config directory is the same. If -v is given, this changes the video directory, and since config follows video (or at least is supposed to), the config files will be loaded from the new video directory. Only if there is an explicit -c option shall the config directory be different from the video directory. I'd like to see a similar mechanism for the two new directories 'cache' and 'resource'. By default they follow 'config' and can only be different if the respective options are given. The default values for 'cache' and 'resource' shall be empty, in which case they follow 'config'. If VDR is compiled with non-empty values for 'cache' and/or 'resource', simply let them no longer follow 'config' (same behavior as if a command line option has been given). Don't know whether the patch already behaves this way (haven't checked), but that's the way it should be. 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 form packages
On 09/05/12 14:32, Tony Houghton wrote: On Wed, 09 May 2012 12:14:48 +0100 Dominic Evansoldma...@gmail.com wrote: On 09/05/12 00:54, Tony Houghton wrote: I'd like eepg to be packaged, but only if the memory leak can be fixed and it's made to work on Freeview HD. The Huffman tables and marker bytes at the start of the strings are the same as for Freesat so it just needs changing to apply this decoding to the standard EIT pids if necessary, not only to Freesat's pids. I did fix a couple of memory leaks in my own local build of eepg, but I still find issues with it killing off my tuners after extended use, so I'm still not using it. Tbh, it would probably be better if someone coded it from scratch. Or rework the alternative patch as a plugin. The patch seems quite stable to me. But it only supports Freesat and Freeview, not Sky and whatever else eepg supports. A smaller amount of work might be just to extend the patch to add a setup option to VDR's menus to enable/disable it (and have it disabled by default). The it could potentially be added to the standard patchlist for debian/ubuntu/yavdr. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR form packages
On Wed, 09 May 2012 16:31:23 +0100 Dominic Evans oldma...@gmail.com wrote: On 09/05/12 14:32, Tony Houghton wrote: On Wed, 09 May 2012 12:14:48 +0100 Dominic Evansoldma...@gmail.com wrote: [Problems with eepg] Tbh, it would probably be better if someone coded it from scratch. Or rework the alternative patch as a plugin. The patch seems quite stable to me. But it only supports Freesat and Freeview, not Sky and whatever else eepg supports. A smaller amount of work might be just to extend the patch to add a setup option to VDR's menus to enable/disable it (and have it disabled by default). The it could potentially be added to the standard patchlist for debian/ubuntu/yavdr. That sounds like a good idea. Tobias, would you be willing to add this patch if enabling it is made optional? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR form packages
On 08.05.2012 21:18, VDR User wrote: If you haven't added it already, you should consider adding softhddevice. I'll take a look at this. Tobias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] LNB sharing interrupts recordings with Twinhan DVBS
Hi, Am 09.05.2012 16:39, schrieb Midas: [...] 2. I got completely confused in how vdr might count devices. As described i have two satellite and one terrestial device. [...] You can try to set the adapter number with the module parameter adapter_nr, so the devices have the same order on every boot. That will remove one possible cause of failure. See modinfo driver. Lars. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] LNB sharing interrupts recordings with Twinhan DVBS
Am 09.05.2012 19:29, schrieb Lars Hanisch: Hi, Am 09.05.2012 16:39, schrieb Midas: [...] 2. I got completely confused in how vdr might count devices. As described i have two satellite and one terrestial device. [...] You can try to set the adapter number with the module parameter adapter_nr, so the devices have the same order on every boot. That will remove one possible cause of failure. See modinfo driver. i did already. yet the two dvbs cards are still device 2 and 3 in the device bonding setup in the osd and 0 and 1 in the module params. I will report if the dvbt/dvbs confusion happens again. tx michael ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR form packages
On 09.05.2012 18:16, Tony Houghton wrote: That sounds like a good idea. Tobias, would you be willing to add this patch if enabling it is made optional? Not if this can be done with a plugin as well. Where can I find the most recent version of the patch? Tobias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR form packages
On Wed, 09 May 2012 21:49:04 +0200 Tobi listacco...@e-tobi.net wrote: On 09.05.2012 18:16, Tony Houghton wrote: That sounds like a good idea. Tobias, would you be willing to add this patch if enabling it is made optional? Not if this can be done with a plugin as well. Where can I find the most recent version of the patch? This is the latest version which Mario Schulz sent me. It has the Huffman tables built in to the code now instead of as separate files. vdr.patch.gz Description: GNU Zip compressed data ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
