gelöst [yavdr 0.5 testing] yaepgHD funktioniert nicht mehr nach update

pc-medusa

Ah, guter Hinweis, hab vorhin den Wald vor lauter Bäumen nimmer gesehen. Nun ein paar Liter Sprit später, wollte ich mich nomm'l ransetzen, untersuche ich gleich mal

Regards
fnu

@all

So, bitte mal testen, hab's hier auf 2 VDRs getestet und läuft.

Früher hatten wir die Themes in einem eigenen Paket "vdr-plugin-yaepghd-themes", was evtl. der ein oder andere noch auf dem VDR hat oder eben noch Reste davon, diese bitte möglichst entfernen.

Das Paket "vdr-plugin-yaepghd-themes" ist nun als Konflikt definiert, würde also automatisch deinstalliert, aber keine Reste entfernen.

Der sauberste Weg wäre IMHO:

#/> sudo apt-get update
#/> sudo apt-get purge vdr-plugin-yaepghd [vdr-plugin-yaepghd-themes]
#/> sudo apt-get install vdr-plugin-yaepghd

Nachdem Neustart dann nicht ungeduldig werden, kann sein das es 1-2min dauert bis alle Senderzeilen mit EPG befüllt sind.

Regards
fnu

Der VDR stürzt leider nach Aufruf von yaepghd ab.

Core was generated by `/usr/bin/vdr-dbg --lirc=/var/run/lirc/lircd -v /srv/vdr/video.00 -c /var/lib/vd'.
Program terminated with signal 11, Segmentation fault.
#0  0x00007f6140ae2101 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0  0x00007f6140ae2101 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007f6138128d5c in length (__s=0x0) at /usr/include/c++/4.6/bits/char_traits.h:261
#2  assign (__s=0x0, this=0x2879d20) at /usr/include/c++/4.6/bits/basic_string.h:1121
#3  Text (_text=0x0, this=0x2879d20) at yaepghd.c:831
#4  cYaepgMsg::UpdateMsg (this=<optimized out>, msg=<optimized out>) at yaepghd.c:2629
#5  0x00007f6138131832 in cYaepghd::Show (this=0x2825ae0) at yaepghd.c:3015
#6  0x000000000046f12b in main (argc=<optimized out>, argv=<optimized out>) at vdr.c:1116

Ich habe vorher alle Pakete für yaepghd deinstalliert und auch im Filesystem nach Resten gesucht, aber nichts weiter gefunden. Nach Neuinstallation und Restart des VDR ergibt sich leider keine Besserung.

Installiert habe ich folgendes

dpkg -l | grep -i yaepg
ii  vdr-plugin-yaepghd               	0.0.5pre1+git20130414-1yavdr0~precise    	Rewrite for Yaepg
ii  vdr-plugin-yaepghd-dbg           	0.0.5pre1+git20130414-1yavdr0~precise    	debugging symbols for vdr-plugin-yaepghd

Mir ist noch völlig unklar, was ich übersehen/überlesen haben könnte bzw. wo ich suchen soll.

Edit: Wenn ich RemoteTimers in yaepghd deaktiviere (auf nein setze), dann sehe ich zumindest das EPG wieder.

Zabrimus

Zabrimus

Oha, gleich mal das dbg Paket installiert, wurde erst vor ein paar Tagen eingetüten und, Asche auf mein Haupt, selbst habe ich es noch nicht probiert.

Danke für den Test, ich hoffe damit kann nun jemand was anfangen, ansonsten müßten wir halt nomm'l ran ...

Liegt noch etwas unter "/usr/lib/vdr/vdr-plugin-yaepghd"?

[EDIT] Welches theme hast Du definiert? [/EDIT]

Regards
fnu

Das Verzeichnis /usr/lib/vdr/vdr-plugin-yaepghd existiert nicht. Als Skin verwende ich nopacity mit dem Theme Dark Blue. Im yaepghd finde ich das Theme Vid_Win_1920.

Aber ich denke, es liegt irgendwie an RemoteTimers. Schalte ich es in yaepghd ab, wird das EPG dargestellt. Aber laut Code hätte ich da eher eine Fehlermeldung erwartet und keinen Absturz. Eine Neuinstallation von RemoteTimers hat nichts gebracht. Dies dürfte aber eine andere Baustelle sein und hat erstmal nichts mit yaepghd zu tun.

Zabrimus

@Zambrinus

Ok, wenn Du meinst.

utiltiy berichtete vorhin, das er in der "setup.conf" noch ein Theme für yaepghd definiert hatte, das es nach Installation nimmer gab und deshalb der Aufruf von yaepghd fehl schlug. Insofern auch abstrakt eine Art "Rest" ...

Regards
fnu

fnu

Das Problem lässt sich reproduzieren. RemoteTimers in yaepghd aktiviert -> Crash. Deaktiviert -> EPG wird vollständig dargestellt.
In der setup.conf finde ich auch keine Reste mehr. Alle Einstellungen zu dem Plugin hatte ich gelöscht und mit der Default-Einstellung gestartet.

Verantwortlich scheint der Code in yaepghd.c zu sein (zumindest bei mir)

if (iRemoteTimer && pRemoteTimers) {
  	cString errorMsg;
  	if (!pRemoteTimers->Service("RemoteTimers::RefreshTimers-v1.0", &errorMsg)) {
     	messageBox = new cYaepgMsg();
     	messageBox->UpdateMsg((char*)*errorMsg);
     	msgBoxStart = cTimeMs::Now();
  	}
}

Im Backtrace sieht man dann
Text (_text=0x0, this=0x2879d20) at yaepghd.c:831
und es kracht dann. Der Code in RemoteTimers sieht so aus

bool cPluginRemotetimers::Service(const char *Id, void *Data)
{
	[viel gelöscht]


	if (strcmp(Id, "RemoteTimers::RefreshTimers-v1.0") == 0) {
 	if (Data) {
    	cString *errorMsg = (cString *) Data;
    	if (svdrp->Connect() && RemoteTimers.Refresh() == rtsOk) {
       	cSchedulesLock SchedulesLock;
       	const cSchedules *Schedules = cSchedules::Schedules(SchedulesLock);
       	if (Schedules) {
          	for (cRemoteTimer *timer = RemoteTimers.First(); timer; timer = RemoteTimers.Next(timer)) {
             	timer->SetEventFromSchedule(Schedules); // make sure the event is current
          	}
       	}
    	}
    	else {
       	*errorMsg = tr(MSG_UNAVAILABLE);
    	}
    	svdrp->Disconnect();
    	return **errorMsg == NULL;
 	}
 	return true;
  }

  [noch mehr gelöscht]
}

Aber vielleicht könnte man das in yaepghd abfangen damit zumindest der Aufruf den VDR nicht in die Knie gezwungen wird, obwohl die Ursache wohl eher in RemoteTimers zu suchen ist.

Etwas unglücklich bin ich mit der Kombination epgsearch und RemoteTimers. Die Timer werden alle lokal abgelegt, aber ich muss erstmal weiter suchen, ob ich nicht eine Einstellung übersehen habe. Bevor der Thread aber nun komplett abdriftet höre ich besser auf.

Zabrimus

Zitat von Zabrimus

Aber vielleicht könnte man das in yaepghd abfangen damit zumindest der Aufruf den VDR nicht in die Knie gezwungen wird, obwohl die Ursache wohl eher in RemoteTimers zu suchen ist.

Gut das Du den Zusammenhang gefunden hast und ja, das wäre bestimmt auch einen eigenen Thread wert und sinnvoll, remotetimers verwenden bestimmt auch ein paar andere Nutzer.

Regards
fnu