[Solved] Kein Menü mehr (nach update?)

jasminj · 27. Januar 2013

Ich beschäftige mich ja eigentlich mit einem Treiber Problem wg. dem CI Modul.
Dazu habe ich brav alle updates immer gemacht, den neuesten Kernel, diverse Pakete, ... .
Zwischen durch habe ich immer wieder mal den vdr abwürgen müssen ... .

Jetzt wollte ich mal testen, ob ich ein Bild habe und ... . NIX GEHT MEHR
Liegt aber nicht an meinem abgeänderten Treiber weil ich das CI Modul entfernt habe!

Dann mal yavdr-utils mal reinstalled weil ich auch diesen Effekt habe:
http://www.vdr-portal.de/board…oniert-nicht/#post1091652

Somit mal auf xine@vdr-plugin-xine umgestellt, obwohl softhd ursprünglich gut funktioniert hat
Dann kam mal ein "NO Signal" auf meinen Test Monitor.

Jetzt geht aber kein Menu und keine Tasten mehr und es liegt NICHT an den übliche Verdächtigen, weil ich das schon nach der Doku getestet habe:
root@vdrjess:/var/run/lirc# irw lircd.942
0000000000ffa857 01 KEY_MENU CMX_DVD_935
0000000000ffa857 00 KEY_MENU CMX_DVD_935
0000000000ff708f 00 KEY_OK CMX_DVD_935
0000000000ff708f 00 KEY_OK CMX_DVD_935

So toll meine Kiste nach der Erstinstallation funktioniert hat, empfindlich ist das Ding schon.
Irgendwie ist der VDR eine Prima Ballerina, die mit Samthandschuhen angefasst werden will
Kernel Treiber debuggen ist einfacher, als sich durch die verschlungenen Pfade des VDRs durchzuboxen

Anbei noch ein paar Logfiles, weil ich wirklich nicht mehr weiter weiß

LG
Jasmin

seahawk1986 · 27. Januar 2013

Zitat von jasminj

Irgendwie ist der VDR eine Prima Ballerina, die mit Samthandschuhen angefasst werden will

Nicht zu vergessen die ganzen "jungen" Frontends mit ihren Besonderheiten, die alten Plugins mit ohne gute Fehlerbehandlung und dann noch die Distributoren mit ihren Sonderlocken... der VDR selbst kann da am wenigsten dafür.

Code

Jan 27 18:09:43 vdrjess rsyslogd-2177: imuxsock lost 15 messages from pid 1008 due to rate-limiting

Das sieht für mich verdächtig nach einem Crash des VDR beim Starten aus (wie man sieht sieht man nichts). Das Problem tritt sporadisch mit yaVDR 0.5 auf (und bislang konnte das noch niemand richtig eingrenzen). Es scheint ein Timing-Problem beim nachträglichen Attachen des sofhtddevice-Frontends zu sein, eine meist funktionierende Abhilfe ist das Attachen des Frontends um ca. 5 Sekunden zu verzögern (das kann man z.B. mit einem angepassten Template für https://github.com/yavdr/yavdr…d.conf/15_pre-start-start umsetzen, indem man da ein "sleep 5" anhängt)
Ich habe rsyslog bei mir so eingestellt, dass möglichst keine Einträge durch die Logratenbegrenzung verloren gehen: http://paste.ubuntu.com/1256937/

Zitat von jasminj

Jetzt geht aber kein Menu und keine Tasten mehr und es liegt NICHT an den übliche Verdächtigen, weil ich das schon nach der Doku getestet habe:
root@vdrjess:/var/run/lirc# irw lircd.942
0000000000ffa857 01 KEY_MENU CMX_DVD_935
0000000000ffa857 00 KEY_MENU CMX_DVD_935
0000000000ff708f 00 KEY_OK CMX_DVD_935
0000000000ff708f 00 KEY_OK CMX_DVD_935

Was mir in der ps_auxwww_lirc.log auffällt ist, dass lircd2uinput offenbar nicht läuft - falls das nicht von Hand gestoppt wurde könnte evtl. etwas in der /var/log/upstart/lircd2uinput.log zu den Gründen stehen. Das Programm nutzen wir als Brücke, um vom Lirc-Sockel auf ein uinput-Device zu kommen, das dann von eventlircd ausgewertet wird (der die Tastendrücke an den VDR weiterleitet).

Code

Jan 27 18:09:48 vdrjess vdr: [1087] frontend 0/0 timed out while tuning to channel 24, tp 111493
Jan 27 18:09:48 vdrjess ntpdate[1345]: step time server 91.189.94.4 offset -0.650157 sec
Jan 27 18:10:57 vdrjess vdr: [1087] frontend 0/0 timed out while tuning to channel 24, tp 111493
Jan 27 18:12:05 vdrjess vdr: [1087] frontend 0/0 timed out while tuning to channel 24, tp

Das würde ich am ehesten als Empfangs- oder Treiberproblem einstufen - funktionieren die Tuner denn ohne den VDR? Sind alle Kanäle betroffen oder nur bestimmte Frequenzen? Ist da evtl. von den Experimenten mit dem CAM eine nicht funktionierende Umleitung oder defektes Modul übrig geblieben?

jasminj · 27. Januar 2013

Na super, das ging ja schnell!

Zitat von seahawk1986

Es scheint ein Timing-Problem beim nachträglichen Attachen des sofhtddevice-Frontends zu sein ...

Welches ich abgeschalten habe und auf xineliboutput umgestellt.

Zitat von seahawk1986

, eine meist funktionierende Abhilfe ist das Attachen des Frontends um ca. 5 Sekunden zu verzögern ...

Nun das kann ich mal versuchen, wenn die Fernbedienung wieder geht. Ich will ja meinen CI Patch im Kernel testen.

Zitat von seahawk1986

Was mir in der ps_auxwww_lirc.log auffällt ist, dass lircd2uinput offenbar nicht läuft - falls das nicht von Hand gestoppt wurde könnte evtl. etwas in der /var/log/upstart/lircd2uinput.log zu den Gründen stehen.

Die Datei existiert nicht.

Ich verwende einen Attric über die Serielle. Braucht man da auch den lircd2uinput? Laut Zeichnung scheint es benötigt zu werden.
Wo wird das gestartet?
Ich habe leider kein Log von einem funktionierenden Hochlauf, dann könnte ich das vergleichen. Tatsache ist, dass das ganze schon mal perfekt funktioniert hat.

Zitat von seahawk1986
Code
Jan 27 18:09:48 vdrjess vdr: [1087] frontend 0/0 timed out while tuning to channel 24, tp 111493
Jan 27 18:09:48 vdrjess ntpdate[1345]: step time server 91.189.94.4 offset -0.650157 sec
Das würde ich am ehesten als Empfangs- oder Treiberproblem einstufen

Nein, das liegt daran, dass kein SAT Kabel angesteckt war, weil ich zum Treiber testen die Kiste in meinem Arbeitszimmer stehen hatte. War aber, im Bezug auf das Menü und die Funktion der Tasten immer Wurst. Dafür zeigt der VDR ja auch "No Signal".

Wie gesagt, die Sache mit dem sofhtddevice ist mir mal Wurst, weil ich ein Bild über xineliboutput bekomme. Die Bedienung des VDR ist jetzt zum Testen mal im Vordergrund und neu Installieren kann ja nicht die Lösung sein. Ist ja kein Windows, oder doch?

gda · 27. Januar 2013

Zitat von jasminj

Nein, das liegt daran, dass kein SAT Kabel angesteckt war, weil ich zum Treiber testen die Kiste in meinem Arbeitszimmer stehen hatte. War aber, im Bezug auf das Menü und die Funktion der Tasten immer Wurst. Dafür zeigt der VDR ja auch "No Signal".

SHD zeigt nichts wenn es keinen Empfang gibt und die anderen Frontends benutzt bei uns kaum noch jemand.

Gerald

seahawk1986 · 27. Januar 2013

Zitat von jasminj

Ich verwende einen Attric über die Serielle. Braucht man da auch den lircd2uinput?

Ja, irgendwie muss man die Tastendrücke an eventlircd (das will wie der Name schon sagt nur Event-Devices) weiterleiten. Das Problem mit der uinput-Option von Lirc ist, dass es da unkontrollierte Tastenpreller gibt - daher existiert lircd2uinput, das das (zumindest für mich) deutlich besser macht.

Zitat von jasminj

Wo wird das gestartet?

Es gibt einen Upstart-Job dafür, der nach lircd gestartet wird: /etc/init/lircd2uinput.conf

Code

start on started lircd
stop on stopping lircd


respawn


script
while [ ! -e /var/run/lirc/lircd.pid ]; do sleep 1; done
exec /usr/bin/python /usr/bin/lircd2uinput
end script

Alles anzeigen

Nachträglich von Hand kann man ihn so starten:

Code

sudo start lircd2uinput

jasminj · 27. Januar 2013

Zitat von gda

SHD zeigt nichts wenn es keinen Empfang gibt und die anderen Frontends benutzt bei uns kaum noch jemand.

Ja, das weiß ich, aber die Fernbedienung ist trotzdem gegangen.
Ich habe jetzt mal per Browser und "vdr live" auf ORF umgeschalten und hatte ein BILD
Was heißt das mein CI Patch funktioniert, was ich eigentlich testen wollte.

jasminj · 27. Januar 2013

Zitat von seahawk1986

start lircd2uinput

Code

root@vdrjess:/var/log/upstart# start lircd2uinput
start: Unknown job: lircd2uinput

Mein freund grep sagte:

Code

root@vdrjess:/etc/init# grep lircd2uinput *
irserver2uinput.conf:test -f /usr/bin/lircd2uinput || exit 0
irserver2uinput.conf:exec /usr/bin/python /usr/bin/lircd2uinput -s /dev/lircd

Ein "start irserver2uinput" produziert das in

Code

Traceback (most recent call last):
  File "/usr/bin/lircd2uinput", line 233, in <module>
    vlirc = main()
  File "/usr/bin/lircd2uinput", line 155, in __init__
    self.sock.connect(self.socket_path)
  File "/usr/lib/python2.7/socket.py", line 224, in meth
    return getattr(self._sock,name)(*args)
socket.error: [Errno 111] Connection refused
Traceback (most recent call last):
  File "/usr/bin/lircd2uinput", line 233, in <module>
    vlirc = main()
  File "/usr/bin/lircd2uinput", line 155, in __init__
    self.sock.connect(self.socket_path)
  File "/usr/lib/python2.7/socket.py", line 224, in meth
    return getattr(self._sock,name)(*args)
socket.error: [Errno 111] Connection refused

Alles anzeigen

seahawk1986 · 27. Januar 2013

Zitat von jasminj

Ein "start irserver2uinput" produziert das in

Das ist klar, irserver2uinput ist für den irserver gedacht. Da der Mangels entsprechender Hardware (meist in Origen-Gehäusen verbaut) nicht läuft, klappt der Start nicht, weil es keinen entsprechenden Sockel des Daemons unter /dev/lircd gibt.

Das heißt es gibt keine /etc/init/lircd2uinput.conf ? Falls nicht, sollte die sich schnell wieder herstellen lassen (wobei ich nicht weiß, wie die abhanden gekommen sein sollt):

Code

sudo process-template /etc/init/lircd2uinput.conf

jasminj · 27. Januar 2013

Zitat von seahawk1986

Das heißt es gibt keine /etc/init/lircd2uinput.conf ?

Nein, war weg.

Code

sudo process-template /etc/init/lircd2uinput.conf

Hat sie wieder hergestellt ... Gestartet ... FB geht wieder

Auch nach reboot!

! BUSSI BUSSI BUSSI BUSSI !

Zitat von seahawk1986

wobei ich nicht weiß, wie die abhanden gekommen sein sollt

Ich habe den VDR mehrmals beim Treiber testen abgewürgt und dann eben das Problem gehabt.
Aber ich bin Kernel Entwicklerin und die yaVDR Templates sind mir irgendwie zu viel Magie

So jetzt schalte ich mal auf sofhtddevice im WEB Frontend um und schau ob das geht. Wenn nicht, dann muss ich weiter lästig sein

LG
Jasmin

jasminj · 27. Januar 2013

Zitat von jasminj

So jetzt schalte ich mal auf sofhtddevice im WEB Frontend um und schau ob das geht.

Das hat nach einigen Anläufen funktioniert, aber immer einen Speicherfehler im WEB Browser gebracht.
Ich hab dann einfach rebootet und -> Finster
Wieder über WEB umgestellt und dann ging es, auch nach Reboot. Allerdings dauert das alles viel länger als vorher. Irgendwie hat sich was verstellt und macht die Kiste beim Starten/Stoppen langsamer.

Ich habe die LogFiles angehängt, wenn sich ein Wissender da mal Zeit nehmen könnte ev. einen Hint für mich hätte, warum denn das jetzt anders ist.
Z.B., fragt er jetzt beim Abschalten wieder nach, nachdem das Frontend detached wurde. Das war vorher nicht, sondern da hat nur der VDR was gesagt und dann ging es zügig weiter mit dem Abschalten, ohne noch mal zu warten.

EDIT:
Umschalten auf XBMC geht, aber wenn ich zurück schalte, dann dauert es 3 Minuten, bis der VDR wieder da ist ... .
Ach ja, im XBMC geht das Ausschalten per PowerOFF auf der FB nicht mehr. Musste es via Menü machen.

Da ist jetzt so viel im Eck, dass ich gute Lust hätte die Kiste noch mal aufzusetzen, weil dann weiß ich, dass sie wie ein Glockerl spielt.

LG
Jasmin

ATD · 27. Januar 2013

Wie sind Deine Anzeigeeinstellungen in WFE gesetzt, Auflösung, Frequenz Voreinstellung, Deinterlacer-Einstellungen, etc.? Was für eine physische Auflösung hat Dein TV?

PS. es wäre eleganter und einfacher, wenn Du den Syslog wie folgt postest:

Code

sudo apt-get install pastebinit
sudo pastebinit -i /var/log/syslog

Danach den Link hier bekanntgeben.

Albert

jasminj · 27. Januar 2013

Zitat von DaKilla

Wie sind Deine Anzeigeeinstellungen in WFE gesetzt, Auflösung, Frequenz Voreinstellung, Deinterlacer-Einstellungen, etc.?

1920x1080, 50hz Rate,
bob, temporal
Alles Default, außer die Frequenz, die hab ich auf 50 eingestellt.

Zitat von DaKilla

Was für eine physische Auflösung hat Dein TV?

Der Beamer hat 1920x1080

Code

root@vdrjess:/etc/X11#  sudo signal-event rescan-display
X.Org X Server 1.11.3
Release Date: 2011-12-16
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.42-23-generic x86_64 Ubuntu
Current Operating System: Linux vdrjess 3.2.0-36-generic #57-Ubuntu SMP Tue Jan 8 21:44:52 UTC 2013 x86_64
Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.2.0-36-generic root=UUID=e80ad366-4171-4730-8c37-533719fe43a8 ro vmalloc=256m quiet splash vga=792 noresume nohz=off acpi_enforce_resources=lax vt.handoff=7
Build Date: 29 August 2012  12:12:33AM
xorg-server 2:1.11.4-0ubuntu10.8 (For technical support please see http://www.ubuntu.com/support) 
Current version of pixman: 0.24.4
        Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
        (++) from command line, (!!) notice, (II) informational,
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.1.log", Time: Sun Jan 27 22:13:23 2013
(==) Using config file: "/etc/X11/xorg.conf.rescan"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
0:DFP-1:0x00020000:Seiko/Epson EPSON PJ
xinit: connection to X server lost


waiting for X server to shut down  ddxSigGiveUp: Closing log
Server terminated successfully (0). Closing log file.

Alles anzeigen

Zitat von DaKilla

PS. es wäre eleganter und einfacher, wenn Du den Syslog wie folgt postest:

OK, werde ich installieren, aber ich komm erst morgen dazu ... Eine Nacht durchmachen reicht mir ...

Jasmin

seahawk1986 · 27. Januar 2013

Zitat von jasminj

EDIT:
Umschalten auf XBMC geht, aber wenn ich zurück schalte, dann dauert es 3 Minuten, bis der VDR wieder da ist ... .
Ach ja, im XBMC geht das Ausschalten per PowerOFF auf der FB nicht mehr. Musste es via Menü machen.

Die Phasen sind nicht in den Logdateien enthalten. Wegen der Fernbedienung würde ich schauen, ob die Dateien korrekt aus dem Templates erzeugt wurden (irgendwie zeichnet sich da ein Muster ab) - yavdr-utils ist aber schon installiert?
Ansonsten mal ein "sudo process-template" für die Dateien /var/lib/vdr/.xbmc/userdata/Lircmap.xml und /var/lib/vdr/.xbmc/userdata/keymaps/remote.xml laufen lassen.

ATD · 27. Januar 2013

Zitat von jasminj

Alles Default, außer die Frequenz, die hab ich auf 50 eingestellt.

So ist es auch richtig.

Zitat von jasminj

bob, temporal

Die GT210 sollte locker temporal für HD und SD können, vielleicht geht auch temporal_spatial. Das wird aber den Fehler nicht beheben, sollte nur ein Hinweis sein.

Zitat von jasminj

OK, werde ich installieren, aber ich komm erst morgen dazu ... Eine Nacht durchmachen reicht mir ...

OK, ich will schließlich auch den "Kampf der Titanen" auf ORF1 zu Ende gucken. N8!

Albert

jasminj · 27. Januar 2013

Zitat von seahawk1986

Wegen der Fernbedienung würde ich schauen, ob die Dateien korrekt aus dem Templates erzeugt wurden (irgendwie zeichnet sich da ein Muster ab) - yavdr-utils ist aber schon installiert?

Code

dpkg -l | grep yavdr-utils
ii  yavdr-utils                        20130111094302stable-0yavdr0~precise                              Utilities and WEB front end for yaVDR

Es hat ja alles schon perfekt funktioniert. Arbeite ja schon seit 1.1.2013 an der Kiste.

Habe dann heute mal ein
sudo apt-get install --reinstall yavdr-utils
gemacht. Vielleicht war es das oder das vdr abwürgen beim Treiber testen.

Zitat von seahawk1986

Ansonsten mal ein "sudo process-template" für die Dateien ...

So das XBMC Umschalten geht jetzt wieder per PowerOff auf der FB und dann kommt der VDR wieder ganz schnell
Bekommst wieder BUSSI BUSSI BUSSI

Nachdem mein CAM zwischenzeitlich nicht mehr wollte, tut es jetzt wieder, nachdem ich es im alten VDR mal stecken hatte. Auch das CAM Menü geht.
Werde mal rebooten und hoffe es geht noch alles.

EDIT:
Es hat wieder 70 Sekunden gedauert bis ein Bild kam.
Das CAM ging wieder nicht. OK, das ist eine andere Baustelle.

EDIT
Beim nochmaligen Reboot hat es über 2 Minuten gedauert, bis ein Bild kam ...
Hier die syslog (Für Albert schon als pastebinit )

Beim Runter fahren kommt er wieder mit der Meldung "frontend detached, press any key on your remote ... ". Ich bilde mir ein, die war vor der Misere nicht zu sehen. Aber Einbildung ...

seahawk1986 · 27. Januar 2013

Beim Start sieht man einen Crash wegen dem nVidia-Treiber/softhddevice:

Code

Jan 27 22:53:46 vdrjess vdr: video/vdpau: VDPAU API version: 1
Jan 27 22:53:46 vdrjess vdr: video/vdpau: VDPAU information: NVIDIA VDPAU Driver Shared Library  304.51  Tue Sep 18 17:40:30 PDT 2012
Jan 27 22:53:46 vdrjess vdr: video/vdpau: highest supported high quality scaling 1
Jan 27 22:53:46 vdrjess vdr: video/vdpau: feature deinterlace temporal supported
Jan 27 22:53:46 vdrjess vdr: video/vdpau: feature deinterlace temporal spatial supported
Jan 27 22:53:46 vdrjess vdr: video/vdpau: attribute skip chroma deinterlace supported
Jan 27 22:53:46 vdrjess vdr: video/vdpau: 4:2:0 chroma format with 4096x4096 supported
Jan 27 22:53:46 vdrjess vdr: video/vdpau: 4:2:2 chroma format with 4096x4096 supported
Jan 27 22:53:46 vdrjess vdr: video/vdpau: 8bit BGRA format with 8192x8192 supported
Jan 27 22:53:46 vdrjess vdr: video/vdpau: 10bit RGBA format with 8192x8192 supported
Jan 27 22:53:46 vdrjess vdr: video/vdpau: can't create presentation queue: A catch-all error, used when no other error code applies.
Jan 27 22:53:46 vdrjess vdr: audio: 'alsa' output module used
Jan 27 22:53:46 vdrjess vdr: audio/alsa: supports pause: no
Jan 27 22:53:46 vdrjess vdr: audio:  44100Hz supports 1 2 3 4 5 6 7 8 channels
Jan 27 22:53:46 vdrjess vdr: audio:  48000Hz supports 1 2 3 4 5 6 7 8 channels
Jan 27 22:53:46 vdrjess vdr: [1728] dbus2vdr: moving message handler 0x7fa950004650 from active to finished
Jan 27 22:53:46 vdrjess vdr: [1728] dbus2vdr message handler thread ended (pid=1008, tid=1728)
Jan 27 22:53:46 vdrjess vdr: [1222] dbus2vdr: connection has messages to send, flushing
Jan 27 22:53:46 vdrjess vdr: [1222] dbus2vdr: done flushing
Jan 27 22:53:46 vdrjess vdr: [1222] dbus2vdr: new message, object /Remote, interface de.tvdr.vdr.remote, member Enable
Jan 27 22:53:46 vdrjess vdr: [1222] dbus2vdr: 1 idle message handler, reusing 0x7fa950004650
Jan 27 22:53:46 vdrjess vdr: [1731] dbus2vdr message handler thread started (pid=1008, tid=1731)
Jan 27 22:53:46 vdrjess vdr: [1731] dbus2vdr: moving message handler 0x7fa950004650 from active to finished
Jan 27 22:53:46 vdrjess vdr: [1731] dbus2vdr message handler thread ended (pid=1008, tid=1731)
Jan 27 22:53:47 vdrjess vdr: [1222] dbus2vdr: connection has messages to send, flushing
Jan 27 22:53:47 vdrjess vdr: [1222] dbus2vdr: done flushing
Jan 27 22:53:47 vdrjess vdr: [1729] dbus2vdr: deleting message dispatcher for interface de.tvdr.vdr.epg
Jan 27 22:53:47 vdrjess vdr: [1729] dbus2vdr: deleting message dispatcher for interface de.tvdr.vdr.osd
Jan 27 22:53:47 vdrjess vdr: [1729] dbus2vdr: deleting message dispatcher for interface de.tvdr.vdr.plugin
Jan 27 22:53:47 vdrjess vdr: [1729] dbus2vdr: deleting message dispatcher for interface de.tvdr.vdr.recording
Jan 27 22:53:47 vdrjess vdr: [1729] dbus2vdr: deleting message dispatcher for interface de.tvdr.vdr.remote
Jan 27 22:53:47 vdrjess vdr: [1729] dbus2vdr: deleting message dispatcher for interface de.tvdr.vdr.setup
Jan 27 22:53:47 vdrjess vdr: [1729] dbus2vdr: deleting message dispatcher for interface de.tvdr.vdr.shutdown
Jan 27 22:53:47 vdrjess vdr: [1729] dbus2vdr: deleting message dispatcher for interface de.tvdr.vdr.skin
Jan 27 22:53:47 vdrjess vdr: [1729] dbus2vdr: deleting message dispatcher for interface de.tvdr.vdr.timer
Jan 27 22:53:47 vdrjess kernel: [   28.351501] Text2Skin: chan[1729]: segfault at 7fa98736d010 ip 00007fa97d579858 sp 00007fa947c32a50 error 4 in libvdr-text2skin.so.1.7.27[7fa97d532000+63000]
Jan 27 22:53:47 vdrjess kernel: [   28.361522] init: vdr main process (1008) killed by SEGV signal
Jan 27 22:53:47 vdrjess kernel: [   28.364448] init: vdr-frontend main process (1717) killed by TERM signal
Jan 27 22:54:12 vdrjess dbus[963]: [system] Failed to activate service 'de.tvdr.vdr': timed out
Jan 27 22:54:37 vdrjess dbus[963]: [system] Failed to activate service 'de.tvdr.vdr': timed out
Jan 27 22:54:37 vdrjess vdr-crash: vdr exit with signal SEGV . Restarting
Jan 27 22:54:37 vdrjess kernel: [   78.512063] init: vdr-exit-other main process (1900) terminated with status 1

Alles anzeigen

Ist das sleep 5 schon vor dem Start des Frontends eingebaut? Falls nicht würde ich folgendes vorschlagen:

Code

sudo mkdir -p /etc/yavdr/templates_custom/etc/init/vdr-frontend.conf
echo "sleep 5" | sudo tee /etc/yavdr/templates_custom/etc/init/vdr-frontend.conf/16_sleep_5
sudo process-template /etc/init/vdr-frontend.conf

Zitat von jasminj

Beim Runter fahren kommt er wieder mit der Meldung "frontend detached, press any key on your remote ... ". Ich bilde mir ein, die war vor der Misere nicht zu sehen. Aber Einbildung ...

Das kommt 15 Sekunden nach dem Druck auf die Power-Taste. Offenbar hängt der VDR da recht lange herum, bevor er herunterfahren kann.

Warum der VDR beim Beenden so lange braucht, weiß ich nicht.

jasminj · 28. Januar 2013

Zitat von seahawk1986

Ich habe rsyslog bei mir so eingestellt, dass möglichst keine Einträge durch die ....

THX, just configured!

Zitat von seahawk1986

Beim Start sieht man einen Crash wegen dem nVidia-Treiber/softhddevice:

Meinst du das:

Code

Jan 27 22:53:46 vdrjess vdr: video/vdpau: can't create presentation queue: A catch-all error, used when no other error code applies.

oder das

Code

Jan 27 22:53:47 vdrjess kernel: [   28.351501] Text2Skin: chan[1729]: segfault at 7fa98736d010 ip 00007fa97d579858 sp 00007fa947c32a50 error 4 in libvdr-text2skin.so.1.7.27[7fa97d532000+63000]
Jan 27 22:53:47 vdrjess kernel: [   28.361522] init: vdr main process (1008) killed by SEGV signal
Jan 27 22:53:47 vdrjess kernel: [   28.364448] init: vdr-frontend main process (1717) killed by TERM signal
Jan 27 22:54:12 vdrjess dbus[963]: [system] Failed to activate service 'de.tvdr.vdr': timed out
Jan 27 22:54:37 vdrjess dbus[963]: [system] Failed to activate service 'de.tvdr.vdr': timed out
Jan 27 22:54:37 vdrjess vdr-crash: vdr exit with signal SEGV . Restarting
Jan 27 22:54:37 vdrjess kernel: [   78.512063] init: vdr-exit-other main process (1900) terminated with status 1

Wenn das reproduzierbar auftritt, dann sollte man das ja finden können. Allerdings sind vdr-plugins nicht meine Stärke. Besser gesagt unbekannt und ich würde lieber mal meinem CAM zum Laufen verhelfen

Zitat von seahawk1986

Ist das sleep 5 schon vor dem Start des Frontends eingebaut? Falls nicht würde ich folgendes vorschlagen:

Die Anleitung war perfekt! Das dauert nun aber schon einige Zeit, bis der VDR kommt. Hier mal das syslog mit den 5 Sekunden dazu. Vielleicht kannst du kurz noch mal drüber schauen.
Mir ist nur eines aufgefallen, was ein Fehler sein könnte:
ERROR: unknown config parameter: softhddevice.SkipLines = 2
ERROR: unknown config parameter: streamdev-server.SuspendMode = 1

Zitat von seahawk1986

Das kommt 15 Sekunden nach dem Druck auf die Power-Taste. Offenbar hängt der VDR da recht lange herum, bevor er herunterfahren kann.
Warum der VDR beim Beenden so lange braucht, weiß ich nicht.

Wenn du mal schauen könntest was der VDR so tut, hier ein syslog vom runter fahren.

Bei abgestecktem SAT Kabel kommt kein Hinweis daruf. Ich bilde mir ein vor der ganzen dummen Sache ein "No Signal" gesehen zu haben. Wenn das tatsächlich so war, warum ist es jetzt nicht mehr da, sondern ein schwarzer Schirm?

EDIT:
Bezüglich der Zeit. Das könnte vom CAM kommen, weil ich beim debuggen drauf gekommen bin, dass da lange versucht wird mit dem CAM zu kommunizieren, was aber nur sporadisch geht.

seahawk1986 · 28. Januar 2013

Zitat von jasminj

Meinst du das:

Code

Jan 27 22:53:46 vdrjess vdr: video/vdpau: can't create presentation queue: A catch-all error, used when no other error code applies.

Wenn ich das damals richtig verstanden habe, ist das der Auslöser für das Beenden des VDR. Der Segfault von text2skin ist wohl eine Folge davon.

Zitat von jasminj

Wenn das reproduzierbar auftritt, dann sollte man das ja finden können. Allerdings sind vdr-plugins nicht meine Stärke. Besser gesagt unbekannt und ich würde lieber mal meinem CAM zum Laufen verhelfen

Das Problem ist, dass es sporadisch auftritt, bei den Betroffenen meist bei < 20% der Starts. Ich habe das Problem zum Glück nicht.
johns hat vermutet, dass der X-Server noch nicht voll initialisiert ist (wobei das ungünstig wäre, denn Openbox sollte ja eigentlich seinen erfolgreichen Start melden, indem es ein Upstart-Signal absetzt: https://github.com/yavdr/yavdr…/openbox.conf/10_main#L22 - darauf hin werden noch ein paar Dinge erledigt: https://github.com/yavdr/yavdr…penbox-tools.conf/10_main und sobald das durchgelaufen ist, wird das Frontend gestartet)

Zitat von jasminj

Mir ist nur eines aufgefallen, was ein Fehler sein könnte:
ERROR: unknown config parameter: softhddevice.SkipLines = 2
ERROR: unknown config parameter: streamdev-server.SuspendMode = 1

Das sind nur überschüssige Zeilen in der setup.conf des VDR. Wenn du willst, kannst du sie bei gestopptem VDR löschen, aber den VDR im Betrieb stören sollten sie nicht.

Zitat von jasminj

Wenn du mal schauen könntest was der VDR so tut, hier ein syslog vom runter fahren.
Bezüglich der Zeit. Das könnte vom CAM kommen, weil ich beim debuggen drauf gekommen bin, dass da lange versucht wird mit dem CAM zu kommunizieren, was aber nur sporadisch geht.

Das kann natürlich sein, solche Effekte kenne ich sonst nur von schwächelnden USB-Sticks, die den VDR ausbremsen, weil sie mit den I/O Operationen nicht nachkommen.

[Solved] Kein Menü mehr (nach update?)

Jetzt mitmachen!

Teilen

Benutzer online in diesem Thema