[gelöst] Konfigurationsfehler, nur wo?

  • Hallo


    ich bin gerade dabei meinen vdr-client om wohnzimmer gegen eine leisere Version auszutauschen. Ich habe die Konfiguration soweit möglich/sinnvoll kopiert, aber beim neuen habe ich nach dem booten nur einen blinkenden Maus-cursor auf dem TV. Gebe ich dann per ssh “start xbmc“ ein, funktioniert xbmc. Gebe ich dann “stop xbmc“ ein, habe ich auch das vdr-frontend-bild. Wo könnte das hängen, dass er direkt zum vdr-frontend durchbooted? Bin ratlos?


    Danke und Gruß

    Server: Hardware: Intel DH77KC, Celeron G1610, 8GB RAM, 2x 5TB HDD, 2x WD 1,9TB HDD; 1x 64 GB SSD (root), System Ubuntu 18.4 / YaVDR ansible headless
    Client: Hardware: Lenovo Q150 (nur Netzwerk, 1GB RAM, ohne DVB-Karte, Igor-USB-Empfänger) System: Ubuntu 18.4 / YaVDR ansible

    2 Mal editiert, zuletzt von Negge ()

  • Was genau, d.h. welche Dateien hast du denn übernommen?
    Im Zweifelsfall im WFE einmal auf was anderes stellen und dann wieder zurück.


    Ansonsten natürlich Meldungen aus dem syslog usw. inspizieren...


    Lars

  • Hi,


    also das Syslog ist unauffällig. Scheinbar wird weder das "vdr-Frontend" noch "xbmc" beim hochfahren gestartet (ergo kein Fehler, aber auch keine Startmeldung wie beim anderen System). Die Konfiguration ist etwas speziell, weil der/die Client nicht auf den lokalen vdr/xineliboutput zugreifen, sondern auf remote auf das xineliboutput des vdr-Servers (yavdr-headless). Die modifizierten configs aus /etc/yavdr/templates custom/ wurden entsprechen vom alten client auf den neuen übernommen (ebenso wie das server-wake-script). Fernbedienung fehlt noch in Details (andere Empfänger-Hardware), aber ein Problem nach dem anderen...


    WIe gesagt, eigentlich funktioniert dasmit den Konfig's ja auch. "start xbmc" und dann "stop xbmc" => frontent wird gestartet und funktioniert. Also kann da an diesen Konfig-Dateien eigentlich kein Fehler sein. ABER: Beim booten sollte er ja eigentlich automatisch xbmc oder das vdr-frontend mitstarten. Im WFE hab ich auch mehrmals die Ausgabe-Einstellungen geändert. Funktioiert leider nicht. Irgenwo verschluck er sich also, dass er ein frontend beim boot-Process startet. Nur wo und warum?!? :wand

    Server: Hardware: Intel DH77KC, Celeron G1610, 8GB RAM, 2x 5TB HDD, 2x WD 1,9TB HDD; 1x 64 GB SSD (root), System Ubuntu 18.4 / YaVDR ansible headless
    Client: Hardware: Lenovo Q150 (nur Netzwerk, 1GB RAM, ohne DVB-Karte, Igor-USB-Empfänger) System: Ubuntu 18.4 / YaVDR ansible

  • Zeig doch mal die Upstart-Dateien, die mit deinen Templates erstellt werden.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • ~# initctl list (direkt nach dem boot)


    Code
    cat /etc/init/vdr-frontend.conf################################################################################## ##   The following configuration file is generated automatically by the yaVDR    ##     system. Don't change this file as every update of yaVDR will overwrite    ##         the local changes. Instead put your required customizations           ##       into /etc/yavdr/templates_custom/ based on the original templates       ##                      under /usr/share/yavdr/templates.                        ##                                                                               ##            http://www.yavdr.org/developer-zone/template-overview/ ##                                                                               ##                                                                               ################################################################################### yavdr-frontend - Starts vdr frontend#description     "yavdr-frontend"author          "Steffen Barszus <steffenbpunkt@gmail.com>"env HOME=/var/lib/vdrexport HOMErespawnstart on started vdr or stopped openbox-tools or started sound-device \         or vdr-frontend-restartstop on stopping vdr or stopping openboxpre-start script# wait for vdr, Xorg (after wm is running) and the sound devices to be loadedstart wait-for-job-state WAIT_FOR=vdr TARGET_GOAL=start WAIT_STATE=running WAITER=vdr-frontend WAIT_FOREVER=1 ||:start wait-for-job-state WAIT_FOR=sound-device TARGET_GOAL=start WAIT_STATE=running WAITER=vdr-frontend WAIT_FOREVER=1 ||:start wait-for-job-state WAIT_FOR=openbox-tools TARGET_GOAL=stop WAIT_STATE=waiting WAITER=vdr-frontend WAIT_FOREVER=1 ||:# dont start if some other application is runningif [ -e /tmp/.standalone ]; then   vdr-dbus-send /Remote remote.Disable ||:   exit 1fiend scriptnice -10#setuid vdr#setgid vdr#env XINE_BUFFER_LOG=1env USE_AUTOCROP=0export USE_AUTOCROPscriptexport DISPLAY=:1`dbget vdr.tempdisplay`export __GL_SYNC_TO_VBLANK=1export __GL_SYNC_DISPLAY_DEVICE=`/usr/bin/dbget system.x11.display.0.device`HUDOPTS=""XINELIBOUTPUTOPTS="--post tvtime:method=use_vo_driver --buffers=300 --lirc=/var/run/lirc/lircd-lirc0 --reconnect --audio=alsa --syslog --silent --tcp "CONFIG="--config /etc/vdr-sxfe/config_xineliboutput"exec sudo -u vdr /usr/bin/vdr-sxfe $HUDOPTS $XINELIBOUTPUTOPTS $CONFIG xvdr://192.168.1.30:37890end script

    Server: Hardware: Intel DH77KC, Celeron G1610, 8GB RAM, 2x 5TB HDD, 2x WD 1,9TB HDD; 1x 64 GB SSD (root), System Ubuntu 18.4 / YaVDR ansible headless
    Client: Hardware: Lenovo Q150 (nur Netzwerk, 1GB RAM, ohne DVB-Karte, Igor-USB-Empfänger) System: Ubuntu 18.4 / YaVDR ansible

    2 Mal editiert, zuletzt von Negge ()

  • Code
    start on started vdr or stopped openbox-tools or started sound-device \
            or vdr-frontend-restart

    Wenn du keinen lokalen VDR hast, ist die Start-Bedingung nie erfüllt.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Hi,


    an den anderen hab ich nur bei lirc etwas per "template_custom" geändert. Sonst alles original yavdr. Und dieselben templates laufen auch dem anderen Client ja auch problemlos? "initcl list" zeigt in (siehe oben Zeile 9, vdr-frontend stop/pre-start, process 1094), das das vdr-frontend nach dem booten offenbar nicht gestartet wurde?!?


    Der Hinweis vom mini73 ist aber gut. An dem alten Client hatte ich das damals zuerst mit dem lokalen VDR getestet, der lief also/kann prinzipiell laufen (auch wenn der nix zu tun hat). Bei dem neuen Client hab ich den VDR auf dem Client nie eingerichtet.
    Der VDR scheint ja auch auf dem neuen Client nach "initcl list" nicht zu laufen (oder wird der per rc-script gestartet, heute abend mal checken). Ich muss ja zugeben, dass ich den Upstart-Krams bisher noch nicht ganz durchblickt hatte/habe.
    Im Prinzip kann ja in meinem Fall in meinem cutom-template das "start on started vdr" raus, oder? Und viel wichtiger die Bedingung "wait-for-job-state WAIT_FOR=vdr TARGET_GOAL=start WAIT_STATE=running WAITER=vdr-frontend WAIT_FOREVER=1" sollte auch raus, oder? (heute abend mal testen).
    Verständnisfrage: die Bedingung "start on stopped openbox-tools" started das fronted nachdem "stop xbmc" (falls xbmc läuft)? Weil XBMC im Fenstermanger openbox läuft?

    Server: Hardware: Intel DH77KC, Celeron G1610, 8GB RAM, 2x 5TB HDD, 2x WD 1,9TB HDD; 1x 64 GB SSD (root), System Ubuntu 18.4 / YaVDR ansible headless
    Client: Hardware: Lenovo Q150 (nur Netzwerk, 1GB RAM, ohne DVB-Karte, Igor-USB-Empfänger) System: Ubuntu 18.4 / YaVDR ansible

  • Der Hinweis vom mini73 ist aber gut. An dem alten Client hatte ich das damals zuerst mit dem lokalen VDR getestet, der lief also/kann prinzipiell laufen (auch wenn der nix zu tun hat). Bei dem neuen Client hab ich den VDR auf dem Client nie eingerichtet.
    Der VDR scheint ja auch auf dem neuen Client nach "initcl list" nicht zu laufen (oder wird der per rc-script gestartet, heute abend mal checken). [...]

    Da hab ich die falsche Stelle zum zitieren erwischt, problematisch ist das hier, wenn der Upstart-Job für den VDR nicht "running" ist, wird das Frontend nie gestartet:

    Code
    # wait for vdr, Xorg (after wm is running) and the sound devices to be loaded
    start wait-for-job-state WAIT_FOR=vdr TARGET_GOAL=start WAIT_STATE=running WAITER=vdr-frontend WAIT_FOREVER=1 ||:

    Ich würde die Zeile einfach mal auskommentieren. Die Start-Bedingung kann dann so aussehen (du kannst sie aber auch lassen wie sie ist, durch das or ist das "started vdr" einfach eine Bedingung, die nie eintritt):

    Code
    start on stopped openbox-tools or started sound-device \
             or vdr-frontend-restart
    stop on stopping vdr or stopping openbox

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Hi,


    danke für die Hilfe. Genau das war es. "vdr" lief auf dem neuen Client nicht und damit war die pre-start-Bedingung nie erfüllt. Danke für die Hilfe. :tup


    Ich hätte da auch basierend meiem Problem hier ggf. noch eine Anregung für das WFE. Man kann ja im WFE bei "cutsom configuration" durchaus den vdr aus "disabled" setzen, und trotzdem ein frontend auf enabled setzen . Eventuell könnte man da dann ja noch einbauen, dass er dann die pre-start-Bedingung "WAIT_FOR=vdr" automatisch deaktiviert (wobei man die Dateien/templates ja sowiesow per Hand anpassen muss, da man dem frontend ja sagen muss zu welchem remote-vdr er sich verbinden muss). Nur so als Anregung (Code-Vorschlag siehe unten, soweit ich die Syntax verstanden hab. Die else-Bedingung kann man natürlich auch ganz weglassen...).


    Code
    .../vdr-frontend.conf/15_pre-start-start
    
    
    <?cs if:(vdr.backend != "disabled") ?>
    start wait-for-job-state WAIT_FOR=vdr TARGET_GOAL=start WAIT_STATE=running WAITER=vdr-frontend WAIT_FOREVER=1 ||:
    <?cs else ?>
    # start wait-for-job-state WAIT_FOR=vdr TARGET_GOAL=start WAIT_STATE=running WAITER=vdr-frontend WAIT_FOREVER=1 ||:
    <?cs /if ?>


    Danke für die gute Arbeit. :tup

    Server: Hardware: Intel DH77KC, Celeron G1610, 8GB RAM, 2x 5TB HDD, 2x WD 1,9TB HDD; 1x 64 GB SSD (root), System Ubuntu 18.4 / YaVDR ansible headless
    Client: Hardware: Lenovo Q150 (nur Netzwerk, 1GB RAM, ohne DVB-Karte, Igor-USB-Empfänger) System: Ubuntu 18.4 / YaVDR ansible

    2 Mal editiert, zuletzt von Negge ()

Jetzt mitmachen!

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