absturz vdr durch plugin text2skin

Zitat

Original von omg1010
Habt Ihr eine Ahnung?

Klar, das Text2Skin-Plugin stürzt ab.

Gerald

Zitat

Klar, das Text2Skin-Plugin stürzt ab.

willstn igel einholen oder was... schlaumeier

Zitat

Original von cooljay032

willstn igel einholen oder was... schlaumeier

Zeigt deine Kristallkugel mehr? Muss ich wohl mal zur Überholung bringen.

Gerald

Zitat

Original von omg1010
danke für Deinen Hinweis. Das habe ich auch bereits vermutet. Aber hilfreicher wäre mir eine Analyse oder zumindest welche Infos / Logs notwendig wären, um der Sache weiter auf den Grund zu gehen ... Das das text2skin abstürzt sehe ich auch!

Du brauchst Hilfe, aber du erwartest das andere für dich arbeiten anstatt selber in Vorleistung zu gehen. Das ärgert mich. Bevor du deine Anfrage stellst überlege erst mal selber was ein Helfer brauchen könnte.
Interessant wäre verwendete Distribution, Versionen von VDR und Text2skin-Plugin, verwendeter Skin.
Die Ergebnisse von ein paar Tests die du schon vorab gemacht haben solltest, z.B. ob das Problem mit anderen Skins auch auftritt, oder ob es bestimmte Situationen sind die das auslösen, Ich sehe das du ein paar der Informationen nachgeliefert hast, aber das hätte von vorne herein da stehen müssen.

Gerald

Zitat

Original von omg1010
Ich werde mal andere Skins testen (z.B. PearlHD) und schauen, ob das Problem damit auch auftritt. Ich berichte wieder. Danke.

Hmm, da habe ich Zweifel, da PearlHD ja auch text2skin zugrunde liegt ...

Aber auch ich habe den Fehler auf einem VDR genau einmal gesehen, als ich nachdem Upgrade aus Holger's Repo meinen üblichen Speed-Zap Test gemacht habe. Allerdings ging das einher mit:

Feb 11 19:37:50 vdr1 vdr: [1504] switching to channel 3
Feb 11 19:37:52 vdr1 vdr: [1840] buffer usage: 70% (tid=1839)
Feb 11 19:37:52 vdr1 vdr: [1840] buffer usage: 80% (tid=1839)
Feb 11 19:37:52 vdr1 vdr: [1840] buffer usage: 90% (tid=1839)
Feb 11 19:37:53 vdr1 vdr: [1840] buffer usage: 100% (tid=1839)
Feb 11 19:37:59 vdr1 lircd-0.8.6[879]: removed client
Feb 11 19:38:03 vdr1 lircd-0.8.6[879]: accepted new client on /var/run/lirc/lircd
Feb 11 19:38:50 vdr1 vdr: [1504] PANIC: watchdog timer expired - exiting!
Feb 11 19:38:50 vdr1 vdr: [1504] radio: delete cRadioAudio
Feb 11 19:38:50 vdr1 vdr: [1536] fatal error, server exiting: Ungültiger Dateideskriptor
Feb 11 19:38:50 vdr1 vdr: [1536] streamdev server thread ended (pid=1504, tid=1536)
Feb 11 19:38:50 vdr1 vdr: [1516] Leaving cXineRemote thread
Feb 11 19:38:50 vdr1 vdr: [1516] XineRemote control thread ended (pid=1504, tid=1516)
Feb 11 19:38:50 vdr1 lircd-0.8.6[879]: removed client
Feb 11 19:38:51 vdr1 kernel: [  381.444988] Text2Skin: chan[1838]: segfault at 210 ip 00007f436af98f06 sp 00007f4350b73ac0 error 4 in libvdr-text2skin.so.1.7.16[7f436af56000+55000]
Feb 11 19:38:51 vdr1 runvdr: restarting VDR

Daher könnte der segfault von text2skin auch ein Folgefehler sein, aber eine Gemeinsamkeit gibt es schon: amd64.

Da text2skin die selbe Version geblieben ist, nur wegen der VDR Patches neu gebaut wurde gibt es IMHO hier zwei Möglichkeiten:

• Einer der neu hinzugekommen Patches/Features im VDR aus Holger's Repo verursacht Probleme unter amd64, was in der Folge zu eben auch zu dem segfault in text2skin führt.
• Text2skin veträgt sich nicht mit einem der neu hinzugekommen Patches/Features im VDR aus Holger's Repo unter amd64

Der Fehler trat bei mir wie gesagt nur einmal auf, daher werde ich es weiter beobachten. Aber der Watchdog hat den VDR wieder sauber gestartet und es reicht ein Restart des Xine-Frontends per FB aus.

Wenn ich Dich richtig verstehe, mußt Du Deine Kiste komplett neu starten, warum? Funktioniert der Watchdog nicht? Hängt dabei der VDR, weil er die DVB Module nicht entladen kann? Wenn ja, hast Du cgroups konfiguriert?

Regards
fnu

omg1010

Sieht doch recht ähnlich zu meinem o.a. aus. Es stellt sich die Frage, ob hier text2skin überhaupt das Problem ist oder eher wie schon von mir vermutet ein Folgefehler. Das Desaster fängt bei Dir hier an, als Du auf Kanal 2 schaltest. Da bekommt der VDR keinen Lock auf den Transponder, Du vmtl. kein Bild und schaltest offensichtlich weiter auf Kanal 1:

Feb 11 22:44:12 ogmedia vdr: [1651] switching to channel 2
Feb 11 22:44:12 ogmedia vdr: [2533] osdteletext-receiver thread ended (pid=1651, tid=2533)
Feb 11 22:44:12 ogmedia vdr: [2530] TS buffer on device 1 thread ended (pid=1651, tid=2530)
Feb 11 22:44:12 ogmedia vdr: [2528] buffer stats: 780388 (37%) used
Feb 11 22:44:12 ogmedia vdr: [2528] receiver on device 1 thread ended (pid=1651, tid=2528)
Feb 11 22:44:12 ogmedia vdr: [2544] receiver on device 1 thread started (pid=1651, tid=2544)
Feb 11 22:44:12 ogmedia vdr: [1651] buffer stats: 0 (0%) used
Feb 11 22:44:12 ogmedia vdr: [2545] osdteletext-receiver thread started (pid=1651, tid=2545)
Feb 11 22:44:12 ogmedia vdr: [2546] TS buffer on device 1 thread started (pid=1651, tid=2546)
Feb 11 22:44:17 ogmedia vdr: [2544] cVideoRepacker: switching to MPEG1/2 mode
Feb 11 22:44:17 ogmedia vdr: [2544] cVideoRepacker: operating in MPEG1/2 mode
Feb 11 22:44:17 ogmedia vdr: [2543] Text2Skin: channelInfo display update thread ended (pid=1651, tid=2543)
Feb 11 22:44:21 ogmedia vdr: [2547] Text2Skin: menu display update thread started (pid=1651, tid=2547)
Feb 11 22:45:09 ogmedia wpa_supplicant[1068]: WPS-AP-AVAILABLE 
Feb 11 22:46:09 ogmedia wpa_supplicant[1068]: WPS-AP-AVAILABLE 
Feb 11 22:46:59 ogmedia vdr: [1749] frontend 0/0 lost lock on channel 2, tp 111953
Feb 11 22:47:02 ogmedia vdr: [2547] Text2Skin: menu display update thread ended (pid=1651, tid=2547)
Feb 11 22:47:02 ogmedia vdr: [2549] Text2Skin: menu display update thread started (pid=1651, tid=2549)
Feb 11 22:47:04 ogmedia vdr: [2549] Text2Skin: menu display update thread ended (pid=1651, tid=2549)
Feb 11 22:47:04 ogmedia vdr: [2550] Text2Skin: menu display update thread started (pid=1651, tid=2550)
Feb 11 22:47:06 ogmedia vdr: [2550] Text2Skin: menu display update thread ended (pid=1651, tid=2550)
Feb 11 22:47:11 ogmedia vdr: [1749] frontend 0/0 timed out while tuning to channel 2, tp 111953
Feb 11 22:48:09 ogmedia wpa_supplicant[1068]: WPS-AP-AVAILABLE 
Feb 11 22:49:09 ogmedia wpa_supplicant[1068]: WPS-AP-AVAILABLE 
Feb 11 22:49:20 ogmedia vdr: [2551] Text2Skin: channelInfo display update thread started (pid=1651, tid=2551)
Feb 11 22:49:20 ogmedia vdr: [2545] osdteletext-receiver thread ended (pid=1651, tid=2545)
Feb 11 22:49:20 ogmedia vdr: [1651] switching to channel 1
Feb 11 22:49:20 ogmedia vdr: [2546] TS buffer on device 1 thread ended (pid=1651, tid=2546)
Feb 11 22:49:20 ogmedia vdr: [2544] buffer stats: 140624 (6%) used
Feb 11 22:49:20 ogmedia vdr: [2544] receiver on device 1 thread ended (pid=1651, tid=2544)
Feb 11 22:49:20 ogmedia vdr: [2552] receiver on device 1 thread started (pid=1651, tid=2552)
Feb 11 22:49:20 ogmedia vdr: [1651] buffer stats: 0 (0%) used
Feb 11 22:49:20 ogmedia vdr: [2553] osdteletext-receiver thread started (pid=1651, tid=2553)
Feb 11 22:49:20 ogmedia vdr: [2554] TS buffer on device 1 thread started (pid=1651, tid=2554)
Feb 11 22:49:25 ogmedia vdr: [2551] Text2Skin: channelInfo display update thread ended (pid=1651, tid=2551)
Feb 11 22:49:35 ogmedia vdr: [2555] Text2Skin: channelInfo display update thread started (pid=1651, tid=2555)
Feb 11 22:50:01 ogmedia lircd-0.8.6[858]: read() failed
Feb 11 22:50:01 ogmedia lircd-0.8.6[858]: Connection reset by peer
Feb 11 22:50:01 ogmedia lircd-0.8.6[858]: removed client
Feb 11 22:50:35 ogmedia vdr: [1651] PANIC: watchdog timer expired - exiting!
Feb 11 22:50:35 ogmedia vdr: [1751] Leaving cXineRemote thread
Feb 11 22:50:35 ogmedia vdr: [1751] XineRemote control thread ended (pid=1651, tid=1751)
Feb 11 22:50:35 ogmedia lircd-0.8.6[858]: removed client
Feb 11 22:50:35 ogmedia kernel: [18372.871869] vdr[1651]: segfault at 7f436efeb010 ip 00007f437671a559 sp 00007fff2d74f730 error 4 in libvdr-text2skin.so.1.7.16[7f43766da000+55000]
Feb 11 22:50:35 ogmedia runvdr: restarting VDR

Das klappt dann auch nicht so richtig und der Watchdog springt an. So, nun würde mich interessieren was der Watchdog macht, aber da erfolgt lt. dem angehängten syslog direkt ein Neustart des ganzen Geräts. Hast Du da die Reset-Taste gedrückt?

Aber ich neige dennoch eher dazu, das der VDR mit den geänderten Patches/Feature hier ein Problem verursacht und text2skin nur ein unschöner Folgefehler ist.

Regards
fnu

fnu ich hab in lucid den patch nicht drin.
den brauchte ich erst für natty, weil es da ohne patch erst garnicht gebaut hätte.
also wohl generell ein problem in text2skin

hotzenplotz5

Nein, ich vermute das einer der neuen Patches die Du dieser Tage eingepflegt hattest, für den VDR selbst, hier zu dem Problemen führt, aber keine Ahnung welcher.

Text2skin hat sich ja nicht geändert, ist die selbe Version, nur neu gebaut. Und es fällt auf, das bei omg1010 und mir vorher eher Probleme mit den DVB Devices auftreten. Welcher der neuen Patches zielt darauf ab?

===
[edit] Evtl. das was Du als "no-retune-on-tid" bezeichnet hast? dynamite-Gedöns? [/edit]
===

Ist ja auch kein Vorwurf, konnte ja nun keiner vorher wissen ...

Regards
fnu

hotzenplotz5

Der segfault mit dem text2skin tritt ja auch erst auf, als der VDR Watchdog schon den VDR runtergerissen hat, siehe die zwei o.a. Auszüge aus den zwei syslogs auf zwei verschiedenen Maschinen D.h. der VDR läuft da schon gar nicht mehr so wirklich ...

Regards
fnu

Moin!

Natürlich ist es nicht auszuschließen, dass ein vdr-Patch das Problem verursacht. Aber wenn der Watchdog zuschlägt, kann natürlich immer alles mögliche passieren - auch, dass ein bisher unauffälliges Plugin mal abstürzt.
Besonders, wenn es versucht, Threads zu starten usw. wenn der vdr gerade dabei ist, die Grätsche zu machen.
Wird bestimmt nicht so einfach, das einzukreisen.

Lars.

Zitat

Original von fnu
Text2skin hat sich ja nicht geändert, ist die selbe Version, nur neu gebaut. Und es fällt auf, das bei omg1010 und mir vorher eher Probleme mit den DVB Devices auftreten. Welcher der neuen Patches zielt darauf ab?

Lnb-sharing und dynamite hauen sich um die devices.

Gerald

Zitat

Original von gda
Lnb-sharing und dynamite hauen sich um die devices.

Hmm, hört sich plausibel an.

Allerdings ist lnb-sharing schon sehr lange mit an Board, wenn ich mich richtig erinnere und genau auf dem VDR bei mir, ist lnb-sharing nicht aktiv.

Auf dem Test-VDR habe ich (m)eine neue CineS2 drin, mit aktivem lnb-sharing und auch dem aktualisierten VDR, dort gab es das Problem bisher interessanterweise nicht.

Ich glaube ja, mini73 hat Recht, das wird nicht einfach, vmtl. ist es irgendwann einfach weg und keiner weiß warum ...

Gruß
Frank

Zitat

Original von fnu

Hmm, hört sich plausibel an.

Allerdings ist lnb-sharing schon sehr lange mit an Board, wenn ich mich richtig erinnere und genau auf dem VDR bei mir, ist lnb-sharing nicht aktiv.

Aber ich habe den lnbsharing aktualisiert, sogar 2 mal.

Gerald

gda

Ok, ja stimmt, gab ja auch eine neue Version von MarkusE

Mir fiel nach nochmaliger Durchsicht des syslogs von "omg1010", neben "amd64", noch eine Gemeinsamkeit auf, er verwendet wohl einen Kernel mit cgroup-Patch und ich habe genau auf der Kiste cgroups im Userspace definiert ... auf dem Test-VDR hatte ich mir das gespart ...

Werde das mal abschalten und schauen, nach rnissl's xine-OSD-Speed-Wunderpatch, wird es schon nicht so schlimm werden ...

Gruß
Frank