Momentan nehmen wir an das Xorg weit genug ist, wenn sich der WM (openbox) fertig initialisiert hat.
[yaVDR64-0.5.0-alpha1]vdr wird sporadisch beim starten gekillt
-
-
Dann sollte es klappen. Entweder ist die nicht zuverlässig oder der XServer wird mehrmals gestartet.
CodeJul 26 20:26:17 vdrwz vdr: [1163] dbus2vdr: emit upstart-signal vdr-plugin for started Jul 26 20:26:17 vdrwz vdr: video: fatal i/o error Jul 26 20:26:17 vdrwz polkitd[1288]: started daemon version 0.104 using authority implementation `local' version `0.104' Jul 26 20:26:17 vdrwz dbus[947]: [system] Successfully activated service 'org.freedesktop.PolicyKit1' Jul 26 20:26:17 vdrwz dbus[947]: [system] Successfully activated service 'org.freedesktop.ConsoleKit' Jul 26 20:26:17 vdrwz kernel: [ 20.072019] HDMI: detected monitor LG TV Jul 26 20:26:17 vdrwz kernel: [ 20.072023] at connection type HDMI
Oder X11 startet ohne Monitor: der Monitor wird erst nach dem Pluginstart erkannt.
Habt Ihr edid.bin ausgelesen und gespeichert?Johns
-
Hi,
denke mal schon, die /etc/X11/edid.0.yavdr ist da und der VDR wurde mit diesem Fernseher als Monitor installiert.
Laut wiki wird diese auch upgedatet:
ZitatFür Nutzer ab yaVDR Version 0.3: Im yaVDR-Web-Frontend muss die Display-Konfiguration vorgenommen und abgespeichert werden. Darauf hin wird automatisch die EDID
des Displays oder Surround-Receivers ausgelesen und eine Datei namens
edid.0.yavdr unter /etc/X11/ abgelegt, die nur zum angeschlossenen
Fernseher/Receiver-Modell passt. Dies muss nur einmal gemacht werden,
solange sich das angeschlossene Fernseher-Modell nicht ändert. -
und hummel99,
gibt es irgendwelche neuigkeiten?
ich muss gestehen, ich habe das text2skin vorübergehend deaktiviert, da ich aktuell nur wenig zeit habe irgendwas zu testen....gruß
Boo -
Hi, naja mit einem Delay von 5 Sekunden läuft es absolut problemlos, lieber wäre mir jedoch auf eine Meldung / Abfrage des VDR nach dessen Start zu warten.
Das soll ja momentan schon so sein, aber ich kapier nicht wo das abgefragt wird.Zitatdbus2vdr meldet das der vdr fertig ist, nachdem alle Plugins fertig
geladen und initialisiert sind. Also im Prinzip passiert exakt das was
du möchtest bereits. -
Das soll ja momentan schon so sein, aber ich kapier nicht wo das abgefragt wird.
Es wird an Upstart gemeldet und du kannst Upstart Jobs definieren die darauf triggern (Also es kann nicht wirklich in diesem Sinne "abgefragt" werden.)
Also um z.B. was zu machen wenn softhddevice bereit ist (d.h. der VDR hat das erste mal den MainThreadHook aufgerufen (d.h. der VDR ist fertig gestartet)) dann brauchst du so was als Jobbedingung:
---
start on started vdr-plugin softhddevice=started
---Wobei, so wie ich das verstehe muss man hier zwangsweise ein Plugin anfragen, eine allgemeine "VDR ist fertig gestartet" Bedingung scheint es nicht zu geben.
cu
-
Und das geht obwol es keinen Job gibt der vdr-plugin heisst ?
root@vdrmd:~# status vdr-plugin
status: Unknown job: vdr-plugin -
Und das geht obwol es keinen Job gibt der vdr-plugin heisst ?
root@vdrmd:~# status vdr-plugin
status: Unknown job: vdr-pluginNein, du musst dir /irgendeinen/ Job erstellen der so anfängt...
---
start on started vdr-plugin softhddevice=started
---dbus2vdr startet ja keine Jobs, es teilt Upstart nur Infos mit die für start/stop Bedingungen von Jobs genutzt werden können.
cu
-
Man muss außerdem beachten, dass das Upstart-Signal, das dbus2vdr da absetzt nur für den User vdr gilt - d.h. man braucht einen Job in /var/lib/vdr/.init/ der das Signal dann ans übrige System weiterleitet - z.B. eine softhddevice-ready.conf: http://paste.ubuntu.com/1124224/ - dann muss innerhalb der vdr-frontend.conf auf das Signal plugins-ready gewartet werden.
Leider hat das ganze damals bei mir nichts gebracht, denn die Abstürze kommen wohl zu einem guten Teil von wechselnden Problemen bei der Variableninitialisierung in verschiedenen Plugins...
-
Hallo zusammen,
also verstehe ich das richtig,
das SHD klemmt sich ab, weil X11 noch nicht soweit ist, richtig?ZitatHi, naja mit einem Delay von 5 Sekunden läuft es absolut problemlos, lieber wäre mir jedoch auf eine Meldung / Abfrage des VDR nach dessen Start zu warten.
Das soll ja momentan schon so sein, aber ich kapier nicht wo das abgefragt wird.
du versetzt also den vdr mit einem delay von 5 Sek, dann ist X11 da, und der vdr wird ohne Probleme gestartet?
und das ganze tritt nur auf, wenn text2skin aktiv ist? -
Hallo,
ob das Problem an SHD oder svdrp liegt kann ich nicht genau sgaen, zumindest macht SHD kein ATTA.
Den Delay habe ich nicht im VDR sondern im Frontend und damit läufts problemlos, und es passiert nur mit text2skin aktiviert, wobei das wohl nichts direkt mit dem Plugin zu tun hat sondern eher mit der Startzeit des VDR's wenn es aktiviert ist. -
Moin..
ok, vielen dank für die rückmeldung.
//edit: kann ich bestätigen klappt bei mir auch mit einem 5 sek. delay beim frontend start... -
also nur nochmal eine kleine Rückmeldung..
das Problem besteht weiterhin..
habs letzens wieder gemerkt als ich ein Update eingespielt hab und er mir die vdr-frontend.conf (da wo das delay definiert ist) weggehauen hat..
Ich hab die jetzt getemplated und schon startet der vdr wieder sauber..
was kann ich noch tun..?
wobei sich mir wieder einmal die frage stellt, ob hummel und ich die einzigen mit dem Problem sind..
und ob wir die einzigen sind die ein delay definiert haben.. -
Moin!
Tja, ist nicht leicht. Es gibt ja immer mal Kombinationen/Installationen, die sich irgendwie anders verhalten.
Wenn es kein globales Problem ist (d.h. dutzende Leute betrifft oder gar einem aus dem Team), und es eine Lösung für euch gibt, mit der ihr leben könnt, dann sehe ich das als ausreichende Lösung an.
Ob der Delay es allerdings in die Distribution schafft, kann ich nicht versprechen. Das würde er erst, wenn es im Team das gleiche Problem und keine andere Lösung gibt.Lars.
-
Hi,
ihr seid nicht allein, ich habe das Problem auch (aktueller yavdr stable, vdr 2.03, softhddevice, graphlcd 0.3.0+git20131012-touchcol-0yavdr1~precise).
Stand der Tests bei mir:
- Diese segfauls treten nur in Verbindung mit glcd_display auf. Ohne glcd_display läuft meine Konfig sehr stabil, auch durch viele reboots.
- segfault tritt nur auf bei reboot, nicht bei "restart vdr" (Mit ~ 70 Durchläufen getestet)
Edit:
- segfault tritt bei reboot auch mit "sleep 5", "sleep 10", "sleep 30" wie in Post 186 beschrieben eingebaut auf. Statistisch bereits beim 2. reboot.Anbei ein einfaches, universelles Script, mit dem man den VDR-PC dauernd von remote rebooten kann.
Edit: Damit mache ich gerade Ausdauertests. Script neue Version abgehängt.ZitatSo sah das bisher aus, Abstürze beim rebooten:
grep segfault /var/log/syslog
Nov 25 23:07:04 media-sack2 kernel: [ 9229.236860] glcd_display[16293]: segfault at 500000064 ip 00007f270b123321 sp 00007f26d6ffca48 error 4 in libc-2.15.so[7f270afc0000+1b5000]
Nov 25 23:38:01 media-sack2 kernel: [11081.456734] softhddev video[20885]: segfault at 7fcc7176b0d4 ip 00007fcc7176b0d4 sp 00007fcbe64c5ea0 error 14 in ISO8859-9.so[7fcc72253000+2000]
Nov 25 23:40:25 media-sack2 kernel: [ 27.679200] glcd_display[2142]: segfault at 500000064 ip 00007f44ca6ac321 sp 00007f44957f9a48 error 4 in libc-2.15.so[7f44ca549000+1b5000]
Nov 25 23:56:35 media-sack2 kernel: [ 132.870472] glcd_display[3136]: segfault at 500000064 ip 00007fcbc9a4d321 sp 00007fcb9d7f9a48 error 4 in libc-2.15.so[7fcbc98ea000+1b5000]
Nov 26 00:05:32 media-sack2 kernel: [ 668.464547] glcd_display[6174]: segfault at 500000064 ip 00007f57a8dec321 sp 00007f5784ff8a48 error 4 in libc-2.15.so[7f57a8c89000+1b5000]
Nov 26 00:13:12 media-sack2 kernel: [ 28.045674] glcd_display[2071]: segfault at 500000064 ip 00007f592003a321 sp 00007f58e37fda48 error 4 in libc-2.15.so[7f591fed7000+1b5000]
Nov 26 12:34:29 media-sack2 kernel: [ 1611.658281] glcd_display[6949]: segfault at 500000064 ip 00007fbe85a70321 sp 00007fbe59ffaa48 error 4 in libc-2.15.so[7fbe8590d000+1b5000]
Nov 26 12:45:56 media-sack2 kernel: [ 2296.730612] glcd_display[8809]: segfault at 500000064 ip 00007f02f230b321 sp 00007f02be7fba48 error 4 in libc-2.15.so[7f02f21a8000+1b5000]
Nov 26 12:46:29 media-sack2 kernel: [ 2329.395681] glcd_display[9193]: segfault at 500000064 ip 00007fc514fd3321 sp 00007fc4f0ff8a48 error 4 in libc-2.15.so[7fc514e70000+1b5000]
Nov 26 13:02:02 media-sack2 kernel: [ 3259.620212] glcd_display[15797]: segfault at 500000064 ip 00007fbd81158321 sp 00007fbd5cff8a48 error 4 in libc-2.15.so[7fbd80ff5000+1b5000]
Nov 26 14:40:43 media-sack2 kernel: [ 9165.728197] vdr-dbg[1943]: segfault at fffffffffffffff8 ip 00007f659c7af818 sp 00007fff64f65b90 error 5 in libstdc++.so.6.0.16[7f659c711000+e2000]
Nov 26 14:40:54 media-sack2 kernel: [ 9176.405142] vdr-dbg[2304]: segfault at fffffffffffffff8 ip 00007fdd4dabf818 sp 00007fff8c8901d0 error 5 in libstdc++.so.6.0.16[7fdd4da21000+e2000]
Nov 26 22:32:36 media-sack2 kernel: [ 28.545570] glcd_display[2048]: segfault at 500000064 ip 00007f1d7bdce321 sp 00007f1d3effca48 error 4 in libc-2.15.so[7f1d7bc6b000+1b5000]
Nov 27 00:14:26 media-sack2 kernel: [ 27.398317] glcd_display[2053]: segfault at 500000064 ip 00007f1fdc252321 sp 00007f1f9f7fda48 error 4 in libc-2.15.so[7f1fdc0ef000+1b5000]Grüße
Ralf -
Hi,
anbei meine Testergebnisse mit imho interessanten Erkenntnissen.
Die DVB Karte ist eine TBS-6985 Quad Tuner Karte. Über udev-Regeln werden derzeit nur 2 der 4 Tuner aktiviert.Jede Zeile ist ein Testlauf bzw. eine Konfigurationsänderung.
ZitatReboot Test: mit dynamite, mit graphlcd, mit "sleep 5" - "sleep 30" (2 von 4 Tunern aktiv): Anzahl Zyklen bis zum Fehler:
5 cycles done
1 cycles done
2 cycles done
1 cycles doneReboot Test: ohne dynamite, ohne graphlcd, ohne "sleep": 43 cycles, dann Test beendet
Reboot Test: mit dynamite, ohne graphlcd, ohne "sleep" (2 von 4 Tunern aktiv): hängt nach 18x, booten im bios / vor grub. Keine vdr-hänger.
Reboot Test: mit dynamite, ohne graphlcd, ohne "sleep" (2 von 4 Tunern aktiv): hängt nach 3x, booten im bios / vor grub. Keine vdr-hänger.
Reboot Test: mit dynamite, ohne graphlcd, ohne "sleep" (2 von 4 Tunern aktiv): hängt nach 65x booten im bios / vor grub. Keine vdr-hänger.
Change: Bios update durchgeführt
Reboot Test: mit dynamite, ohne graphlcd (2 von 4 Tunern aktiv): 6 cycles, dann Test manuell beendet
Reboot Test: mit dynamite, ohne graphlcd (2 von 4 Tunern aktiv): hängt nach 6x booten im bios / vor grub. Keine vdr-hänger.
Change: grup delay 1 eingestellt, damit man erkennt wo's hängt, bios oder grub -> Später Erkenntnis: Hängt beim Bios, nicht bei grup / Kernel laden.
Reboot Test: mit dynamite, ohne graphlcd, ohne "sleep" (2 von 4 Tunern aktiv): 16 cycles, dann Test manuell beendet
Reboot Test: mit dynamite, mit *graphlcd (als letztes laden), order.conf:1, ohne "sleep" (2 von 4 Tunern aktiv): 1 cycles done, vdr hängt!
Nov 27 19:10:29 media-sack2 kernel: [ 30.697444] glcd_display[2091]: segfault at 500000064 ip 00007f0549131321 sp 00007f05067fba48 error 4 in libc-2.15.so[7f0548fce000+1b5000]
Reboot Test: mit dynamite, mit *graphlcd (als letztes laden), order.conf:1, ohne "sleep" (2 von 4 Tunern aktiv): 2 cycles done, vdr hängt!
Nov 27 19:28:25 media-sack2 kernel: [ 30.239318] glcd_display[2066]: segfault at 500000064 ip 00007fe9c727d321 sp 00007fe990ff8a48 error 4 in libc-2.15.so[7fe9c711a000+1b5000]
2x manuell rebootet, vdr hängt immer!
Nov 27 19:35:15 media-sack2 kernel: [ 30.511537] glcd_display[2062]: segfault at 500000064 ip 00007f0d2bfcc321 sp 00007f0ced7f9a48 error 4 in libc-2.15.so[7f0d2be69000+1b5000]
Nov 27 19:45:32 media-sack2 kernel: [ 86.556855] softhddev video[2394]: segfault at 7f9e618880d4 ip 00007f9e618880d4 sp 00007f9dcb7fdea0 error 14 in libusb-0.1.so.4.4.4[7f9e62370000+6000]
Reboot Test: mit dynamite, mit graphlcd (VOR softhddevice laden), ohne "sleep" (2 von 4 Tunern aktiv): 8 cycles done, dann Test manuell beendet
Reboot Test: mit dynamite, mit *graphlcd (als letztes laden), order.conf:1, ohne "sleep" (2 von 4 Tunern aktiv): 0 cycles done
manuell restarted, 0 cycles done
Reboot Test: mit dynamite, mit graphlcd (NACH softhddevice laden), ohne "sleep" (2 von 4 Tunern aktiv): 2x 0 cycles done
Nov 27 20:40:00 media-sack2 kernel: [ 23.142529] glcd_display[1915]: segfault at 500000064 ip 00007fd10d77e321 sp 00007fd0e3ffea48 error 4 in libc-2.15.so[7fd10d61b000+1b5000]
Nov 27 20:55:34 media-sack2 kernel: [ 22.695216] glcd_display[1876]: segfault at 500000064 ip 00007f4286c30321 sp 00007f4269914a48 error 4 in libc-2.15.so[7f4286acd000+1b5000]
Reboot Test: mit dynamite, mit graphlcd (VOR softhddevice laden), ohne "sleep" (2 von 4 Tunern aktiv): 7 cycles done, dann hänger im bios
Reboot Test: mit dynamite, mit graphlcd (VOR softhddevice laden), ohne "sleep" (2 von 4 Tunern aktiv): 6 cycles done, dann hänger im bios
Rechner ausgeschaltet
Reboot Test: mit dynamite, mit graphlcd (VOR softhddevice laden), ohne "sleep" (2 von 4 Tunern aktiv):70 cycles done, dann Test manuell beendetMeine Schlussfolgerungen:
1. Die Hardware (DVB?) wird nicht vollständig initialisiert. Das könnte besser werden, wenn alle 4 Tuner aktiviert sind. (Sollte eigentlich nichts ausmachen...) -> ToDo Test.
2. Ein "sleep x" in vdr-frontend.conf ist bei diesem System keine Lösung.
3. Über order.conf muss graphlcd VOR softhddevice geladen werden.Grüße
Ralf -
Hi,
anbei die Testergebnisse für 4 aktive Tuner:
ZitatChange: Alle 4 Tuner aktiviert
Reboot Test: mit dynamite, mit graphlcd (VOR softhddevice laden), ohne "sleep" (4 von 4 Tunern aktiv): 3x: Startet, aber "Frontend detached"
Change: Wieder 2 Tuner aktiviert
Reboot Test: mit dynamite, mit graphlcd (VOR softhddevice laden), ohne "sleep" (4 von 4 Tunern aktiv): 1x: Startet, aber "Frontend detached"
2x: Startet, mit Frontend
Change: Alle 4 Tuner aktiviert 1x rebootWiederholung des Tests aus dem vorigen Post, bei dem hänger im Bios auftraten, aber mit 4 Tunern aktiv:
Reboot Test: mit dynamite, mit graphlcd (VOR softhddevice laden), ohne "sleep" (4 von 4 Tunern aktiv): 10 cycles done, dann Test manuell beendet
Reboot Test: mit dynamite, mit graphlcd (NACH softhddevice laden), ohne "sleep" (4 von 4 Tunern aktiv): 0 cycles done
Nov 28 00:58:55 media-sack2 kernel: [ 21.734702] glcd_display[1895]: segfault at 500000064 ip 00007fd9e37b1321 sp 00007fd9c6591a48 error 4 in libc-2.15.so[7fd9e364e000+1b5000]
Reboot Test: mit dynamite, mit graphlcd (NACH softhddevice laden), ohne "sleep" (4 von 4 Tunern aktiv): 12 cycles done, dann Test manuell beendetMeine Schlussfolgerungen:
4. Die hänger im Bios liegen daran, dass nicht alle Tuner aktiviert waren.Edit:
Ich erachte die Konfig jetzt z.Z. als stabil:Reboot Test: mit dynamite, mit graphlcd (NACH softhddevice laden), ohne "sleep" (4 von 4 Tunern aktiv): 32 cycles done, dann Test manuell beendet
Reboot Test: mit dynamite, mit graphlcd (NACH softhddevice laden), ohne "sleep" (4 von 4 Tunern aktiv): 83 cycles done, dann Test manuell beendetGrüße
Ralf -
Waren zufällig Timer aktiv? Dann startet das vdr-frontend nicht und man sieht das Bild mit dem Text "frontend detached...".
Lars.
-
Waren zufällig Timer aktiv? Dann startet das vdr-frontend nicht und man sieht das Bild mit dem Text "frontend detached...".
Lars.
Hi Lars,
nee, sind noch keine Timer im System.
Grüße
Ralf
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!