...
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.
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 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.
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?
I did disable EPG scan but I still get the problem and I think because of my hardware setup.
Vladimir Shved wrote:
Installed VDR 1.3.21 yesterday with CVS drivers from 25.01.2005, and while I did not see any problems with VDR 1.3.19 I previously had installed, I immediately got VDSB messages with VDR 1.3.21 when I recorded with the FF card while I was zapping with the Nova-S (because the FF was "occupied"). I admit: I did not make such an extensive tests with VDR 1.3.19 - simply did my recordings and did not touch the remote (I know VDSB and UPT from the past...). I could also check this version again, but I can´t think of any restart VDR 1.3.19 made. The only differences between the two installs: I additionally installed the text2skin-1.0 and the streamclient plugin - of course, I can also check it again with plain vanilla.
Once again my setup: SuSE 9.2 with original kernel 2.6.8, CVS drivers from 25.01.2005, 1 FF Nexus and 1 budget Nova-S, no diseq, just a multiswitch :-)
With kind regards
Joerg
Vladimir Shved wrote:
Same here, reloading the drivers and restarting VDR also did not help - a VDSB nearly every minute. Only after a restart of the complete system, it seemed to work as expected. Later, I turned EPG scan on again, and I had no further problems.
I have set a lot of timers today for testing the VDSB behaviour. Let´s see what my logs will say this evening... Looking out of the windows: Did I have a bad but error free signal yesterday evening at 1:00 am because it was snowing?
With kind regards
Joerg
-
Joerg Knitter -
Vladimir Shved