Hello It's probably common use but I didn't find good info how to do that: I record movie. It needs to be cutted (advertisment etc) and than compressed from mpeg2 to divx (because this format is smaller and playable on almost everything). Then movie is moved to library which scans IMDB or similair services to download meta information.
The goal is how to do that as most automatically as possible. For now it's rather long way: I convert .ts stream into mpeg2 (I forgot the name but it's software which allows cut file altogether, hovewer it's not user friendly becauses of small preview window), then convert it with some software (VirtualDub, Handbrake or ffmpeg), then rename and load into XBMC library.
I know it's rather lously connected with VDR, hovewer I have idea of using VDR as main tool in this toolchain. First it knows from EPG metadata the name of movie, so it can find it in IMDB (in fact both web interfaces can do that now). Next it allows to cut recordings (hovewer I prefer doing it with keyboard) and sometimes automate ads removing. The last piece is converting which also is available via some external scripts.
The problem is I would prefer doing it via web interface, because keyboard & mouse is more productive than remote. I hoverwer didn't find possibility to start converting via web interface.
What do you think about it?
Marx
On 4 May 2012 14:28, Marx acc.for.news@gmail.com wrote:
Hello It's probably common use but I didn't find good info how to do that: I record movie. It needs to be cutted (advertisment etc) and than compressed from mpeg2 to divx (because this format is smaller and playable on almost everything). Then movie is moved to library which scans IMDB or similair services to download meta information.
The goal is how to do that as most automatically as possible. For now it's rather long way: I convert .ts stream into mpeg2 (I forgot the name but it's software which allows cut file altogether, hovewer it's not user friendly becauses of small preview window), then convert it with some software (VirtualDub, Handbrake or ffmpeg), then rename and load into XBMC library.
I recommend looking at http://projects.vdr-developer.org/projects/vdrnfofs
This fuse-based tool allows you to make your VDR library easily understandable by XBMC by providing a suitable filename and .nfo pair:
e.g.,
$ ls -1 /srv/vdr/Green_Card* Green_Card_2011-09-07.23.28.1-0.rec.mpg Green_Card_2011-09-07.23.28.1-0.rec.nfo $ cat /srv/vdr/Green_Card*.nfo <?xml version="1.0" encoding="UTF-8" standalone="yes" ?> <movie> <title>Green Card</title> <plot>Gérard Depardieu's much-anticipated English language debut was, to some extent, lost in the fuss created by the revelations about his wild youth that appeared around the time of its release. Despite being unoriginal, full of narrative improbabilities and not as funny as it should be, this easy-going comedy from director Peter Weir has undeniable charm and features two engaging performances, with Andie MacDowell winning you over to her initially cold, calculating Manhattanite. Weir is a little heavy-handed with the comic set pieces, but he develops the romance with some care and turns the immigration inquiry into a nail-biting tear-jerker. It's slight and trite, but so what?||Director Peter Weir|Actor Gérard Depardieu|Actor Andie MacDowell|Actor Bebe Neuwirth|Actor Gregg Edelman|Actor Robert Prosky|Actor Jessie Keosian|Actor Ethan Phillips|Actor Mary Louise Wilson|Actor Lois Smith|Actor Conrad McLaren|</plot> </movie>
W dniu 2012-05-04 16:25, Dominic Evans pisze:
I recommend looking at http://projects.vdr-developer.org/projects/vdrnfofs
This fuse-based tool allows you to make your VDR library easily understandable by XBMC by providing a suitable filename and .nfo pair:
I know it and it seems nice but it's not exactly what I'm looking for. For example after conversion I doubt such recording still be working in VDR, so there is no sense to keep it in VDR recordings directory. Marx
On Fri, May 4, 2012 at 6:28 AM, Marx acc.for.news@gmail.com wrote:
For now it's rather long way: I convert .ts stream into mpeg2 (I forgot the name but it's software which allows cut file altogether, hovewer it's not user friendly becauses of small preview window), then convert it with some software (VirtualDub, Handbrake or ffmpeg), then rename and load into XBMC library.
I know it's rather lously connected with VDR, hovewer I have idea of using VDR as main tool in this toolchain. First it knows from EPG metadata the name of movie, so it can find it in IMDB (in fact both web interfaces can do that now). Next it allows to cut recordings (hovewer I prefer doing it with keyboard) and sometimes automate ads removing. The last piece is converting which also is available via some external scripts.
The problem is I would prefer doing it via web interface, because keyboard & mouse is more productive than remote. I hoverwer didn't find possibility to start converting via web interface.
You should look into VDR's "commands.conf". Next, don't do any unnecessary encoding. Cut the ads from the VDR recording either within VDR or using an external app, then transcode the editing recording directly to xvid. IMDB probably has an api to fetch data but if not, you still have the info from the VDR recording and can just parse IMDB webpages using a script.
One note about encoding... Do yourself a favor and use a target quantizer rather than target bitrate or filesize. Every video is different and has different requirements to maintain quality. There is no 'magic encoding settings' where one-size-fits-all, but using a target quantizer will get you closer than anything else. With xvid I'd recommend 3-5, and do a 2-pass encode. You may want to consider transcoding to x264 (in an mkv container) instead. In most cases it will give you better quality at smaller sizes. The mkv container is far more capable that avi.
These days the only reason to both with xvid is if you use some old & outdated standalone player that only supports xvid.
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
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 ;-)
Klaus
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
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 ;-)
Klaus
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
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 incase 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
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 incase 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 to write data on the disc though still being shown as recording in the vdr osd. Note that the liveview AV signal can be reactivated by switching to another channel. However this does not revive a recording. (Unsure: If i recollect correctly it is even possible to switch to channels which should not be allowed to switch to because of the active timer.)
How to reproduce: Install vdr 1.7.27, start watching a channel. After minutes the av signal freezes and the log tells us that device bonding has switched the master.
(Superstition: There is an imho very small chance this can be triggered by cpu load which might point to setup probs. I observed the issue once when i called the osd and in another case when i started compiling the media build drivers).
Greets
Michael
Date: Mon, 7 May 2012 14:34:57 +0200 From: vdrportal_midas@gmx.de To: vdr@linuxtv.org Subject: 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 incase 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 to write data on the disc though still being shown as recording in the vdr osd. Note that the liveview AV signal can be reactivated by switching to another channel. However this does not revive a recording. (Unsure: If i recollect correctly it is even possible to switch to channels which should not be allowed to switch to because of the active timer.)
How to reproduce: Install vdr 1.7.27, start watching a channel. After minutes the av signal freezes and the log tells us that device bonding has switched the master.
(Superstition: There is an imho very small chance this can be triggered by cpu load which might point to setup probs. I observed the issue once when i called the osd and in another case when i started compiling the media build drivers).
Greets
Michael
Here i have 3 devices in a bonding setup (without diseqc) / vdr-1.7.26. i have similar symptoms --> av-freezes. If i switch to another receiver (via femon) or another channel, av comes back. i have to dig deeper into the symptoms.
Markus
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 incase 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 to write data on the disc though still being shown as recording in the vdr osd. Note that the liveview AV signal can be reactivated by switching to another channel. However this does not revive a recording. (Unsure: If i recollect correctly it is even possible to switch to channels which should not be allowed to switch to because of the active timer.)
How to reproduce: Install vdr 1.7.27, start watching a channel. After minutes the av signal freezes and the log tells us that device bonding has switched the master.
(Superstition: There is an imho very small chance this can be triggered by cpu load which might point to setup probs. I observed the issue once when i called the osd and in another case when i started compiling the media build drivers).
Looks like this comes from the "bondedMasterFailed" mechanism, which switches the master to an other device if one fails. Apparently this disturbs live viewing or recordings if a channel can't be tuned to in the EPG scan (or otherwise).
Since the whole device bonding (formerly known as "LNB sharing") is a makeshift solution, anyway, I guess putting in that bondedMasterFailed mechanism was just too much of a good thing. I guess it will be better if I just drop that.
Please try whether the following change fixes your problem:
--- dvbdevice.c 2012/04/04 09:49:12 2.70 +++ dvbdevice.c 2012/05/08 09:49:11 @@ -878,9 +878,6 @@ isyslog("frontend %d/%d timed out while tuning to channel %d, tp %d", adapter, frontend, channel.Number(), channel.Transponder()); lastTimeoutReport = time(NULL); } - cMutexLock MutexLock(&bondMutex); - if (bondedTuner && bondedMaster) - bondedMasterFailed = true; // give an other tuner a chance in case the sat cable was disconnected continue; } WaitTime = 100; // allows for a quick change from tsTuned to tsLocked
Klaus
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. This not only freezes the liveview AV but also makes recordings stop to write data on the disc though still being shown as recording in the vdr osd. Note that the liveview AV signal can be reactivated by switching to another channel. However this does not revive a recording. (Unsure: If i recollect correctly it is even possible to switch to channels which should not be allowed to switch to because of the active timer.)
How to reproduce: Install vdr 1.7.27, start watching a channel. After minutes the av signal freezes and the log tells us that device bonding has switched the master.
(Superstition: There is an imho very small chance this can be triggered by cpu load which might point to setup probs. I observed the issue once when i called the osd and in another case when i started compiling the media build drivers).
Looks like this comes from the "bondedMasterFailed" mechanism, which switches the master to an other device if one fails. Apparently this disturbs live viewing or recordings if a channel can't be tuned to in the EPG scan (or otherwise).
Since the whole device bonding (formerly known as "LNB sharing") is a makeshift solution, anyway, I guess putting in that bondedMasterFailed mechanism was just too much of a good thing. I guess it will be better if I just drop that.
Please try whether the following change fixes your problem:
--- dvbdevice.c 2012/04/04 09:49:12 2.70 +++ dvbdevice.c 2012/05/08 09:49:11 @@ -878,9 +878,6 @@ isyslog("frontend %d/%d timed out while tuning to channel %d, tp %d", adapter, frontend, channel.Number(), channel.Transponder()); lastTimeoutReport = time(NULL); }
cMutexLock MutexLock(&bondMutex);if (bondedTuner && bondedMaster)bondedMasterFailed = true; // give an othertuner a chance in case the sat cable was disconnected continue; } WaitTime = 100; // allows for a quick change from tsTuned to tsLocked
It seems to work :). I tried for half a day and no issue happened, yet at a distinct timer start the liveview was not switched and froze but the timer correctly started and recorded the whole show.
Afterwards i changed my setup and exchanged the Twinhan DVBS with a Mantis DVBS2 card. I am observing other issues with lnb sharing now and will start a new thread once i know a bit better what is happening. Sorry to have no better news at this point.
Thank you Klaus.
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. This not only freezes the liveview AV but also makes recordings stop to write data on the disc though still being shown as recording in the vdr osd. Note that the liveview AV signal can be reactivated by switching to another channel. However this does not revive a recording. (Unsure: If i recollect correctly it is even possible to switch to channels which should not be allowed to switch to because of the active timer.)
How to reproduce: Install vdr 1.7.27, start watching a channel. After minutes the av signal freezes and the log tells us that device bonding has switched the master.
(Superstition: There is an imho very small chance this can be triggered by cpu load which might point to setup probs. I observed the issue once when i called the osd and in another case when i started compiling the media build drivers).
Looks like this comes from the "bondedMasterFailed" mechanism, which switches the master to an other device if one fails. Apparently this disturbs live viewing or recordings if a channel can't be tuned to in the EPG scan (or otherwise).
Since the whole device bonding (formerly known as "LNB sharing") is a makeshift solution, anyway, I guess putting in that bondedMasterFailed mechanism was just too much of a good thing. I guess it will be better if I just drop that.
Please try whether the following change fixes your problem:
--- dvbdevice.c 2012/04/04 09:49:12 2.70 +++ dvbdevice.c 2012/05/08 09:49:11 @@ -878,9 +878,6 @@ isyslog("frontend %d/%d timed out while tuning to channel %d, tp %d", adapter, frontend, channel.Number(), channel.Transponder()); lastTimeoutReport = time(NULL); }
cMutexLock MutexLock(&bondMutex);if (bondedTuner&& bondedMaster)bondedMasterFailed = true; // give an othertuner a chance in case the sat cable was disconnected continue; } WaitTime = 100; // allows for a quick change from tsTuned to tsLocked
It seems to work :). I tried for half a day and no issue happened, yet at a distinct timer start the liveview was not switched and froze but the timer correctly started and recorded the whole show.
Was that timer on the same polarization/band as the live view channel?
Klaus
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 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 to write data on the disc though still being shown as recording in the vdr osd. Note that the liveview AV signal can be reactivated by switching to another channel. However this does not revive a recording. (Unsure: If i recollect correctly it is even possible to switch to channels which should not be allowed to switch to because of the active timer.)
How to reproduce: Install vdr 1.7.27, start watching a channel. After minutes the av signal freezes and the log tells us that device bonding has switched the master.
(Superstition: There is an imho very small chance this can be triggered by cpu load which might point to setup probs. I observed the issue once when i called the osd and in another case when i started compiling the media build drivers).
Looks like this comes from the "bondedMasterFailed" mechanism, which switches the master to an other device if one fails. Apparently this disturbs live viewing or recordings if a channel can't be tuned to in the EPG scan (or otherwise).
Since the whole device bonding (formerly known as "LNB sharing") is a makeshift solution, anyway, I guess putting in that bondedMasterFailed mechanism was just too much of a good thing. I guess it will be better if I just drop that.
Please try whether the following change fixes your problem:
--- dvbdevice.c 2012/04/04 09:49:12 2.70 +++ dvbdevice.c 2012/05/08 09:49:11 @@ -878,9 +878,6 @@ isyslog("frontend %d/%d timed out while tuning to channel %d, tp %d", adapter, frontend, channel.Number(), channel.Transponder()); lastTimeoutReport = time(NULL); }
cMutexLock MutexLock(&bondMutex);if (bondedTuner&& bondedMaster)bondedMasterFailed = true; // give an othertuner a chance in case the sat cable was disconnected continue; } WaitTime = 100; // allows for a quick change from tsTuned to tsLocked
It seems to work :). I tried for half a day and no issue happened, yet at a distinct timer start the liveview was not switched and froze but the timer correctly started and recorded the whole show.
Was that timer on the same polarization/band as the live view channel?
Iirc not. The liveview was H whereas the timer was V.
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 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 to write data on the disc though still being shown as recording in the vdr osd. Note that the liveview AV signal can be reactivated by switching to another channel. However this does not revive a recording. (Unsure: If i recollect correctly it is even possible to switch to channels which should not be allowed to switch to because of the active timer.)
How to reproduce: Install vdr 1.7.27, start watching a channel. After minutes the av signal freezes and the log tells us that device bonding has switched the master.
(Superstition: There is an imho very small chance this can be triggered by cpu load which might point to setup probs. I observed the issue once when i called the osd and in another case when i started compiling the media build drivers).
Looks like this comes from the "bondedMasterFailed" mechanism, which switches the master to an other device if one fails. Apparently this disturbs live viewing or recordings if a channel can't be tuned to in the EPG scan (or otherwise).
Since the whole device bonding (formerly known as "LNB sharing") is a makeshift solution, anyway, I guess putting in that bondedMasterFailed mechanism was just too much of a good thing. I guess it will be better if I just drop that.
Please try whether the following change fixes your problem:
--- dvbdevice.c 2012/04/04 09:49:12 2.70 +++ dvbdevice.c 2012/05/08 09:49:11 @@ -878,9 +878,6 @@ isyslog("frontend %d/%d timed out while tuning to channel %d, tp %d", adapter, frontend, channel.Number(), channel.Transponder()); lastTimeoutReport = time(NULL); }
cMutexLock MutexLock(&bondMutex);if (bondedTuner&& bondedMaster)bondedMasterFailed = true; // give an othertuner a chance in case the sat cable was disconnected continue; } WaitTime = 100; // allows for a quick change from tsTuned to tsLocked
It seems to work :). I tried for half a day and no issue happened, yet at a distinct timer start the liveview was not switched and froze but the timer correctly started and recorded the whole show.
Was that timer on the same polarization/band as the live view channel?
Iirc not. The liveview was H whereas the timer was V.
Ok, i want to add a comment to the bonding workaround and describe some other strange issues i experienced with lnb sharing recently.
1. The workaround on the one hand helps in that recordings are not interrupted and liveview does not freeze anymore except maybe if a recording happens to be on another polarization as already described before. However the workaround leads to massive problems with initial tuning. Neither satellite transponder is tuned to (femon does not detect anything). It seems possible to workaround this by first set the DVBS devices to have different cables connected in the osd, then switch the devices via femon plugin and once you have signal then set the devices back to be connected to one cable. While i am writing this i had to double apply this workaround to have WDR HD Duisburg in the first run and TELE5 in the second run which probably was caused by problems with v/h switching.
Sidenote: The problems with device bonding interrupting live AV and recordings are clearly not hardware related i would say, as i exchanged the suspicious Twinhan device with a second DVB-S2 card (Mantis). The issue also happended in this setup.
2. I got completely confused in how vdr might count devices. As described i have two satellite and one terrestial device. VDR does detect four devices in total, which might be explainable by having an additional device in xineliboutput. Yet though my satellite devices are recognized first during boot and also recognized as the first two adapters at vdr start i can only setup lnb sharing cables for device 2 and device 3, which i hardly understand. But the most irritating issue is that vdr while being on a satellite channel lets me switch dvb devices via femon between one of the satellite cards and the DVB-T device...(yet these identifiers are given). On top of that this mostly coinheres with tuning problems (no signal) and the DVB-T device (again identified by the string in the femon osd) being the only or first device that can tune to the channel. These two issues raise the idea that there is something wrong in device counting inside vdr not necessarily in femon, i guess. Imho lnb cables should be possible to set to device 1 and 2 in my setup. Note that this is in fact offered sometimes yet rarely but if so initial tuning also works perfectly. As far as i can say this all happens with both vdr 1.7.21+lnb-sharing and vdr-1.7.27. Atm i am on 27 and i will post anything new.
I wish i had better facts to describe point 2 yet i am a bit lost how to reproduce or to understand what is happening at all. If i could be of further help please drop me a line.
thx
michael
Hi,
Am 09.05.2012 16:39, schrieb Midas: [...]
- 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.
Am 09.05.2012 19:29, schrieb Lars Hanisch:
Hi,
Am 09.05.2012 16:39, schrieb Midas: [...]
- 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
x264 is an option because it's defacto standard. What external software can I use to mark ads? For now I mainly use web interface, is there possibility to externally mark ads in recording and somehow start conversion from web interface? Marx
On Sat, May 5, 2012 at 3:17 PM, Marx acc.for.news@gmail.com wrote:
x264 is an option because it's defacto standard. What external software can I use to mark ads? For now I mainly use web interface, is there possibility to externally mark ads in recording and somehow start conversion from web interface?
I don't edit video in linux so I'm not sure what, or even if there's anything worth recommending. From what I've heard there isn't BUT, apparently there's a linux port of AviSynth called AvxSynth. If it works, you should be able to use that to easily remove ads and encode. You should also be able to trigger it from a web interface. Doing this with AviSynth in Windows is a piece of cake but I can't speak for the linux port. Additionally, maybe someone else would like to chime in with other alternatives..?
-
Dominic Evans -
it's me -
Klaus Schmidinger -
Lars Hanisch -
Marx -
Midas -
VDR User