als ich den sleep 5 mit rein genommen habe, war das Ergebnis so 50-50. mal gings mal gabs das Problem.
Dann hab ichs 1x mit sleep 10 probiert, und hatte gleichdas Problem, da habe ich dann die und-verküpfte startup Variante von Seahawk probiert.
Bei mind. 4 Versuchen hat es immer funktioniert bei mir (Syslog).
Sieht für mich im Moment gut aus, allerdings bin ich nicht so tief drin in Euren Upstart Jobs.
Gruß
Marc
hab nur noch das zum 2. Syslog (der Fehlerhafte boot) Link
das ist jetzt aber von dem Boot der funktionierte? Denn das Display hat er erkannt. Sieht also nicht aus als wenn der Reciver aus war.
[ 12.778] (**) NVIDIA(0): ConnectedMonitor string: "DFP-1"
[ 14.373] (II) NVIDIA(GPU-0): Display (NAD T747 (DFP-1)) does not support NVIDIA 3D Vision
[ 14.376] (--) NVIDIA(0): Connected display device(s) on GeForce GT 520 at PCI:1:0:0
[ 14.376] (--) NVIDIA(0): NAD T747 (DFP-1)
[ 14.376] (--) NVIDIA(0): NAD T747 (DFP-1): 165.0 MHz maximum pixel clock
[ 14.376] (--) NVIDIA(0): NAD T747 (DFP-1): Internal Single Link TMDS
[ 14.376] (II) NVIDIA(0): Option "UseDisplayDevice" "DFP-1" converted to "DFP-1".
[ 14.376] (**) NVIDIA(0): Using HorizSync/VertRefresh ranges from the EDID for display
[ 14.376] (**) NVIDIA(0): device NAD T747 (DFP-1) (Using EDID frequencies has been
[ 14.376] (**) NVIDIA(0): enabled on all display devices.)
[ 14.391] (II) NVIDIA(0): Assigned Display Device: DFP-1
[ 14.391] (II) NVIDIA(0): Validated modes:
[ 14.391] (II) NVIDIA(0): "1920x1080_50"
[ 14.391] (II) NVIDIA(0): Virtual screen size determined to be 1920 x 1080
Hast du noch ein zweites vom gegenteiligen Zustand?
Vielleicht erhellt das unser Problem.
was mir noch aufgefallen an deinem Logfile wo es nicht geht:
das ist nicht komplett - man sieht nicht wie er vdr startet, somit für die Analyse etwas doof. Kannst das bitte auch nochmal komplett posten
Ist das inzwischen geklärt ?
Ich hatte auch zweimal nach apt-get dist-upgrade einen schwarzen Bildschirm.
Kann ich was helfen dabei ? Braucht ihr noch Infos ?
Grüße Bernd
Anstatt eines sleeps in das upstart? Script, könnte man dort eine Schleife mit 1s Sleep einbauen.
Dann startet das Frontend so schnell wie möglich, klappt aber auch wenn das Script schon läuft und VDR noch nicht fertig ist.
Zur Not kann man auch noch abfragen "svdrpsend plug softhddevice status" ob das Frontend auch läuft.
Johns
Zur Not kann man auch noch abfragen "svdrpsend plug softhddevice status" ob das Frontend auch läuft.
Wir versuchen solche loops zu vermeiden wie die Pest. Deshalb haben wir auch schon im dbus2vdr-Plugin eingebaut, dass eine DBUS-Meldung abgegeben wird, wenn alle Plugins initialisiert sind. Das scheint wohl leider nicht zu reichen.
Gerald
in softhddevice einen patch für dbus ? gda würde sowas helfen ?
in softhddevice einen patch für dbus ? gda würde sowas helfen ?
Denkbar wäre das schon. Wenn Johns uns sicher signalisiert, dass sein Plugin soweit ist, dann sollte das helfen. Vielleicht sagt mini73 noch was dazu.
Gerald
Hallo,
hatte gerade auch mal wieder das Problem dass nur der Mauszeiger zu sehen ist.
Es hängt wohl mit dbus2vdr zusammen, wenn ich ein:
vdr-dbus-send /Plugins/softhddevice plugin.SVDRPCommand string:"ATTA" string:"-d :1`dbget vdr.tempdisplay`"
absetze bekomme ich den Fehler:
Error org.freedesktop.DBus.Error.TimedOut: Activation of de.tvdr.vdr timed out
im Syslog:
Error 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
Wenn ich ein:
svdrpsend plug softhddevice ATTA -d :1`dbget vdr.tempdisplay`
absetze, kommt das Bild.
Habe jetzt mal zwei meiner VDR's mit dieser vdr-frontend.conf getemplated:
cat /etc/yavdr/templates_custom/etc/init/vdr-frontend.conf/30_softhddevice
<?cs if:(vdr.frontend == "softhddevice") ?>
svdrpsend plug softhddevice ATTA -d :1`dbget vdr.tempdisplay` ||: &> /dev/null
end script
post-stop script
svdrpsend plug softhddevice DETA ||: &> /dev/null
end script
<?cs /if ?>
<?cs /if ?>Bis jetzt hatte ich immer Bild nach dem Start.
Was ist eigentlich der Vorteil den ATTA bzw. DETA über vdr-dbus-send zu erledigen ?
svdrpsend war für uns mit mehreren parallelen Zugriffen prinzipbedingt zunehmend unzuverlässig. dbus ist für die lokale Benutzung besser geeignet und kann neben SVDRP Ersatz auch noch 1-2 Sachen mehr (setzen von setup Werten des VDR und einigen Plugins, absetzen eines upstart events wenn mit --upstart gestartet usw). Versuch hier mal die aktuelle Version des dbus2vdr Plugins (siehe 100% Last Thread) Ich könnte mir vorstellen das die Änderung hier auch hilft.
Hast du das log von /var/log/upstart/vdr-frontend.log ? War es komplett schwarz oder yavdr-logo ? Mauszeiger zu sehen ? Wie sieht deine /etc/init/sound-device.conf aus ?
Hallo zusammen,
also mir ist aufgefallen, das bei mir das softhddevice-plugin des öftern für einen absturz des vdr verantwortlich ist,
das erkenne ich daran, das dann im entsprechenden bt irgendwas von softhddevice steht,
wenns hilft kann ich den hier bei gelegenheit mal anhängen...
ich hab jetzt den theat nicht ganz gelesen, aber vllt hilft das ja...
außerdem habe ich mich um abstürze wegen des softhddeveces auch noch nicht intensiv gekümmert, da ich mich jetzt erstmal aufs text2skin konzentrieren wollte,
aber bei mir tritt das auch auf...
hier isser:
(gdb) bt
#0 0x00007f9aa8228445 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f9aa822bbab in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2 0x00007f9aa822110e in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#3 0x00007f9aa82211b2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
#4 0x00007f9aa248a683 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#5 0x00007f9aa248a6a1 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#6 0x00007f9aa248adfd in _XEventsQueued () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#7 0x00007f9aa247c49d in XPending () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#8 0x00007f9a9e987629 in VideoPollEvent () from /usr/lib/vdr/plugins/libvdr-softhddevice.so.1.7.27
#9 0x00007f9a9e988357 in ?? () from /usr/lib/vdr/plugins/libvdr-softhddevice.so.1.7.27
#10 0x00007f9aa9abfe9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#11 0x00007f9aa82e44bd in clone () from /lib/x86_64-linux-gnu/libc.so.6
#12 0x0000000000000000 in ?? ()Ja, dann... du weist ja jetzt wie das mit den Debugsymbolen geht 
johns ist mit seinen Plugin ja ziemlich aktiv. Bei nem bt mit Debugsymbolen und der Angabe der verwendeten Pluginversion stehen die Chancen gut das er was damit anfangen kann *).
cu
*) So ein Fehler wie bei text2skin wo niemand ne Idee hat was der Grund sein könnte ist eher selten.
Fresh install yavdr 05.alpha1.
softhddevice geht ootb, auch hinter DDRECEIVER.
apt-get update //upgrade.... schon ist es schwarz
ii vdr-plugin-softhddevice 0.6.0.git20120523.0717-0yavdr0~preciseNach langem suchen und Probieren tippe ich hier auch auf ein Timingproblem bei upstart und failsafe sowie der spaete connect der Netzwerkkarte.
Die Netzwerkkarte schein mit der noapic Kerneloption besser zu gehen.
( Besser meint, MediaSensing lauft schneller ab )
Hinzu kommt das der avahi-daemon langer benötigt, da er vollkommen uebereifrig alles mountet,
was in meinem netz NFS und mDNS spricht.
mount.nfs: /media/Bilder/yavdr5 is busy or already mounted
mount.nfs: /srv/vdr/video.00/yavdr5 is busy or already mounted
Traceback (most recent call last):
File "/usr/bin/avahi-mounter", line 399, in <module>
avahiMounter()
File "/usr/lib/python2.7/contextlib.py", line 154, in __exit__
self.thing.close()
File "/usr/bin/avahi-mounter", line 58, in close
mount.unuse()
File "/usr/bin/avahi-mounter", line 235, in unuse
os.rmdir(self.local)
OSError: [Errno 16] Device or resource busy: '/media/Sonstige/ix2-200/'Seitdem ich ein paar NFS Dienste auf meinen NAS System gestoppt habe, VDR sich seine recordings sauber aktualisiert hat ( liegen z.T. auf NFS ) geht es jetzt !
Kann aber noch nicht so wirklich eingrenzen, warum, sonder nur vermuten.
Wie das mit dem AVAHI so kommt im anderen thread:
hi,
ZitatJa, dann... du weist ja jetzt wie das mit den Debugsymbolen geht
leider nein, das text2skin mit debug symbolen wurde mir freundlicher weise gestellt
aber ich kann jetz pakete bauen, evtl. schaue ich mir das heute abend mal an..
wobei ich mich nach wie vor erstmal auf das text2skin-problem konzentrieren möchte.
Ich hatte in einer der softhddevice Versionen das Problem, daß das ATTA gesendet wurde als die Variablen im softhddevice (interne Variable ob detached ist) noch nicht gesetzt war. Da das auch stark Timingabhängig war - kann es sein das das Problem evtl nicht gelöst ist, sondern sich bei mir nur das Timing geändert hat. Deswegen bin ich scharf auf das /var/log/upstart/vdr-frontend.log, dieses müsste es zeigen. Wenn IHR von schwarzem Bildschirm redet nehme ich an es ist der nackte X-Screen gemeint - sprich svdrpsend plug softhddevice STAT zeigt das es detached ist ? Es gibt auch noch ein laufendes Problem bei der Sounderkennung welches ein starten des upstart jobs sound-device verhindert, auf welchen vdr-frontend wartet.
Ich würde mich freuen wenn wir nicht alles durcheinanderwerfen würden - und sehen könnten:
Welche schwarzen Bidschirme kommen von der Sounderkennung ?
Welche haben hier ein potentielles Timingproblem ?
Crashes des Softhddevice konnte ich hier noch nicht beobachten - die würde ich dann auch gerne seperat diskutieren wollen. Wenn das mit dem Debugsymbolpaket für text2skin geklappt hat, können wir hier ja nach Anforderung andere nachschieben ?
BooStar: das automatische generieren des crashlogs hatte funktioniert ? Oder erstellst du den bt "manuell" ?
Moin!
Falls ich heute abend dazu komme, werde ich softhddevice noch mit Debug-Symbolen versehen.
Wäre ja schön, wenn das so nach und nach in alle Plugins einzieht, deshalb erst mal auf Anforderung. 
Lars.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!