[Problem wieder da] nach YaVDR update: Neustart von vdr 2.2 bei KODI Programmstart

    ist das gleiche wie der gelbe deaktivierungsbubble im webtool, odedr?

    Produktivsystem:
    Server: yaVDR 0.3 0.5 0.6 0.7 im Silverstone Lascala LC16MR; Board: Asus P5N7A-VM S775 GF9300 FSB 1333MHz PCIe Chip: Intel Pentium Dual Core E5200 2.50GHz
    streaming clients: windows-Rechner, Ubuntu-Rechner, 3xRaspberryPI I, 1x RasPi II mit aktuellem Openelec, Kodi + VNSI-PVR auf div. Android-Clients

    Ja, der Effekt sollte der selbe sein.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Dann hats leider nichts geholfen - schmiert immernoch ab.

    Produktivsystem:
    Server: yaVDR 0.3 0.5 0.6 0.7 im Silverstone Lascala LC16MR; Board: Asus P5N7A-VM S775 GF9300 FSB 1333MHz PCIe Chip: Intel Pentium Dual Core E5200 2.50GHz
    streaming clients: windows-Rechner, Ubuntu-Rechner, 3xRaspberryPI I, 1x RasPi II mit aktuellem Openelec, Kodi + VNSI-PVR auf div. Android-Clients

    Zitat

    Kannst du mal einen anderen Skin als das schon länger ungepflegte skinnopacity probieren? IIRC gab es da den ungelösten Fehler im Bugtracker (der mittlerweile nicht mehr erreichbar ist), dass OSD-Meldungen bei detachtem Frontend den VDR zum Absturz bringen können.


    Edit: Ich kann die Crashes beim detachen des Frontends auf einer yaVDR-Installation mit den stable-vdr Paketen mit skinnopacity reproduzieren.


    Wenns nicht am Skin liegt - hast du noch einen alternativen Ansatz für mich?
    Greets
    Ralf

    Produktivsystem:
    Server: yaVDR 0.3 0.5 0.6 0.7 im Silverstone Lascala LC16MR; Board: Asus P5N7A-VM S775 GF9300 FSB 1333MHz PCIe Chip: Intel Pentium Dual Core E5200 2.50GHz
    streaming clients: windows-Rechner, Ubuntu-Rechner, 3xRaspberryPI I, 1x RasPi II mit aktuellem Openelec, Kodi + VNSI-PVR auf div. Android-Clients

    Momentan habe ich da keine Idee - was hast du denn gegenüber der yaVDR-Standardinstallation alles verändert?

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Interessant, heute morgen kann ich die Crashes des VDR auf dem Testrechner auch nachvollziehen, wenn softhddevice über dbus2vdr detached wird (wenn man über svdrp detached, passiert es nicht) ?(


    Und es passiert nur mit dem nvidia-304 Treiber, nicht mit dem nvidia-340 Treiber.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Einmal editiert, zuletzt von seahawk1986 ()

    Kannst du mal ausprobieren, ob ein detachen über SVDRP ohne Crash des VDR funktioniert?

    Code
    svdrpsend plug softhddevice deta


    Dann würde ich im Frontend-Skript eine Option einbauen das über SVDRP statt dbus2vdr zu machen.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    hallo Seahawk
    folgende Punkte:
    - ausser einem angepassten menuorg.xml, ein paar gemountete Festplatten im System und etweas angepasstem Samba-server hab ich nur noch plugins installiert und ein paar internetpages per direktaufruf per menuaufruf (init...) eingerichtet - nichts wildes.


    - nachdem mal bei einem update alles schwarz blieb habe ich den Grafiktreiber für die updates fixiert per

    Zitat

    sudo apt-mark hold nvidia-304
    sudo apt-mark hold nvidia-current


    das deckt sich mit deiner Beobachtung!
    mit dem 340 hatte ich zuletzt nur schwarzen schirm...


    - das von dir vorgeschlagene detachen per "svdrpsend plug softhddevice deta" funktioniert ohne absturz!


    - die funktion "TV-frontend on/off" des wmdrawer führt hingegen auch zum absturtz / neustart


    - wenn ich vdr-sxfe@vdr-plugin-xineliboutput oder xine@vdr-plugin-xine wähle stürtzt er nicht ab bei KODI-Start (hat aber andere Defizite wie lange Umschaltzeiten, Fehler im Menu etc...)


    - Wegen Meldungen als Auslöser vielleicht interessant: OSD messages aus meiner FHEM-Hausautomatisation an die vdr IP:port (192.168.x.y 6419) "echo mesg 'Hello World!'" werden ohne Absturz im vdr und im KODI angezeigt.


    Bin dir immernoch sehr Dankbar für Deine Arbeit an meinen speziellen Fall!
    Gruß
    Tschennings


    Hoffe, das bringt Dich weiter?!

    Produktivsystem:
    Server: yaVDR 0.3 0.5 0.6 0.7 im Silverstone Lascala LC16MR; Board: Asus P5N7A-VM S775 GF9300 FSB 1333MHz PCIe Chip: Intel Pentium Dual Core E5200 2.50GHz
    streaming clients: windows-Rechner, Ubuntu-Rechner, 3xRaspberryPI I, 1x RasPi II mit aktuellem Openelec, Kodi + VNSI-PVR auf div. Android-Clients

    Probier mal bitte folgendes:

    Code
    sudo stop vdr-frontend
sudo wget "https://gist.githubusercontent.com/seahawk1986/451620177e29fae7d5ab9a76d68b7616/raw/cbf95ba380d91f45dcdc355dbe5f60faac0e3def/frontend" -O /usr/bin/frontend


    Dann legst du eine /etc/init/vdr-frontend.override mit diesem Inhalt an:

    Code
    env use_svdrp_for_detach=1
export use_svdrp_for_detach


    Und dann startest du das Frontend-Skript wieder:

    Code
    sudo start vdr-frontend


    Danach sind die Crashes hoffentlich weg.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Hi,
    habs eben noch schnell gemacht -20:15 muss eine Aufnahme laufen, sonst gibts Ärger... Ohne Sytsemneustart hats auf den ersten Blick noch nicht geholfen.Werdes heute Nacht nochmal testen.
    Greets
    tschennings

    Produktivsystem:
    Server: yaVDR 0.3 0.5 0.6 0.7 im Silverstone Lascala LC16MR; Board: Asus P5N7A-VM S775 GF9300 FSB 1333MHz PCIe Chip: Intel Pentium Dual Core E5200 2.50GHz
    streaming clients: windows-Rechner, Ubuntu-Rechner, 3xRaspberryPI I, 1x RasPi II mit aktuellem Openelec, Kodi + VNSI-PVR auf div. Android-Clients

    Hi Seahawk,
    hat leider noch nicht den gewünschten Erfolg gebracht.
    Beim Start von Kodi startet der vdr immernoch neu.
    Wenns dumm läuft sogar irgendwie simultan, so dass bei KODI dr Ton vom vdr durch zu hören ist.
    (Eben hat es ihn sogar mal richtig abgeschmiert, so dass er beim warmstart nicht mal mehr die SSD gefunden hat...)
    Grüße
    tschennings

    Produktivsystem:
    Server: yaVDR 0.3 0.5 0.6 0.7 im Silverstone Lascala LC16MR; Board: Asus P5N7A-VM S775 GF9300 FSB 1333MHz PCIe Chip: Intel Pentium Dual Core E5200 2.50GHz
    streaming clients: windows-Rechner, Ubuntu-Rechner, 3xRaspberryPI I, 1x RasPi II mit aktuellem Openelec, Kodi + VNSI-PVR auf div. Android-Clients

    Zitat von Tschennings

    (Eben hat es ihn sogar mal richtig abgeschmiert, so dass er beim warmstart nicht mal mehr die SSD gefunden hat...)

    Das würde ich ja eher der alten Hardware in die Schuhe schieben...


    Kannst du mal die Zeilen aus der /etc/init/vdr-frontend.override zu den anderen Variablen-Deklarationen in die /etc/init/vdr-frontend.conf (z.B. in die Zeile nach "export start_always_detached") packen und die override-Datei löschen? Nicht dass Upstart die Umgebungsvariable aus irgendeinem Grund ignoriert, wenn die in der override-Datei steckt.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Zeig bitte auch mal das Syslog vom Wechsel vom VDR zu KODI, da müsste man sehen, ob es einen Zugriff über SVDRP gibt oder nicht.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Hallo Seahawk,
    folgendes: Nach dem umkopieren der beiden Zeilen in die vdr-frontend.conf passiert nun folgendes:
    - vdr läuft weiter (!) bei Wechsel zu KODI, kein Absturz
    - KODI startet sehr langsam(gefühlt...)
    und am wichtigsten:
    - der Ton vom vdr ist bei laufendem KODI noch immer zu hören!


    der letzte Punkt ist hinsichtlich der usability an sich der einzige - die Ladezeiten währen zu verschmerzen...
    Grüße
    tschennings

    Produktivsystem:
    Server: yaVDR 0.3 0.5 0.6 0.7 im Silverstone Lascala LC16MR; Board: Asus P5N7A-VM S775 GF9300 FSB 1333MHz PCIe Chip: Intel Pentium Dual Core E5200 2.50GHz
    streaming clients: windows-Rechner, Ubuntu-Rechner, 3xRaspberryPI I, 1x RasPi II mit aktuellem Openelec, Kodi + VNSI-PVR auf div. Android-Clients

    Nachtrag:
    Wenn ich KODI per Maus über den den wmdrawer starte passt alles!?!!


    menuorg.xml
    - <command name="XBMC" execute="/usr/share/vdr/menuorg-appswitcher standalone=yes app=kodi display=1 &amp;> /dev/null " />


    wmdrawer
    - (Kodi) (xbmc_icon.png) (/usr/share/vdr/menuorg-appswitcher standalone=yes app=kodi)



    ...Bitte noch den finalen Tipp, wie ich das Startverhalten aus dem wmdrawer heraus in den Aufruf aus dem Menuorg.xml übertragen kann :]

    Produktivsystem:
    Server: yaVDR 0.3 0.5 0.6 0.7 im Silverstone Lascala LC16MR; Board: Asus P5N7A-VM S775 GF9300 FSB 1333MHz PCIe Chip: Intel Pentium Dual Core E5200 2.50GHz
    streaming clients: windows-Rechner, Ubuntu-Rechner, 3xRaspberryPI I, 1x RasPi II mit aktuellem Openelec, Kodi + VNSI-PVR auf div. Android-Clients

    Einmal editiert, zuletzt von Tschennings ()

    Zeig mal das Syslog im Vergleich und den Backtrace, wenn es crasht.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Hi,
    Syslog verstehe ich - kommt sobald ich am vdr bin. Was versteht man unter "und den Backtrace, wenn es crasht."
    Wie gesagt, crashen tut nichts mehr - nur der Aufruf per menuorg.xml a) dauert ewig und b) der Ton vom vdr läuft weiter, wenn KODI gestartet ist.
    der start per wmdrawer klappt perfekt (schneller start, kein vdr Ton, kein crash).
    Werde heute Abend einmal per wmdrawer, einmal per menuorg.xml KODI starten und das syslog posten.
    Grüße
    tschennings

    Produktivsystem:
    Server: yaVDR 0.3 0.5 0.6 0.7 im Silverstone Lascala LC16MR; Board: Asus P5N7A-VM S775 GF9300 FSB 1333MHz PCIe Chip: Intel Pentium Dual Core E5200 2.50GHz
    streaming clients: windows-Rechner, Ubuntu-Rechner, 3xRaspberryPI I, 1x RasPi II mit aktuellem Openelec, Kodi + VNSI-PVR auf div. Android-Clients

    Zitat von Tschennings

    Wie gesagt, crashen tut nichts mehr - nur der Aufruf per menuorg.xml a) dauert ewig und b) der Ton vom vdr läuft weiter, wenn KODI gestartet ist.

    Vermutlich blockiert SVDRP, wenn der Start von KODI nicht über at entkoppelt wird - probier mal die Änderung in der menuorg.xml rückgängig zu machen, so dass das wieder genutzt wird.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Habs gestern sowohl mit
    display=1 &amp;> /dev/null " />
    also auch mit
    display=1 | at now > /dev/null " />
    probiert - beides mal das selbe problem (langsam, ton geht durch).
    Bin mir gerade nur nicht sicher, ob ich einen Neustart dazwischen gemacht habe...

    Produktivsystem:
    Server: yaVDR 0.3 0.5 0.6 0.7 im Silverstone Lascala LC16MR; Board: Asus P5N7A-VM S775 GF9300 FSB 1333MHz PCIe Chip: Intel Pentium Dual Core E5200 2.50GHz
    streaming clients: windows-Rechner, Ubuntu-Rechner, 3xRaspberryPI I, 1x RasPi II mit aktuellem Openelec, Kodi + VNSI-PVR auf div. Android-Clients

    ein

    Code
    | at now

    anzuhängen genügt nicht, du musst den Befehl an at pipen (das evaluiert den dann später) und daher muss vorne noch ein echo stehen.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden