I am running vdr 1.3.26, during the night it is changing state to SetPlayMode: 0 and the only way to bring it back up is to kill vdr, unload the skystar2 module and restart.
I am using a modified runvdr and starting as so: sudo ./runvdr '-P"xine -r" -P"femon"'
runvdr:
# $Id: runvdr 1.14 2004/11/21 11:30:00 kls Exp $
export LD_ASSUME_KERNEL=2.4.1 export LANG=fr_FR
DVBDIR="/lib/modules/2.6.11.10-epia/kernel/drivers/media/dvb/b2c2" VDRPRG="./vdr" VDRCMD="$VDRPRG -w 60 $*"
LSMOD="`/sbin/lsmod | grep -w 'skystar2' | wc -l`" KILL="/usr/bin/killall -q -TERM"
# Load driver if it hasn't been loaded already: if [ $LSMOD -eq 0 ] ; then (cd $DVBDIR; /sbin/modprobe skystar2) fi
while (true) do su $VDRUSR -c "$VDRCMD" if test $? -eq 0 -o $? -eq 2; then exit; fi date echo "restarting VDR" $KILL $VDRPRG sleep 10 (cd $DVBDIR; /sbin/modprobe -r skystar2; /sbin/modprobe skystar2) date done
I am not a super shell scripter and I know the problem is in here somewhere.
Cheers
Tony
tony wrote:
# Load driver if it hasn't been loaded already: if [ $LSMOD -eq 0 ] ; then (cd $DVBDIR; /sbin/modprobe skystar2) fi
here I need to load also the tuner module
modprobe dvb-core modprobe skystar2 modprobe mt312
Maybe your modules are actually loaded somewhere else, or maybe you have entries in /etc/modprobe.conf to load the tuner module when you load skystar2 (note the the first modprobe should not be necessary, in fact I'm using insmod instead of modprobe to test cvs drivers).
[.....]
(cd $DVBDIR; /sbin/modprobe -r skystar2; /sbin/modprobe skystar2)
I do an
rmmod skystar2 rmmod mt312 rmmod dvb-core
(of course it also depends on your modprobe.conf)
Bye
Le samedi 06 août 2005 à 13:42 +0200, Luca Olivetti a écrit :
tony wrote:
# Load driver if it hasn't been loaded already: if [ $LSMOD -eq 0 ] ; then (cd $DVBDIR; /sbin/modprobe skystar2) fi
here I need to load also the tuner module
modprobe dvb-core modprobe skystar2 modprobe mt312
My modprobe.conf is correctly set up so unloading/loading skystar2 looks after the other modules.
Nothing happens when I run my xine "watch tv" script (starts xine fullscreen and reads from vdr stream. The stream does not exist and vdr does not seem to know it has died.
I was out all afternoon and something happened vdr passed from one state to another like this:
vdr-xine: Client disconnected! ### I quit xine after news at lunch ::write(2048) returned -1, error 32: Relais bris (pipe) SetPlayMode: 0 SetPlayMode: 1 [vVMSetDigitalAudioDevice: 0 aA+9+12+13+14SetPlayMode: 0 SetPlayMode: 1 ### unknown event while I was absent [vVMSetDigitalAudioDevice: 0 aA+5+6+10+13+14]
Cheers
Tony
tony wrote:
Nothing happens when I run my xine "watch tv" script (starts xine fullscreen and reads from vdr stream. The stream does not exist and vdr does not seem to know it has died.
Ok, so this probably has nothing to do with your runvdr script. If it's the network patched version of xine, I found that sometimes it deadlocks and you need to manually kill vdr and/or xine and/or both, but that may be cause by some other plugin. I don't know if it also happens with the vanilla xine plugin.
Bye
Hi,
tony wrote:
I was out all afternoon and something happened vdr passed from one state to another like this:
vdr-xine: Client disconnected! ### I quit xine after news at lunch ::write(2048) returned -1, error 32: Relais bris (pipe) SetPlayMode: 0 SetPlayMode: 1 [vVMSetDigitalAudioDevice: 0 aA+9+12+13+14SetPlayMode: 0 SetPlayMode: 1 ### unknown event while I was absent [vVMSetDigitalAudioDevice: 0 aA+5+6+10+13+14]
One possible explanation would be that the channel's tranponder data has changed a bit and VDR was retuning this channel to honor the change.
What's your setup option concerning this issue? Do the logfiles report such an activity (you my need to run VDR with option "-l 3" go get this logged)?
Bye.
Le dimanche 07 août 2005 à 13:57 +0200, Reinhard Nissl a écrit :
I was out all afternoon and something happened vdr passed from one state to another like this:
vdr-xine: Client disconnected! ### I quit xine after news at lunch ::write(2048) returned -1, error 32: Relais bris (pipe) SetPlayMode: 0 SetPlayMode: 1 [vVMSetDigitalAudioDevice: 0 aA+9+12+13+14SetPlayMode: 0 SetPlayMode: 1 ### unknown event while I was absent [vVMSetDigitalAudioDevice: 0 aA+5+6+10+13+14]
One possible explanation would be that the channel's tranponder data has changed a bit and VDR was retuning this channel to honor the change.
What's your setup option concerning this issue? Do the logfiles report such an activity (you my need to run VDR with option "-l 3" go get this logged)?
This still has me stumped. What do you need to see? I have attached setup.conf
Tony
Hi,
tony wrote:
I was out all afternoon and something happened vdr passed from one state to another like this:
vdr-xine: Client disconnected! ### I quit xine after news at lunch ::write(2048) returned -1, error 32: Relais bris (pipe) SetPlayMode: 0 SetPlayMode: 1 [vVMSetDigitalAudioDevice: 0 aA+9+12+13+14SetPlayMode: 0 SetPlayMode: 1 ### unknown event while I was absent [vVMSetDigitalAudioDevice: 0 aA+5+6+10+13+14]
One possible explanation would be that the channel's tranponder data has changed a bit and VDR was retuning this channel to honor the change.
What's your setup option concerning this issue? Do the logfiles report such an activity (you my need to run VDR with option "-l 3" go get this logged)?
This still has me stumped. What do you need to see? I have attached setup.conf
I ment the following entry in setup.conf:
UpdateChannels = 4
So, do you find a logging message similar to
Aug 30 16:48:00 video vdr[19777]: changing pids of channel 2744 from 0+0:1121=deu:0 to 0+0:1121=deu;1122=deu:0
within the time you were absent?
Bye.
Le mercredi 31 août 2005 à 00:20 +0200, Reinhard Nissl a écrit :
I ment the following entry in setup.conf:
UpdateChannels = 4
So, do you find a logging message similar to
Aug 30 16:48:00 video vdr[19777]: changing pids of channel 2744 from 0+0:1121=deu:0 to 0+0:1121=deu;1122=deu:0
No. I am beginning to think it is an udev/dvb module thing rather than a VDR problem
Tony
-
Luca Olivetti -
Reinhard Nissl -
tony