-----Original Message----- From: vdr-bounces@linuxtv.org [mailto:vdr-bounces@linuxtv.org] On Behalf Of Rainer Zocholl Sent: Tuesday, February 15, 2005 11:40 AM To: vdr@linuxtv.org Subject: Re: [vdr] vdr-1.3.21: video data stream broken
...
I think this bug only can be reproduced if you are using 4x1 diseqc switches. I have exact same problem on my setup
To be exact: You have the same error messages ;-)
Actually I was battling this problem since vdr1.3.9 was released. I have four DVB-S cards, two FF and two budget cards and I tried variety of hardware combinations to solve it and I think I'm getting better at it too. Since I live in US, no one makes diseqc multiswitches here which would be appropriate for my setup and I can't get one from Germany because dealers just refuse to send it. So I'm looking for other ways to solve it.
and I traced it out to diseqc switches. Every time one of your cards switches one switch while other card is recording, the diseqc signal goes around LNB to another diseqc switch and moves its position too, and other card, which is recording, loses signal and you get VDSB.
That sounds like the problem i have with my "single LNB" environment: If i enabled EPG scan, after an hour the Video stream breaks.
I suggest getting latest 2.6 kernel and CVS drivers. Although I keep EPG disabled too but I never get these errors in single card setup, using 4 LNBs and I can run VDR for weeks without errors or reboots, and I do a lot of recordings. I'm still running vdr1.3.14 on my single FF card production machine and vdr1.3.21 is much better, I did not test 1.3.18-20 though.
I don't have scope but I've put the cards in different machines and if I set one of the machines to record while I'm flipping channels on second machine, the first one would got VDSB
or if I'm not recording, I'd just lose signal on first machine.
If I use only one, either machine, at the time, stuff works without any problems.
In my opinion, the only way to resolve this is to get diseqc-multiswitch.
So only users with diseqc enabled have that problem?
I think only users that use certain type of hardware setups like mine :) i.e. at least two 4x1 diseqc switches and as least two LNBs. I'm sure people with diseqc multiswitches don't have this problem.
Another possibility is your hardware setup, i.e. one or all of your Nexus cards are using bad PCI slots or sharing IRQ with very incompatible devices. Try moving cards to different PCI slots to resolve IRQ issues.
And why he didn't had/don't have the problem with 1.3.17? Was diseqc handling introduced with 1.3.18ff?
He'll get that problem back if I'm right and we all know when diseqc handling was introduced, and diseqc handling is out of question here. In my case VDSB does not happen every time, he just did not test it very well yet. It happened to me too, I'd make some change to my setup and all of the sudden the problem disappears and then eventually it would come back. VDR has nothing to do with it if its VDSB, its either drivers or signal loss. If you are sure the diseqc switch signal does not get through LNB back to other switches, I'd overview your hardware setup, bad RAM, CPU overheats, IRQ conflicts, PCI bandwidth bottlenecks and etc. because in my opinion, VDR just has nothing to do with this.
I think there were some VDSB related problems in vdr <1.3.13 because of buffer overflows but those all fixed now. Threading has some affect but usually you can notice it very quick: the VDR responds slowly, crashes, does not exit normally and etc. In my opinion, VDSB very much causes clean exit because it detects abnormal data in the stream and does not know how to handle it. VDR can be blamed for stressing your hardware but all that should be handled by drivers and kernel?
hm, but with same environment, vdr-1.3.17 (with nearly all plugins enabled) everything works?! Is this error introduced with > 1.3.17 ?
The easiest workaround is to disable the EPG scan in the EPG setup menu. Search the mailing list for details.
I did disable EPG scan but I still get the problem and I think because of my hardware setup.