[ANNOUNCE] runvdr extreme

  • Hi,


    Ich habe gerade die erste Version meines runvdr extreme Package veröffentlicht.


    runvdr extreme ist ein runvdr-Skript, genau wie das runvdr-Skript aus der VDR-Distribution. Es bietet jedoch Konfigurationsdateien, umfangreiche Kommandozeilenoptionen, und viele zusätzliche Features.


    -> http://www.udo-richter.de/vdr/scripts.html#runvdr-extreme


    - Lädt die Grundkonfiguration aus runvdr.conf
    - Die gesamte Konfiguration kann per Kommandozeile gesetzt werden
    - Alle VDR-Optionen werden unterstützt
    - Verwaltet runvdr.pid Datei, reagiert auf Signale
    - Startet VDR im Falle von Fehlern neu
    - Kommandos, um VDR neu zu starten und DVB-Treiber neu zu laden
    - Beim VDR-Neustart wird die Konfiguration erneut gelesen
    - Vermeidet endlose Schleifen, wenn VDR sofort stirbt
    - Setzt Terminal zurück nachdem VDR beendet wurde
    - Starten von Wrapper-Programmen zum Debuggen
    - Wartet bis der VDR-Prozess beendet wurde,
    hartes Beenden nach Timeout
    - Kommandozeilenhilfe
    - Kann Konsole umschalten
    - Kann Landessprache für VDR setzen
    - Unterstützt Pluginsetup-Plugin (optional)



    Wer sich noch mit dem original runvdr-Skript durchschlägt, ist, für den ist diese aufgebohrte Version vielleicht interessant. Alternativ kann man sich natürlich auch ein paar coole Tricks aus dem Skript klauen und in die eigene runvdr einbauen.


    Gruß,


    Udo

  • Hi Udo!


    Alter Schwede, das sieht umfangreich aus! Werde mir das Skript mal ansehen und versuchen das in das Zenslack einzubinden, von dem wir gesprochen haben! Solche Features fehlen da nämlich!


    Also Danke für deine Arbeit!!! :respekt



    Gruß


    Toxic

    Registrierter VDR-User #1275


    VDR-Server: Proxmox 7.1 - LXC Container - Debian 11.5 - eTobi-VDR 2.6.0

    DVB-Hardware: Digital Devices - Cine S2 V5.5 und V6

    VDR-Clients: FireTV Sticks 2 bis 4K Max und Kodi 19.4

  • Geniale Sache das.
    Nur irgendwas mache ich wohl total falsch.
    Ich bekomme das nicht zum laufen:


    : command not foundf: line 9:
    : command not foundf: line 13:
    : command not foundf: line 16:
    : command not foundf: line 21:
    : command not foundf: line 25:
    : command not foundf: line 28:
    : command not foundf: line 32:
    : command not foundf: line 33:
    : command not foundf: line 37:
    : command not foundf: line 61:
    : command not foundf: line 64:
    : command not foundf: line 68:
    : command not foundf: line 74:
    : command not foundf: line 79:
    : command not foundf: line 88:
    : command not foundf: line 92:
    : command not foundf: line 98:
    : command not foundf: line 102:
    : command not foundf: line 107:
    : command not foundf: line 111:
    : command not foundf: line 115:
    : command not foundf: line 121:
    : command not foundf: line 125:
    : command not foundf: line 128:
    : command not foundf: line 132:
    : command not foundf: line 136:
    : command not foundf: line 139:
    : command not foundf: line 142:
    : command not foundf: line 146:
    : command not foundf: line 150:
    : command not foundf: line 153:
    : command not foundf: line 159:
    : command not founddr: line 580:
    Starting VDR at Mi Okt 11 18:11:32 CEST 2006
    "-w 90 "/videop 2001a
    : command not founddr: line 604:
    VDR died within 10 seconds, this happened 1 time(s).
    Restarting VDR and DVB by error level 127 at Mi Okt 11 18:11:32 CEST 2006
    ";)syntax error: operand expected (error token is "/runvdr: line 454: ((: i<


    ";)syntax error: operand expected (error token is "/runvdr: line 465: ((: i<
    failed.




    Ich hab die .conf schon soweit abgespeckt, daß nur die benötigten Daten wirklich drin sind.
    aber immer dasselbe. Ich fahre SuSE 10.1 mit selbstkompiliertem Kernel 2.6.17.13 und VDR 1.4.3-1


    Ich oute mich jetzt mal also totaler script-Anfänger, aber:
    Was mir auffällt ist, daß wenn ich das script mit kwrite anschaue, daß der Bereich ab
    "function AddDevice()" komplett in rot ist.
    kwrite markiert ja scripts farblich so daß man die einzelnen Funktionen schön unterscheiden kann, aber ab dieser Zeile 198 ist es wohl gestört. Sobald ich vorher ein " einsetze ist das behoben.
    Kannst Du das bitte nochmal überprüfen, oder mache ich generell etwas falsch ???


    Die 'command not foundf:' bringt er wohl für jede leere Zeile in der runvdr.conf.

  • Ich hab etwas gegrübelt, bis ich verstanden hatte, was die Fehlermeldung besagt...


    : command not foundf: line 9:


    ... bedeutet eigentlich:
    /......./runvdr.conf: line 9: ^M: command not found


    und:
    : command not founddr: line 580:


    ... bedeutet eigentlich:
    /usr/local/bin/runvdr: line 580: ^M: command not found


    Dabei ist ^M der Zeilenrücklauf (CR), weshalb der Anfang der Fehlermeldung wieder überschrieben wird. Fazit: Du hast die runvdr.conf in einem Windows-Texteditor bearbeitet, und dabei ist die Datei ins DOS-CRLF-Format konvertiert worden, und deine Shell interpretiert jetzt jedes CR am Zeilenende als reguläres Zeichen, bzw. sonst irgendwie als verwertbaren Text.


    Zitat

    Was mir auffällt ist, daß wenn ich das script mit kwrite anschaue, daß der Bereich ab "function AddDevice()" komplett in rot ist.


    Das hat nichts zu sagen, da wird nur das Shell-Quoting so kompliziert, dass kein simpler Texteditor mehr mit kommt. So lange die bash es aber noch versteht, sollte das ok sein. ;)


    Gruß,


    Udo

  • Wenn man VFAT=1 setzt klappt Dein Skript nicht. Der Patch fixt das.


  • Hi,


    Klasse Script, habe ein - zwei für mein EIS/Fair Packet augeschaut.
    Nur stört mich etwas, dass das Script nur dann auf Signale reagiert, wenn der VDR schon nicht mehr läuft.


    deswegen hab ich die Zeilen

    Code
    wait $PID
    RET=$?


    durch folgendes ersetzt



    jetzt reagiert das Script auch auf Signale wärend der VDR noch läuft.


    Vielleicht kanns ja noch jemand außer mir gebrauchen,
    in das neue EIS/Fair VDR PAcket kommt es jedenfalls so rein.


    Gruß Maverick-ME

  • Sorry, irgendwie verstehe ich das nicht.


    Zunächst mal, VDR wird vom Skript mit & im Hintergrund gestartet. Unmittelbar danach legt sich runvdr im Vordergrund mit wait schlafen. Damit reagiert runvdr durchaus auf Signale, während vdr läuft.


    Außerdem verstehe ich deinen Code nicht: Wenn der VDR-Prozess existiert (was er anfangs fast sicher tut), schläft deine Schleife auch mit wait, und wird dann beendet.
    Wenn der VDR-Prozess nicht existiert (zb. wegen sofortiger Beendigung), wartest du noch auf ein Signal, bevor das runvdr-Skript weiter läuft. Dadurch wird aber ein Neustartversuch auch unterbunden.


    Also: Stehe ich auf der Leitung, oder du? ;)


    Gruß,


    Udo

  • Hi,


    Zitat

    Zunächst mal, VDR wird vom Skript mit & im Hintergrund gestartet. Unmittelbar danach legt sich runvdr im Vordergrund mit wait schlafen. Damit reagiert runvdr durchaus auf Signale, während vdr läuft.

    Bei mir reagiert das Script erst auf die Signale wenn der VDR Prozess beendet wurde.


    Zitat

    Wenn der VDR-Prozess existiert (was er anfangs fast sicher tut), schläft deine Schleife auch mit wait, und wird dann beendet.


    Nein die Scheife schläft nicht mit wait, sondern mit sleep und in der Schleife wird geprüft, ob der VDR Prozess noch läuft, wenn nicht wird mit wait der
    Returncode vom VDR geholt. Und ausserdem wird in der Schleife noch gechekt, ob dem Script ein Signal gesendet wurde.


    Zitat

    Wenn der VDR-Prozess nicht existiert (zb. wegen sofortiger Beendigung), wartest du noch auf ein Signal, bevor das runvdr-Skript weiter läuft. Dadurch wird aber ein Neustartversuch auch unterbunden.

    Nein, da wird mit "if [ $(ps -p $PID | wc -l) -lt 2 ]" überprüft ob der VDR noch läuft.


    Also, nochmal der Grund für die Zeilen: VDR wird vom Script in den Hintergrund geschickt, aber bei mir ist es so, dass
    ab der Zeile "wait $PID" das Script auf keine Signale reagiert, solange der VDR Prozess nicht beendet ist.

  • Aus dem bash-manual:


    Zitat

    3.7.6 Signals
    [...]
    When Bash receives a signal for which a trap has been set while waiting for a command to complete, the trap will not be executed until the command completes. When Bash is waiting for an asynchronous command via the wait builtin, the reception of a signal for which a trap has been set will cause the wait builtin to return immediately with an exit status greater than 128, immediately after which the trap is executed.


    Bei mir funktioniert es jedenfalls. Meine bash ist dabei auch altes Eisen: 2.05b.0(1)-release (Debian Sarge).


    Hier ein Kompakt-Test:


    #>{ trap "echo SIGTERM" SIGTERM ; sleep 10 & wait $! ; echo "wait: $?" ; } &
    [7] 3829
    [1]+ Done sleep 10
    wait: 0


    #>{ trap "echo SIGTERM" SIGTERM ; sleep 10 & wait $! ; echo "wait: $?" ; } &
    [8] 3834
    #>kill 3834
    SIGTERM
    wait: 143


    #>


    Beim ersten Start passiert 10s lang nichts, dann liefert wait 0 zurück. Beim zweiten Start wird das Kommando mittels SIGTERM abgebrochen, und wait kehrt frühzeitig zurück.


    Gruß,


    Udo

  • Hi,


    zu den Tests:
    die funktionieren wie ich hier schon getestet hatte,
    Test 1 läuft 10 sec.
    Test 2 läuft 10 sec. kann aber durch kill beendet werden.


    trotzdem hab ich hier das Problem, dass es in einem Script nicht funktioniert.


    z.B. ich starte auf einer Konsole das Script


    nun gehe ich auf eine andere Konsole und gebe "kill" und die jeweilige SCRIPTPID ein und das
    Script läuft trotzdem weiter und wird erst beendet, wenn wait "fertig ist". Die Variable SIG enthält
    zwar das entsprechende Signal, aber das hat ja erst Effekt, wenn wie schon gesagt, wait beendet ist.

  • Seltsame sache, hab keine Ahnung, warum das bei dir nicht läuft. Entweder hat deine bash noch einen Bug, den meine nicht hat, oder irgend etwas an der Konfiguration ist anders und hat hier eine Auswirkung. Wobei ich nicht wüsste, was das sein kann. Fehlende Job Control Fähigkeiten oder so.


    Gruß,


    Udo

  • Hab mich ja auch gewundert, aber ne andere Lösung als die while Schleife von Oben, hab ich nicht gefunden.


    Naja so funktionierts jedenfalls hier.


    P.S.: Es ist funktioniert nciht nur nicht am meinem VDR sondern auch an anderen EIS/Fair Rechnern mit denen ich es probiert hab.


    Danke nochmal!


    Gruß Maverick-ME

  • Hmmm, mal überlegen. Die 0.1.0 war die erste jemals veröffentlichte Version. Die beiden Patches sind Antworten auf den Release-Post von 0.1.0. Seit 0.1.0 sind auch keine neuen Versionen erschienen. Ob die Patches wohl schon mit drin sind? ;)


    Gruß,


    Udo

  • Zitat

    Ob die Patches wohl schon mit drin sind? Augenzwinkern


    Nein sind sie noch nicht.


    Tolle Arbeit deine runvdr :respekt


    Ich habe auch noch folgendes am Anfang eingefügt:

    Code
    export LANG=de_DE.iso8859-1
    export LC_CTYPE=de_DE.iso8859-1



    Viele Grüße


    Vielleicht veröffentlichst Du mal eine neue Version?

    MSI K9 Neo V3 | Athlon X2 6000+ | 4GB DDR2 Ram | TT Budget S2-3200 | TT DVB-S Budget S1102 (like Nova) | 400 GB Samsung HD401LJ | DVD-Laufwerk
    Ubuntu 9.10 | VDR 1.7.10 | Nvidia 195.30 | xbmc mit pvr


    ---driver140771---

  • Hi,


    Zitat

    Ein weiterer Patch behebt das Problem der verlorenen "-" Dateien.


    wenn ich diesen Patch einspiele, läuft das Skript unter kanotix nicht mehr:


    Code
    root@Kanotix:/usr/local/src/VDR# ./runvdr &
    [1] 2328
    root@Kanotix:/usr/local/src/VDR# /bin/which: line 41: printf: write error: Ungültiger Dateideskriptor


    unter Suse 10 allerdings schon.


    Wenn es was bringt, hier mal das which von kanotix:



    Zitat

    Vielleicht veröffentlichst Du mal eine neue Version?


    find ich auch ;)


    Tschüss,


    winni

  • Zitat

    Originally posted by winni
    wenn ich diesen Patch einspiele, läuft das Skript unter kanotix nicht mehr:


    Code
    root@Kanotix:/usr/local/src/VDR# ./runvdr &
    [1] 2328
    root@Kanotix:/usr/local/src/VDR# /bin/which: line 41: printf: write error: Ungültiger Dateideskriptor


    Da mag wer nicht, dass ich die Dateideskriptoren schließe. Ersetz mal ab Zeile 71 in runvdr alle >&- durch das 'traditionelle' >/dev/null.


    Zitat

    find ich auch ;)


    jaja... aber ich bin gerade an einem Plugin, das mindestens genauso interessant sein dürfte...


    Zitat

    Originally posted by driver140771
    Ich habe auch noch folgendes am Anfang eingefügt:

    Code
    export LANG=de_DE.iso8859-1
    export LC_CTYPE=de_DE.iso8859-1


    Zumindest LANG kann man über die Option LANGUAGE bzw. über --language setzen. Hat es darüber hinaus einen Vorteil, auch LC_CTYPE zu setzen? Ist bei mir auf keinem System gesetzt.


    Gruß,


    Udo

  • Zitat

    Da mag wer nicht, dass ich die Dateideskriptoren schließe. Ersetz mal ab Zeile 71 in runvdr alle >&- durch das 'traditionelle' >/dev/null.


    so mag es nun auch kanotix, Danke!


    noch was anderes, was aber nichts mit Deiner runvdr zu tun haben muss: Ich hab seit meiner Umstellung von Suse auf Kanotix das Problem, dass sich VDR plötzlich ohne jeden Grund beendet:


    Code
    Nov 16 23:38:01 Kanotix vdr: [2492] record /video0/Spielfilme/Egoshooter_(Drama)/2006-11-16.23.
    38.40.99.rec
    Nov 16 23:47:36 Kanotix vdr: [2497] channel 22 (HR) event Don 16.11.2006 23:00-23:45 'Late Lounge: Club' status 1
    Nov 16 23:47:37 Kanotix vdr: [2497] channel 22 (HR) event Don 16.11.2006 23:45-00:15 'Harald Schmidt' status 2
    Nov 16 23:48:01 Kanotix vdr: [2497] channel 22 (HR) event Don 16.11.2006 23:45-00:15 'Harald Schmidt' status 4
    Nov 16 23:54:26 Kanotix vdr: [2492] caught signal 15
    Nov 16 23:54:26 Kanotix vdr: [2492] stopping plugin: osdteletext
    Nov 16 23:54:26 Kanotix vdr: [2492] stopping plugin: premiereepg


    auch die runvdr beendet sich dann. Der Rechner selbst läuft dann unendlich weiter. Ich hab schon alle Logs durchforstet, aber finde nirgends einen Sender von signal 15. Die runvdr-extreme war bei mir bei kanotix von Anfang an im Einsatz, aber wie gesagt, muss nicht daran liegen. Mit einer "normalen" runvdr hab ich es noch nicht getestet. Mir ist nur eines aufgefallen: Das Problem taucht scheinbar nur dann auf, wenn ich vdr per "runvdr &" direkt aus einer shell per ssh starte. Beim Start per inittab trat es bisher nie auf. Im Fehlerfall läuft vdr meist ein paar Stunden und dann passiert es einfach. Irgendeine Idee?


    Tschüss,


    winni

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!