[ANNOUNCE] runvdr extreme 0.4

  • Quote

    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

    Full-Budget: Athlon XP 2600+ auf Asrock K7VT4A+, XFX Nvidia Geforce 6200, Hauppauge Nova-S Plus.
    HjsLfs 1.2.8 mit VDR 1.6.0-2 und xineliboutput.

  • Quote

    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
    1. S05loadcpufreq
    2. S10rsyslog
    3. S11runvdr
    4. S12acpid
    5. S12dbus
    6. S16ssh
    7. ....


    no problem...


    Gruß, tomas

  • 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.



    Gruß Braumeister

    1) yaVDR (1.7.16-12yavdr4)
    2) Vdr 1.7.9 - Debian Lenny Kernel 2.6.31.6 - VDPAU - xine
    3) HW: TT S2-1600, TT-S2-3200

  • 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.

  • @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:



    Im Log steht dann:



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


    Gruß Braumeister

    1) yaVDR (1.7.16-12yavdr4)
    2) Vdr 1.7.9 - Debian Lenny Kernel 2.6.31.6 - VDPAU - xine
    3) HW: TT S2-1600, TT-S2-3200

  • 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:



    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

  • 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.

  • Hallo, bei älteren versionen konnte ich mir:

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


    ein extra log anlegen.


    Bei 0.42 passiert bei:

    Code
    1. 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 ?

    HW1: Tyan S2915|2x AMD Opteron 2216 HE|pcie 8400GS|TeVii S470 |LSI 8888ELP|SAS Expander|15x2TB mit mhddfs|32" SONY 32EX705
    HW2: Zotac ION|Tevii S650|Samsung 60GB 2,5"|HDMI an 52" Toshiba
    SW 1-2: Xubuntu 10.4, VDR 1.7.14, xine-vdpau, xbmc

  • Quote

    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.



    Quote

    Originally posted by Chello
    Bei 0.42 passiert bei:

    Code
    1. 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

  • Quote

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


    Gruß,


    Udo


    Das mir VDR nicht mehr startet :)

    HW1: Tyan S2915|2x AMD Opteron 2216 HE|pcie 8400GS|TeVii S470 |LSI 8888ELP|SAS Expander|15x2TB mit mhddfs|32" SONY 32EX705
    HW2: Zotac ION|Tevii S650|Samsung 60GB 2,5"|HDMI an 52" Toshiba
    SW 1-2: Xubuntu 10.4, VDR 1.7.14, xine-vdpau, xbmc

  • Quote

    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.


    Quote


    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.

  • Quote

    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:



    Marcus

    My VDRs:

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



    Gruss
    Marcus

    My VDRs:

  • 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
    1. 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


    Medion Digitainer; AsRock B75 Pro3-M, Celeron G540; Kingston Value 4GB
    Samsung SpinPoint 250GB 2,5"; Samsung WriteMaster DVD-Brenner;
    TT-S2-6400, 2x TT-S2-1600, Ubuntu 12.04 mit YaVDR-Paketen. VDR 1.7.27, UPnP/DLNA-Plugin

    The post was edited 2 times, last by methodus ().

  • 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:


    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

  • 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

    produktiv: intel dh67bl, sat>ip, octopusnet, 16gig boot-ssd, yavdr 0.6.1, cir lirc
    testing: zotac ion-f itx, 1x tt s2-3600 usb, 8gig boot-ssd, yavdr 0.5 testing
    tv: samsung 75" amp:denon avr-x1300


  • 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.

    produktiv: intel dh67bl, sat>ip, octopusnet, 16gig boot-ssd, yavdr 0.6.1, cir lirc
    testing: zotac ion-f itx, 1x tt s2-3600 usb, 8gig boot-ssd, yavdr 0.5 testing
    tv: samsung 75" amp:denon avr-x1300

  • 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.


    Medion Digitainer; AsRock B75 Pro3-M, Celeron G540; Kingston Value 4GB
    Samsung SpinPoint 250GB 2,5"; Samsung WriteMaster DVD-Brenner;
    TT-S2-6400, 2x TT-S2-1600, Ubuntu 12.04 mit YaVDR-Paketen. VDR 1.7.27, UPnP/DLNA-Plugin

  • Quote

    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:


    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

  • 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.