yavdr 0.6 Bild sporadisch schwarz in Verbindung mit Skindesigner

Ich würde mal versuchsweise die Animations- und Fading-Zeit im Skindesigner auf 0 setzen (da gibt es pro Skin eine Einstellung). IIRC gibt es da ab und an beim Attachen von softhddevice Probleme, wenn das angeschaltet ist.

Welche Skindesigner Version mit welchem Skin benutzt Du?

skindesigner 0.7.2 funktioniert nicht mehr mit den neuen Skins und skindesigner 1.0.0 funktioniert nicht mehr mit den alten Skins.

Zitat von Perlbo

Wenn es wirklich daran liegt, wie sieht den da langfristig die Lösung aus und Animationen wieder anzuschalten. ?

Debug-Pakete (vdr-dgb vdr-plugin-softhddevice-(openglosd)-dbg (je nach genutzter Variante), vdr-plugin-skindesigner-dbg) installieren, Crash provozieren, einen Bugreport für das Problem mit dem dazugehörigen Backtrace für den Crash aufmachen und louis fragen, was man da am besten machen kann... - wenn das bei dir im Backtrace anders aussieht, kannst du das gerne hier dazupacken: https://projects.vdr-developer.org/issues/2382

Hi,

ich schaue mir das bei Gelegenheit mal an...

Perlbo: bei dir crasht es aber ja anscheinend nicht oder?

Ciao Louis

Zitat von louis

Perlbo: bei dir crasht es aber ja anscheinend nicht oder?

Für mich sieht das schon so aus, als ob da der VDR beim Attachen wegbricht - zumindest laut dem Log des vdr-frontend Skriptes ist der VDR da plötzlich nicht mehr verfügbar (das Skript wartet, bis dbus2vdr in der Mainloop des VDR ein Signal absetzt, bevor es softhddevice den Befehl zum Attachen schickt):

dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
(2186, 256) {}
child process ended
restarting process
Traceback (most recent call last):
  File "/usr/bin/frontend", line 587, in <module>
    resume(frontend.status())
  File "/usr/bin/frontend", line 260, in resume
    frontend.attach()
  File "/usr/bin/frontend", line 174, in attach
    dbus.String("ATTA"), display, dbus_interface=self.interface)
  File "/usr/lib/python2.7/dist-packages/dbus/proxies.py", line 145, in __call__
    **keywords)
  File "/usr/lib/python2.7/dist-packages/dbus/connection.py", line 651, in call_blocking
    message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
(2269, 256) {}
child process ended

Wenn man Kodi startet, kommt der VDR nicht in die Verlegenheit, dass das Frontend attached wird.

Perlbo: schau mal, ob du da noch die syslog-Dateien dazu hast, da sieht man Crashes besser als in den Ausgaben des VDR auf seinem stdout/stderr.

Ok, das war in dem Fall aus dem Syslog kein Crash des VDR, sondern ein Problem mit der Video-Ausgabe:

Apr 22 19:22:07 yavdr vdr.conf: vdr is ready
Apr 22 19:22:07 yavdr vdr-frontend[1886]: acip-wakeup.time.old hatte Wert: Fri Apr 22 18:04:00 2016
Apr 22 19:22:07 yavdr vdr-frontend[1886]: vergleiche mit jetzt: Fri Apr 22 17:22:07 2016
Apr 22 19:22:07 yavdr vdr-frontend[1886]: assuming manual start
Apr 22 19:22:07 yavdr vdr-frontend[1886]: watching "MCE IR Keyboard/Mouse (nuvoton-cir)": /dev/input/event3
Apr 22 19:22:07 yavdr vdr-frontend[1886]: started udev monitoring of input devices
Apr 22 19:22:07 yavdr vdr: video: fatal i/o error

Zitat

Ok, das war in dem Fall aus dem Syslog kein Crash des VDR, sondern ein Problem mit der Video-Ausgabe

Hatte auch so ein Problem.Habe dann den Vidia Treiber auf "nvidia-340, 340.96, 3.13.0-85-generic," downgegradet. Seit dem ist Ruhe.

Ich hatte heute ein ähnliches Problem vielleicht ist es auch das gleiche. Normalerweise funktioniert die Ausgabe nach dem Start des VDR PCs sofort, heute kam aber kein Bild selbst nach 4 maligem neustart des Computers.
Laut syslog wurde der VDR komplett gestartet nur das Frontend konnte nicht angesprochen werden.
X-Windows war gestartet den der Mauszeiger war zu sehen.
Im vdr-frontend.log gab es einige Fehler:

root@vdr1:/var/log/upstart# cat vdr-frontend.log
sys:1: Warning: GChildWatchSource: Exit status of a child process was requested but ECHILD was received by waitpid(). Most likely the process is ignoring SIGCHLD, or some other thread is invoking waitpid() with a nonpositive first argument; either behavior can break applications that use g_child_watch_add()/g_spawn_sync() either directly or indirectly.
(2498, 0) {}
child process ended
Error org.freedesktop.DBus.Error.ServiceUnknown: The name de.yavdr.frontend was not provided by any .service files
feh ERROR: Can't open X display. It *is* running, yeah?
Ready <bound method Main.onStart of <__main__.Main object at 0x7fdae94bcc50>>
Stop <bound method Main.onStop of <__main__.Main object at 0x7fdae94bcc50>>
Error org.freedesktop.DBus.Error.ServiceUnknown: The name de.yavdr.frontend was not provided by any .service files
feh ERROR: Can't open X display. It *is* running, yeah?
Ready <bound method Main.onStart of <__main__.Main object at 0x7f8a02e0cc50>>
Stop <bound method Main.onStop of <__main__.Main object at 0x7f8a02e0cc50>>
Ready <bound method Main.onStart of <__main__.Main object at 0x7f1408738c50>>
Stop <bound method Main.onStop of <__main__.Main object at 0x7f1408738c50>>
Error org.freedesktop.DBus.Error.ServiceUnknown: The name de.yavdr.frontend was not provided by any .service files
feh ERROR: Can't open X display. It *is* running, yeah?
Ready <bound method Main.onStart of <__main__.Main object at 0x7fbbaf951c50>>
Stop <bound method Main.onStop of <__main__.Main object at 0x7fbbaf951c50>>

Nachdem ich in /etc/vdr/conf.avail/softhddevice.conf den Parameter "-D" deaktiviert habe funktionierte alles wie gewünscht.

Irgend was passt mit den Anpassungen des Detached Modus, skindesigner und softhddevice-openglosd wohl noch nicht.

Wieso muß der VDR Detached starten? Ich verstehe das er detached sein muß wenn man Kodi verwendet, da Kodi aber nicht mehr als default Frontend nutzbar ist kann doch eigentlich auch der Parameter -D in der softhdevice.conf wegfallen.

Zitat von Frodo

Wieso muß der VDR Detached starten?

Weil der X-Server noch nicht zwingend laufen muss, wenn der VDR gestartet wird - im regulären Betrieb kann das gut gehen, aber die Skripte, die vom WFE ausgelöst werden gehen davon aus, dass der VDR keine Abhängigkeit zum X-Server hat.

Moin,

hm...so ganz weiss ich nicht, wo ich ansetzen soll. Die Crashes von Seahawk sind beide ein bisschen seltsam...in dem einen Crash wird das normale SHD OSD benutzt, dabei crasht es dann. Warum das normale und nicht das High Level OSD benutzt wird ist mir unklar. Die Codestelle dürfte bei Benutzung des High Level OSD gar nicht angesprungen werden. Im anderen crasht es irgendwo bei der VDPAU initialisierung. Auch keine Stelle, an der ich direkt was geändert habe.

Bei Perlbo gab es das Problem ja offensichtlich schon vor dem SHD High Level OSD, nur mit diesem tritt es wohl öfter auf. Es scheint sich ja auch um was anderes zu handeln. Möglicherweise forciert das fading/shiftung der Kanalanzeige das Problem noch, da hier sofort relativ viele Flush() Aufrufe direkt nach dem Start kommen...

Insgesamt...habe ich aktuell keine Ahnung was ich tun könnte Ich hatte solche Probleme noch nie...

Ciao Louis

Die Crashes ohne aktive Animationen (mit aktiven Animationen habe ich es noch nicht ausprobiert) scheinen sich durch eine zusätzliche Wartezeit zwischen dem Start des X-Servers und dem Attachen des softhddevice-Frontends vermeiden zu lassen - man könnte z.B. an der Stelle ansetzen (Einrückung mit Leerzeichen beachten!): https://github.com/yavdr/yavdr…ter/usr/bin/frontend#L585

if ((settings.manualstart or not settings.acpi_wakeup)
            and settings.conf['start_always_detached'] in ('0', '2')):
        time.sleep(5)  # wait 5 seconds after starting vdr-frontend before attaching softhddevice
        resume(frontend.status())

Das könnte möglicherweise ein Timing-Problem bei der Initialisierung der nvidia-Treiber sein, denn zu dem Zeitpunkt haben eigentlich schon sowohl der X-Server als auch openbox ein Signal abgesetzt, dass sie bereit sind.

Alternativ kannst du auch mal versuchen den xorg-launcher (https://github.com/yavdr/yavdr…-launcher.conf/10_main#L2) auf das drm-Device warten zu lassen - das sollte so funktionieren, solange es nur eine Grafikkarte im System gibt:

start on ((filesystem
           and runlevel [!06]
           and started dbus
           and plymouth-ready
           and drm-device-added)
          or runlevel PREVLEVEL=S)