[ANNOUNCE] runvdr extreme 0.4

kanotixer · 8. September 2009

Zitat

Original von Braumeister

Es fehlt beim initialen Start jedoch die Tastatur. Erst nach einem erneuten Starten funktioniert die Bedienung über Tastatur wie gewohnt.

Bis auf die Tastenkombination zum Abbrechen des xserver habe ich keine funktionierende Taste gefunden. Selbst die Tastaturkürzel zum Wechseln der Konsole z.B. mit Ctrl / Alt / F1 funktionieren nicht.

Kenn ich! Das Problem hatte ich auch. Spiel mal ein bisschen mit der Reihenfolge innerhalb von SysV. Je später X und VDR gestartet werden, umso wahrscheinlicher ist, dass die Tastatur funktioniert.
Warum das so ist, weiß ich auch nicht, wenn Du den Schuldigen hast, lass es uns wissen.

Grüße
kanotixer

tomas · 8. September 2009

Zitat

Original von kanotixer

Kenn ich! Das Problem hatte ich auch. Spiel mal ein bisschen mit der Reihenfolge innerhalb von SysV. Je später X und VDR gestartet werden, umso wahrscheinlicher ist, dass die Tastatur funktioniert.
Warum das so ist, weiß ich auch nicht, wenn Du den Schuldigen hast, lass es uns wissen.

...da bin ich ja mal gespannt, die Vermutung hatte ich auch....aber selbst wenn ich runvdr eine niedrige Startnummer verpasse, gibt es hier keine Probleme mit der Tastatur:

Code

S05loadcpufreq
S10rsyslog
S11runvdr
S12acpid
S12dbus
S16ssh
....

no problem...

Gruß, tomas

Braumeister · 9. September 2009

Danke für die tollen Hinweise.

Das Problem ist nun gelöst. Ich habe einige Werte durch probiert. Hier das Ergebnis:

Es wird RunLevel 3 als Default gestartet.

Bisher hatte ich S20runvdr verwendet. Alle Werte < 90 verändern nichts an der Situation.

Jetzt starte ich mit S93runvdr und es funktioniert bestens.

Code

...
S20cups
S20exim4
S20hddtemp
S20kerneloops
S20nfs-common
S20openbsd-inetd
S20samba
S24dhcdbd
S24hal
S26network-manager
S26network-manager-dispatcher
S30system-tools-backends
S89anacron
S89atd
S89cron
S90binfmt-support
S93runvdr
S99rc.local
S99rmnologin
S99stop-bootlogd

Alles anzeigen

Gruß Braumeister

M-Reimer · 9. September 2009

Problem mit "neueren" X-Servern könnte sein, dass Input-Devices via HAL erkannt werden. Es wird Zeit, dass die den Umstieg auf libudev schaffen. HAL ist eine ziemliche Krücke. Das ist das erste, was ich auf einem VDR-System tot mache. Die Input-Devices gebe ich dann in gewohnter Weise in der xorg.conf an.

Suche mal nach "AutoAddDevices" im Internet.

Braumeister · 9. September 2009

@Mreimer

Habe ein bischen getestet. Bei mir ändert sich mit dieser Option nichts. Oder habe ich da etwas falsch verstanden?

Hier ein Ausschnitt aus meiner xorg.conf:

Code

Section "ServerLayout"
    Identifier     "Layout[all]"
    Screen      0  "Screen0" 0 0
    InputDevice    "Keyboard0"
    InputDevice    "Mouse0"
    Option         "Clone" "off"
    Option         "Xinerama" "off"
    Option         "AutoAddDevices" "false" 
EndSection


Section "InputDevice"
    Identifier     "Keyboard0"
    Driver         "keyboard"
    Option         "XkbRules" "xfree86"
    Option         "XkbModel" "pc105"
    Option         "XkbLayout" "de"
    Option         "XkbVariant" "nodeadkeys"
EndSection

Alles anzeigen

Im Log steht dann:

Code

(**) Keyboard0: always reports core events
(**) Option "Protocol" "standard"
(**) Keyboard0: Protocol: standard
(**) Option "AutoRepeat" "500 30"
(**) Option "XkbRules" "xfree86"
(**) Keyboard0: XkbRules: "xfree86"
(**) Option "XkbModel" "pc105"
(**) Keyboard0: XkbModel: "pc105"
(**) Option "XkbLayout" "de"
(**) Keyboard0: XkbLayout: "de"
(**) Option "XkbVariant" "nodeadkeys"
(**) Keyboard0: XkbVariant: "nodeadkeys"
(**) Option "CustomKeycodes" "off"
(**) Keyboard0: CustomKeycodes disabled
(II) evaluating device (Keyboard0)
(II) XINPUT: Adding extended input device "Keyboard0" (type: KEYBOARD)
(II) evaluating device (Mouse0)
(II) XINPUT: Adding extended input device "Mouse0" (type: MOUSE)
(II) evaluating device (Mouse0)
(II) XINPUT: Adding extended input device "Mouse0" (type: MOUSE)
(II) evaluating device (Keyboard0)
(II) XINPUT: Adding extended input device "Keyboard0" (type: KEYBOARD)

Alles anzeigen

Wenn ich dann runvdr wieder früher starte (S20runvdr), so funktioniert die Tastatur nicht mehr.

Gruß Braumeister

tomas · 9. September 2009

Hallo,

wird jetzt zwar OT...aber ich glaube nicht, dass das Tastaturproblem mit hald zusammenhängt. Auf dem Rechner, mit dem ich das getestet habe, wird hal auch erst nach runvdr gestartet und es gibt keine Probleme mit der Tastatur.

Hier mal der komplette runlevel:

Code

README
S05loadcpufreq
S10rsyslog
S11runvdr
S12acpid
S12dbus
S16ssh
S19cpufrequtils
S20cpufreqd
S20ddclient
S20fancontrol
S20hddtemp
S20nfs-common
S20nfs-kernel-server
S24hal
S70bootlogs
S89atd
S89cron
S99jackd
S99rc.local
S99rmnologin
S99stop-bootlogd

Alles anzeigen

Vielleicht wirfst du mal die Dienste, die bei dir zusätzlich vorhanden sind, testweise raus und probierst es damit.

Cups, exim etc. sind auf einem VDR eigentlich eh nicht unbedingt sinnvoll und ob es überhaupt was/viel bringt, den VDR schon so früh starten zu lassen ist nochmal ne andere Frage;)

Gruß, tomas

M-Reimer · 10. September 2009

Urig

Nochmal wegen dem Kammeffekt:

Ich habe einen fertigen Patch an kls gesendet, der das Problem in VDR lösen würde. Allerdings habe ich das Problem im Voraus schonmal angesprochen und er meinte, dass die, für diesen Zweck vorgesehene, Lösung das Starten von VDR mit dem Parameter "--daemon" sei, was im Falle "runvdr-extreme" natürlich nicht funktionieren würde, da so auch die Tastatur als Eingabegerät wegfallen würde.

Patch ist, wie gesagt, via Mail an kls gegangen und ich hoffe, dass das eingebaut wird.

Für runvdr-extreme habe ich einen Patch gebaut, der das Problem "einigermaßen sauber" via stty umgeht. Der Patch hängt an. Ich habe auch das "Killen" an für sich etwas umstrukturiert und doppelten Code durch eine zweite Schleife unnötig gemacht. Bitte um Kommentare.

Chello · 11. September 2009

Hallo, bei älteren versionen konnte ich mir:

Code

ADDPARAM="> /var/log/vdr/vdr.log 2>&1"

ein extra log anlegen.

Bei 0.42 passiert bei:

Code

AddParams "> /var/log/vdr/vdr.log 2>&1"

nichts ausser ein 0 byte file

Wie könnte ich das mit 0.42 denn lösen ?

Urig · 12. September 2009

Zitat

Originally posted by Mreimer
Allerdings habe ich das Problem im Voraus schonmal angesprochen und er meinte, dass die, für diesen Zweck vorgesehene, Lösung das Starten von VDR mit dem Parameter "--daemon" sei

--daemon war schon immer eine untaugliche Lösung, da es damit keine Möglichkeit gibt, einen Neustart auszulösen. Und der staircase-Patch sah meiner Meinung nach unproblematisch und sinnvoll aus.

Deine Änderungen mit stty werde ich mir auf jeden Fall vor der nächsten Version nochmal vornehmen, und wahrscheinlich so in der Art übernehmen.

Zitat
Originally posted by Chello
Bei 0.42 passiert bei:
Code
AddParams "> /var/log/vdr/vdr.log 2>&1"
nichts ausser ein 0 byte file

Hmmm, stimmt, mit der Array-Kommandozeile geht das tatsächlich nicht mehr. Das '>' wird jetzt schlicht als Parameter übergeben, statt von der Shell interpretiert zu werden.

Was spricht denn gegen TERMINAL="/var/log/vdr/vdr.log" ?

Gruß,

Udo

Chello · 12. September 2009

Zitat

Original von Urig
Was spricht denn gegen TERMINAL="/var/log/vdr/vdr.log" ?

Gruß,

Udo

Das mir VDR nicht mehr startet

M-Reimer · 12. September 2009

Zitat

Original von Urig
--daemon war schon immer eine untaugliche Lösung, da es damit keine Möglichkeit gibt, einen Neustart auszulösen. Und der staircase-Patch sah meiner Meinung nach unproblematisch und sinnvoll aus.

Zumal hier offensichtlich ein Bug vorliegt. Da HasStdin durch das Setzen eines Terminals auf "1" gesetzt wird, wird beim Beenden für dieses Terminal die Einstellungen aus der Variable savedTm wiederhergestellt. Nur das die Variable dann nicht definiert ist und so "Mist" ins Terminal geschrieben wird.

Es gibt also meiner Meinung nach nur zwei Lösungen. Entweder man definiert savedTm (wie das mein Patch tut) oder man schreibt die Terminaleinstellungen bei gesetzten -t beim Beenden einfach garnicht zurück. Eine undefinierte Variable zum Zurückschreiben *ist und bleibt* ein Bug...

Besonders ärgerlich finde ich, dass Klaus nun auch schon auf meine zweite Mail nicht reagiert hat. Ich glaube nicht, dass ich unfreundlich gewesen bin. Warum also schlicht garkeine Antwort...

In meinem Thread in der Mailingliste hatte sich ja auch schon schlicht garnichts getan.

Ich warte jetzt noch bis morgen und dann poste ich meinen Patch (habe mittlerweile eine getestete, saubere Patch-Datei, die sowohl auf VDR 1.6 als auch 1.7.9 anwendbar ist) nochmal in die Mailingliste. Wenn dann wieder garnichts passiert, dann ist das einerseits bedenklich und andererseits gebe ich es dann endgültig auf, Fixes für VDR erstellen zu wollen. Mit negativem Feedback kann man leben, aber ich glaube nicht, dass ich es verdient habe, ignoriert zu werden.

Zitat

Deine Änderungen mit stty werde ich mir auf jeden Fall vor der nächsten Version nochmal vornehmen, und wahrscheinlich so in der Art übernehmen.

Gut zu wissen. Mein VDR ist zwar bereits mit meinem Patch gefixt, aber andere wollen vielleicht auch mit ungepatchten VDR eine saubere Ausgabe.

Dumm ist halt, dass der offizielle VDR eine runvdr hat, die VDR im Vordergrund startet. Da tritt das Problem nicht auf. Wobei ich mich frage, ob das Problem nicht auch mit einer offiziellen runvdr auftritt, wenn man das "offizielle" runvdr im Hintergrund startet, wie es wohl die meisten machen, da die offizielle runvdr ja blockiert, wenn sie im Vordergrund gestartet wird.

Mal eine dumme Idee:

vdr &

sorgt dafür, dass der Bug auftritt, aber was macht

( vdr ) &

(also VDR im Vordergrund in einer Subshell starten, welche im Hintergrund gestartet wird). Ich werde das mal probieren und melde mich dann wieder...

Was mir noch aufgefallen ist: Aus einem im Moment noch nicht klar eingegrenzten Grund wird "MAXRESTARTS" nicht berücksichtigt, wenn ein X-Server mit aufgestartet wird. Ich wollte das für einen Test auf "0" setzen, aber es wird dennoch bis zu 5 mal neu gestartet. Irgendwo geht die Einstellung wohl verloren.

dad401 · 26. September 2009

Zitat

Original von dad401
Dank Urigs neuer Funktionen XSTARTUP() und XSHUTDOWN(), habe ich mir meinen Aufruf für vdr-sxfe neugestaltet. Dabei ist auch ein Watchdog der vdr-sxfe neustarten lässt, falls es "TCP: fifo buffer full"-Fehler gibt.

Ich habe meinen Watchdog mal etwas angepasst, da dieser beim Vorspringen in Aufnahmen fälschlicherweise zuschlug:

Code

function XSTARTUP() {


    SHORTRUNTIMES=0
    LOGFILE="/var/log/vdr/vdr-sxfe.log"
    LOGFILE2="/ramdisk/vdr-sxfe.log"
    WATCHDOGLOG="/ramdisk/vdr-sxfe-watchdog.log"


    while true ; do
        VDRSXFE_PRG="/usr/local/bin/vdr-sxfe"
        VDRSXFE_ARGS="--post=tvtime:method=use_vo_driver --reconnect --fullscreen --silent --verbose xvdr://localhost"
        MAXRESTARTS=10
        RESTARTTIME=10


        cp -f $LOGFILE $LOGFILE.old
        sleep 5


        STARTTIME=`date +%s`
        $VDRSXFE_PRG $VDRSXFE_ARGS 2>&1 | tee $LOGFILE > $LOGFILE2
        STOPTIME=`date +%s`


        if [ $((STOPTIME-STARTTIME)) -le "$RESTARTTIME" ] ; then
            SHORTRUNTIMES=$((SHORTRUNTIMES+1))
            echo "vdr-sxfe died within $RESTARTTIME seconds, this happened $SHORTRUNTIMES time(s)." | tee -a $LOGFILE
            if [ $SHORTRUNTIMES -gt $MAXRESTARTS ] ; then
                echo "maximum short restarts of vdr-sxfe achieved - exiting vdr-sxfe start function" | tee -a $LOGFILE
                exit
            fi
        else
            echo "vdr-sxfe died within $((STOPTIME-STARTTIME)) seconds" | tee -a $LOGFILE
        fi
    done &
    SXFEPID=$!


    # start watchdog in case of TCP fifo buffer full failure
    echo "starting vdr-sxfe watchdog" > $WATCHDOGLOG
    while true ; do
    sleep 10
    LASTLINE=$(nl $LOGFILE2 | tail -n 1)
    LINENUM=$(echo $LASTLINE | cut -d' ' -f1)


    #echo $LASTLINE >> $WATCHDOGLOG
    #echo $LINENUM >> $WATCHDOGLOG


    if echo $LASTLINE | grep -q 'TCP: fifo buffer full' || echo $LASTLINE | grep -q 'Data thread terminated'; then
        echo "first watchdog check (found fifo buffer full or Data thread terminated)" >> $WATCHDOGLOG
        sleep 2
        LASTLINE2=$(nl $LOGFILE2 | tail -n 1)
        LINENUM2=$(echo $LASTLINE2 | cut -d' ' -f1)


        echo $LASTLINE2 >> $WATCHDOGLOG
        echo $LINENUM2 >> $WATCHDOGLOG


        if echo $LASTLINE2 | grep -q 'TCP: fifo buffer full' || echo $LASTLINE2 | grep -q 'Data thread terminated'; then
            echo "second watchdog check (found again fifo buffer full or Data thread terminated)" >> $WATCHDOGLOG
            if [ $LINENUM = $LINENUM2 ] ; then
                echo "third watchdog check (lines are equal, killing vdr-sxfe)" >> $WATCHDOGLOG
                echo "killing vdr-sxfe"
                kill -9 `pidof vdr-sxfe`
                sleep 10
            fi
        fi
    fi
    done &
    WATCHDOGPID=$!
}

Alles anzeigen

Marcus

dad401 · 25. Oktober 2009

Eine weitere Version, nun mit XBMC-Support und einfacherer Definition der "Watchdog"-Strings zum weiter ausbauen...

Code

function XSTARTUP() {


    SHORTRUNTIMES=0


    # logfiles / statusfiles
    SXFE_LOG="/var/log/vdr/vdr-sxfe.log"
    SXFE_LOG2="/ramdisk/vdr-sxfe.log"
    SXFE_WATCHLOG="/ramdisk/vdr-sxfe-watchdog.log"

    XBMC_LOG="/var/log/vdr/xbmc.log"
    XBMC_RUN="/tmp/xbmc.run"


    # vdr-sxfe or xbmc
    SXFE_PRG="/usr/local/bin/vdr-sxfe"
    SXFE_ARGS="--post=tvtime:method=use_vo_driver --reconnect --fullscreen --silent --verbose xvdr://localhost"

    XBMC_PRG="/usr/local/src/xbmc_vdr/XBMC/xbmc.bin"
    XBMC_ARGS=""


    # kill vdr-sxfe if the following strings are found
    SXFE_LOG_STRING[0]='TCP: fifo buffer full'
    SXFE_LOG_STRING[1]='Data thread terminated'
    SXFE_LOG_STRING[2]='read_block: no data source, returning NULL'

    mv -f $SXFE_WATCHLOG $SXFE_WATCHLOG.old


    while true ; do 
	MAXRESTARTS=10
	RESTARTTIME=10


	if [ -e $XBMC_RUN ]; then
	    cp -f $XBMC_LOG $XBMC_LOG.old
	    svdrpsend.pl REMO off | tee -a $XBMC_LOG


	    STARTTIME=`date +%s`
	    $XBMC_PRG $XBMC_ARGS 2>&1 | tee -a $XBMC_LOG
	    STOPTIME=`date +%s`
	    rm $XBMC_RUN


	    svdrpsend.pl REMO on | tee -a $XBMC_LOG


	    #sleep 3
	    #if [ $((STOPTIME-STARTTIME)) -le "$RESTARTTIME" ] ; then
		#SHORTRUNTIMES=$((SHORTRUNTIMES+1))
		#echo "$XBMC_PRG died within $RESTARTTIME seconds, this happened $SHORTRUNTIMES time(s)." | tee -a $XBMC_LOG
		#if [ $SHORTRUNTIMES -gt $MAXRESTARTS ] ; then
		#    echo "maximum short restarts of $XBMC_PRG achieved - exiting $XBMC_PRG start function" | tee -a $XBMC_LOG
		#    exit
		#fi
	    #else
		#echo "$XBMC_PRG died within $((STOPTIME-STARTTIME)) seconds" | tee -a $XBMC_LOG
	    #fi


	else
	    cp -f $SXFE_LOG $SXFE_LOG.old


	    STARTTIME=`date +%s`
	    $SXFE_PRG $SXFE_ARGS 2>&1 | tee -a $SXFE_LOG > $SXFE_LOG2
	    STOPTIME=`date +%s`


	    sleep 3
	    if [ $((STOPTIME-STARTTIME)) -le "$RESTARTTIME" ] ; then
		SHORTRUNTIMES=$((SHORTRUNTIMES+1))
		echo "$SXFE_PRG died within $RESTARTTIME seconds, this happened $SHORTRUNTIMES time(s)." | tee -a $SXFE_LOG
		if [ $SHORTRUNTIMES -gt $MAXRESTARTS ] ; then
		    echo "maximum short restarts of $SXFE_PRG achieved - exiting $SXFE_PRG start function" | tee -a $SXFE_LOG
		    exit
		fi
	    else
		echo "$SXFE_PRG died within $((STOPTIME-STARTTIME)) seconds" | tee -a $SXFE_LOG
	    fi
	fi
    done &
    SXFEPID=$!


    # start watchdog in case of TCP fifo buffer full failures etc.
    echo "starting vdr-sxfe watchdog at `date`" >> $SXFE_WATCHLOG

    while true ; do
    sleep 10


    # stop watchdog while XBMC is running
    while [ -e $XBMC_RUN ]; do
	sleep 1
    done

    LASTLINE=$(nl $SXFE_LOG2 | tail -n 1)
    LINENUM=$(echo $LASTLINE | cut -d' ' -f1)


    #echo $LASTLINE >> $SXFE_WATCHLOG
    #echo $LINENUM >> $SXFE_WATCHLOG


    for i in "${SXFE_LOG_STRING[@]}"
    do
	if echo $LASTLINE | grep -q "$i"; then
	    echo "first watchdog check (found $i)" >> $SXFE_WATCHLOG
    	    sleep 2


    	    LASTLINE2=$(nl $SXFE_LOG2 | tail -n 1)
    	    LINENUM2=$(echo $LASTLINE2 | cut -d' ' -f1)


    	    for j in "${SXFE_LOG_STRING[@]}"
    	    do
    		if echo $LASTLINE2 | grep -q "$j"; then
            	    echo "second watchdog check (found $j again)" >> $SXFE_WATCHLOG
            	    if [ $LINENUM = $LINENUM2 ] ; then
            		echo "third watchdog check (lines are equal, killing vdr-sxfe)" >> $SXFE_WATCHLOG
                	echo "killing vdr-sxfe"
                	kill -9 `pidof vdr-sxfe`
                	sleep 10
                	break 2
            	    fi
            	fi
    	    done
    	fi
    done


    done &
    WATCHDOGPID=$!
}


# X shutdown commands, called within the X server
function XSHUTDOWN() {
    kill $WATCHDOGPID
    kill $SXFEPID
    sleep 1
    VDRSXFEPID=`pidof vdr-sxfe`
    if [ $VDRSXFEPID ]; then
	kill -9 $VDRSXFEPID
    fi
}

Alles anzeigen

Gruss
Marcus

methodus · 11. November 2009

Ich hab das ganze jetzt auch mal ausprobiert, komme aber beim Starten nicht weiter. Sobald ich /etc/init.d/runvdr start aufrufe wird X gestartet, allerdings sofort wieder beendet, weil xineliboutput nicht mit dem XServer verbinden kann.

Ich habe die Zeilen zum Starten von X auskommentiert und xineliboutput mittels

Code

AddPlugin xineliboutput -l sxfe --video=vdpau

eingebunden. Fehlen irgendwelche Berechtigungen für den Zugriff?

//Edit: "xhost +" scheint nicht geholfen zu haben, es bleibt bei connection refused

Urig · 12. November 2009

Hmmm, schwierig zu sagen, woran es liegt. X Authorisation ist ein ziemliches Durcheinander.

So weit ich mich erinnere, funktioniert es bei mir so: Da der X-Server über xinit direkt gestartet wird, und dieser Aufruf kein -auth enthält, gilt die Default-Authorisierung, und localhost hat Vollzugriff. Dank -nolisten tcp sollte das Risiko begrenzt sein. Der Server läuft als root, und der User (gewechselt durch VDR) hat Zugriff.

Als root gestartet:

Code

#>xauth info
Authority file:       /root/.Xauthority
File new:             no
File locked:          no
Number of entries:    0
Changes honored:      yes
Changes made:         no
Current input:        (argv):1
#>xauth list
#>DISPLAY=:0 xhost
access control enabled, only authorized clients can connect

Alles anzeigen

Zum besseren Experimentieren gib mal auf einer root-Konsole das ein:

xinit /usr/bin/xterm -- /usr/bin/X -nolisten tcp :0

Das sollte einen root X-Server öffnen und bis zum exit offen halten. Danach kannst du z.B. von einer User-Konsole DISPLAY=:0 xclock versuchen.

Gruß,

Udo

izeman · 12. November 2009

Urig

ich benutze dein geniales runvdr schon seit es das erste mal erschienen ist, und es funktioniert auch ganz toll. jetzt habe ich den vdr neu aufgesetzt, und zwar mit xine und vdpau (also mit xserver)

ich habe die variable VDR_CHARSET_OVERRIDE="ISO-8859-15"

das funktioniert auch soweit, aber ERST wenn ich runvdr das 2te mal starte. also reboot, die variable ist nicht gesetzt. ich gehe auf die konsole und mache ein /etc/init.d/runvdr restart und alles passt. ein einfaches "restart" innerhalb von vdr (menu - setup - restart) bringt auch nichts.

ich habe versucht vdr von S20runvdr auf S99runvdr zu setzen - was natuerlich auch nichts brachte. hast du eine idee wo ich noch suchen koennte???

danke izeman

izeman · 12. November 2009

Zitat

Originally posted by izeman
Urig

ich benutze dein geniales runvdr schon seit es das erste mal erschienen ist, und es funktioniert auch ganz toll. jetzt habe ich den vdr neu aufgesetzt, und zwar mit xine und vdpau (also mit xserver)

ich habe die variable VDR_CHARSET_OVERRIDE="ISO-8859-15" in der .conf gesetzt

das funktioniert auch soweit, aber ERST wenn ich runvdr das 2te mal starte. also reboot, die variable ist nicht gesetzt. ich gehe auf die konsole und mache ein /etc/init.d/runvdr restart und alles passt. ein einfaches "restart" innerhalb von vdr (menu - setup - restart) bringt auch nichts.

ich habe versucht vdr von S20runvdr auf S99runvdr zu setzen - was natuerlich auch nichts brachte. hast du eine idee wo ich noch suchen koennte???

danke izeman

Alles anzeigen

EDIT: noch was vergessen. es kann auch sein dass das locale nicht richtig gesetzt wird. leider blick ich da nicht so ganz durch. tatsache ist, dass die umlaute erst richtig gesetzt werden wenn ich runvdr restarte.

methodus · 12. November 2009

Ich hab den Fehler, der mir allerdings bisher immer verborgen blieb. Wenn ich vdr-sxfe die Option --video=vdpau mitgebe, schmiert mir VDPAU wegen preemption ab. Ich schätze, dass er abbricht, weil beim Start die Displayauflösung geändert wird, womit der nicht klar kommt. Bleibt die Option weg, funktioniert es offenbar.

Urig · 13. November 2009

Zitat

Originally posted by izeman
das funktioniert auch soweit, aber ERST wenn ich runvdr das 2te mal starte. also reboot, die variable ist nicht gesetzt. ich gehe auf die konsole und mache ein /etc/init.d/runvdr restart und alles passt. ein einfaches "restart" innerhalb von vdr (menu - setup - restart) bringt auch nichts.

Für die nächste Version habe ich schon folgende Änderung vorgemerkt:

Diff

--- init.d.runvdr.Debian	(revision 1106)
+++ init.d.runvdr.Debian	(revision 1107)
@@ -28,6 +28,10 @@
 # Gracefully exit if the package has been removed.
 test -x $DAEMON || exit 0
 
+# Pull Debian default locale
+[ -e /etc/default/locale ] && . /etc/default/locale
+export LANG
+
 #
 #   Function that starts runvdr.
 #

Alles anzeigen

Bei den init-Skripten ist u.U. die systemweite Default-Sprache nicht gesetzt, das führt zu dem Problem, dass per init.d die Sprache nicht funktioniert, von Hand per Konsole jedoch schon. Ich denke, das dürfte dein Problem auch beheben. (Geklaut übrigens von den offiziellen Debian-initskripten für VDR.)

Gruß,

Udo

M-Reimer · 13. November 2009

Warum das LANG nicht einfach via runvdr.conf setzen? Ist ja möglich und mache ich auch so, um sicher zu gehen, dass die Sprache gesetzt ist.

In die runvdr.conf gehört ein

LANGUAGE="en_US.UTF-8"

und das Problem ist Geschichte. Vorteil dadurch: Es ist sicher UTF-8 gesetzt, was systemweit nicht zwingend so sein muss (bei Slackware wird z.B. standardmäßig kein UTF-8 genutzt).

Das "en_US" ist auch für Deutschland nicht falsch, denn die OSD-Sprache wählt man letztlich ohnehin via OSD.

[ANNOUNCE] runvdr extreme 0.4

Jetzt mitmachen!

Teilen