Re: [vdr] [ANNOUNCE] VDR successfully ported to Windows
Am 18.05.2012 23:30, schrieb WinVDR: I have successfully ported VDR to Windows :) The port is a *native* Windows port using MinGW-w64 (does NOT use cygwin). (I will post the patch when every thing is ready). The only unsolved problem is that section filtering functions in cDevice cannot be implemented on Windows since hardware drivers do not use file descriptors to deliver data, another problem is that some drivers like the SkyStar2 driver do not provide section filtering at all, so if you want that data you have to extract it from TS packets directly. To solve that problem we need to modify these functions and avoid using file descriptors: int cDevice::OpenFilter(u_short Pid, u_char Tid, u_char Mask); void cDevice::CloseFilter(int Handle); Does any body have suggestions about the best way to implement this. We might also consider implementing builtin section filtering in VDR so we can extract section filtering data from TS packets directly if the driver does not provide them. The libdvbpsi library might be handy for that purpose. I have implemented a plugin to support the SkyStar2 budget card and it works fine, but since cDevice::OpenFilter() is not implemented, all the recordings produced by VDR do not include section packets(PAT,PMT..) so they are not playable. nice work. sounds great :) will it be possible to have a windows vdr as a slave to a linux vdr via streamdev for example? if there is one thing missing since years it is a reliable frontend including osd on the windows platform. i for myself would really appreciate to have the opportunity to cut recordings or even to do some debug work on my plugins regardless on what os i am on. of course there may be lot more opportunities to make use of the port. greets Michael ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Initial Tuning fails with lnb sharing / device bonding
Am 13.05.2012 16:02, schrieb Klaus Schmidinger: On 12.05.2012 14:26, Midas wrote: Hi, to pick out one of the problems i am currently experiencing with lnb sharing i am starting a new thread. With device bonding or same cable usage (vdr 1.7.27 / 21 resp.) set, vdr absolutely fails to tune to any satellite channel after a restart. The only chance to regain tuning is to set up the devices individually, then switch to some channel, then switch between devices via femon and then set up back to lnb sharing /device bonding. This is not reliable and it may be necessary to repeat the steps until vdr finally works as expected. Afterwards there seem to be at least no serious problems with the setup and vdr keeps tuning as expected (yet maybe from time to time it looses live pic when switching polarization on timer start). Adapters (with indices set by module params): MSI TV@nywhere Satellite II PCI (Mantis / stb0899) adapter_nr=0 Technisat Skystar HD PCI (TT S3200 clone / stb0899) adapter_nr=1 Hauppauge WinTV Nova T-Stick (mt2060) adapter_nr=2 Notes: -This is a Diseqc setup. -The MSI card replaces my old Twinhan VP1020 SD DVBS device. In the old setup i had lnb sharing running for months but it turned out to be necessary to patch the Twinhan driver preventing it from sending any voltage signal, to achieve reliable switching between V and H. Conclusion: Something is wrong in how vdr administrates / sets up the master device (on restart). I tried to reproduce your setup here with - 2 budget DVB-S2 cards - TT S2-6400 as primary device, forcing it to always use transfer mode from devices 3 and 4 in order to mimic the behavior of your software device - devices 3 and 4 (the two budget cards) bonded and connected to a common sat cable I tuned to a channel with horizontal polarization and restarted VDR, and it tuned to that channel again without problems. Same with a vertically polarized channel. Conclusion: Something is wrong with your system (it turned out to be necessary to patch the Twinhan driver preventing it from sending any voltage signal, to achieve reliable switching between V and H seems to hint in that direction ;-). Klaus Nice work Klaus, thanx a lot. I didn't want to exclude something is borked in my setup though i do not have any idea at all what is going wrong. After your test i guess i am finally lost. Right now i am doing some research on the dvb cards drivers. As the issue appears with the old Twinhan and the new Mantis as well i switched from blaming the Twinhan driver to focus the S3200 driver now. Though i am not familar with the DVB API at all... Maybe someone else might contribute, especially Lars who reported similar issues in the big thread few days ago. I will report anything new. greets Michael ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Initial Tuning fails with lnb sharing / device bonding
Hi, to pick out one of the problems i am currently experiencing with lnb sharing i am starting a new thread. With device bonding or same cable usage (vdr 1.7.27 / 21 resp.) set, vdr absolutely fails to tune to any satellite channel after a restart. The only chance to regain tuning is to set up the devices individually, then switch to some channel, then switch between devices via femon and then set up back to lnb sharing /device bonding. This is not reliable and it may be necessary to repeat the steps until vdr finally works as expected. Afterwards there seem to be at least no serious problems with the setup and vdr keeps tuning as expected (yet maybe from time to time it looses live pic when switching polarization on timer start). Adapters (with indices set by module params): MSI TV@nywhere Satellite II PCI (Mantis / stb0899) adapter_nr=0 Technisat Skystar HD PCI (TT S3200 clone / stb0899) adapter_nr=1 Hauppauge WinTV Nova T-Stick (mt2060) adapter_nr=2 Notes: -This is a Diseqc setup. -The MSI card replaces my old Twinhan VP1020 SD DVBS device. In the old setup i had lnb sharing running for months but it turned out to be necessary to patch the Twinhan driver preventing it from sending any voltage signal, to achieve reliable switching between V and H. Conclusion: Something is wrong in how vdr administrates / sets up the master device (on restart). Greetz Michael ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [xineliboutput] remove top/bottom black borders (patch suggested)
Hi, some shows though being sent in native 16:9 still have black borders at top and bottom of the pics. To some extent this can be reduced but not completely removed by setting Overscan to 10% (don't confuse with Overscan Compensation) in xineliboutputs video menu. After some investigation i found a very simple patch that allows one to set Overscan to values 10 % (i limited to 20% in the patch). Furthermore i changed the sequence of the settings in xineliboutputs Video menu to make Overscan the topmost setting, so one now could configure some User keys in keymacros.conf. Feel free to play around with it. SNIP* diff -Naur vdr-plugin-xineliboutput//setup_menu.c /usr/src/vdr/PLUGINS/src/vdr-plugin-xineliboutput/setup_menu.c --- vdr-plugin-xineliboutput//setup_menu.c 2012-05-08 01:34:30.0 +0200 +++ /usr/src/vdr/PLUGINS/src/vdr-plugin-xineliboutput/setup_menu.c 2012-05-08 23:58:03.0 +0200 @@ -580,6 +580,11 @@ Add(SeparatorItem(tr(Video))); + Add(ctrl_overscan = + new cMenuEditTypedIntItem(tr(Overscan (crop image borders)), %, + newconfig.overscan, 0, 20, + tr(Off))); + Add(ctrl_vo_aspect_ratio = new cMenuEditStraI18nItem(tr(Aspect ratio), newconfig.vo_aspect_ratio, VO_ASPECT_count, xc.s_vo_aspects)); @@ -668,10 +673,6 @@ } } - Add(ctrl_overscan = - new cMenuEditTypedIntItem(tr(Overscan (crop image borders)), %, - newconfig.overscan, 0, 10, - tr(Off))); Add(ctrl_pp = new cMenuEditBoolItem(tr(Post processing (ffmpeg)), newconfig.ffmpeg_pp)); SNIP* hf Michael ___ 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
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
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
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] LNB sharing interrupts recordings with Twinhan DVBS
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. This not only freezes the liveview AV but also makes recordings stop
Re: [vdr] LNB sharing interrupts recordings with Twinhan DVBS
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). thx Michael ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] LNB sharing interrupts recordings with Twinhan DVBS
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? Greets, Michael ___ 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 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 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? Thank you Klaus for vdr and for your answer. Michael ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Stop live TV whilst in menu
Am 13.05.2011 01:49, schrieb Dominic Evans: On 13 May 2011 00:34, VDR Useruser@gmail.com wrote: On Thu, May 12, 2011 at 12:29 PM, Dominic Evansoldma...@gmail.com wrote: Is there any patch for VDR that stops Live TV whilst you're in the menus? None that I'm aware of but what's the point of doing that anyways? If it's a matter of being too distracting or something then you can always modify the themes transparency so the background is solid and increase the OSD size to cover the entire video frame. I already have OSD filling entire frame. It'd be nice if there was an option so that the frontend auto-muted whilst in menu and, even better if it didn't use cpu on live TV at all if I'm not watching. For example, currently if I want to watch two or three recordings one after another, I go to recordings menu, play 1 till end, hit back (returning me to recordings menu), play 2 till end and so on. Each time I go back to the recordings menu to choose the next recording, I'm forced to see and hear whatever happens to be showing at that time on the last channel tuned, even when it has no interest to me... ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr There are several plugins which do not match your needs exactly but could be worth a try. -suspendoutput: i have never tested this. my idea is that it would suspend after a timeout. it is available from the xineliboutput sourceforge page. -block: switches to another channel, if the current EPG title was blacklisted -sleeptimer: shuts down the machine or mutes vdr audio after a timeout ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr + epgsearch = no timers
i have similar issues with the live frontend. i can't say if always but surely certain timers won't be even searched (log review). The solution i have found is that after a restart of the vdr instance the timers will be searched, found and activated correctly. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
