[0.5] Live verursacht manchmal Absturz

Da es gerade wieder aktuell ist, kann man als Workaround nicht sowas machen, um den Fehler abzufangen?

virtual std::string const LongDescr() const 
{
if (!m_event)
 return std::string("");
else
 return std::string(m_event->Description() ? m_event->Description() : ""); 
}

Zitat von TheChief

Da es gerade wieder aktuell ist, kann man als Workaround nicht sowas machen, um den Fehler abzufangen?

wenn deine Änderung hilft, dann geht es aber auch so:

virtual std::string const LongDescr() const 
{
 return std::string(m_event && m_event->Description() ? m_event->Description() : ""); 
}

War mir nicht sicher, ob das auch so geht. Aber vielleicht könnte mal jemand mit vielen Timern testen. Hab aktuell grad keine.

ich kann das mal einbauen heute Abend und testen - habe ne ganze Reihe von Timern - aber ich bezweifle, dass es hilft - denn wenn m:event ungültig ist, bringt der if nichts.

Da hilft IMHO nur sauberes locking "vorne dran"

Kachelt immer noch ab - das ärgerliche dabei:
- laufende Aufnahmen werden unterbrochen
- manchmal rutscht aber auch ein Timer "aus versehen" in die timersdone.conf

na dann muss da mal jemand ran, der sich damit auskennt Ich öffne nochmal ein Ticket auf vdr-developer.

TheChief: welche Version der cxxtools nutzt du? Ich habe den Eindruck, dass es mit der letzten stabilen Version 2.2.1 nicht mehr passiert.
Vielleicht können die vdr4arch-Nutzer und andere, die schon die aktuelle Version 2.2.1 einsetzen (z.B. easyVDR Alpha mit den Pakete aus trusty) etwas dazu schreiben, ob sie damit noch Abstürze beobachten konnten.

Dass das mit der cxxtools-Version zusammenhängt, glaube ich ehrlich gesagt nicht. Ich hab aber 2.1.1.

root@homeserver:~# apt-cache policy libcxxtools8
libcxxtools8:
  Installiert:           2.1.1-1
  Installationskandidat: 2.1.1-1
  Versionstabelle:
 *** 2.1.1-1 0
        500 http://mirror.switch.ch/ftp/mirror/debian/ wheezy/main amd64 Packages
        100 /var/lib/dpkg/status

Aktuell hab ich keine Timer und wenn, dann weiss ich, dass ich da nicht klicken darf, da es zum Absturz kommen KÖNNTE.

tntnet könnte da natürlich auch noch mit hineinspielen - da gab es auch noch Bugfixes beim Threading und den Request-Headern: http://www.tntnet.org/download…1/Releasenotes-2.2.1.html

Um mal die cxxtools und tntnet auszuschließen (den recimagesv3-Patch im live-Plugin hat mini73 gestern auch noch um [live] Patch für Recording Images erweitert) hier mal ein PPA mit den betroffenen Paketen passend zu testing-vdr und testing-yavdr:
https://launchpad.net/~seahawk…l/+archive/tntnet-testing

Vielleicht können das mal die betroffenen yaVDR Nutzer mit Crashes des live-Plugin ausprobieren.

Moin seahawk,

leider passiert es auch mit neuen cxxtools und tntnet aus deinem Repo:

Mar 13 10:44:11 htpc kernel: [10713.088997] vdr[6483]: segfault at f800 ip 00007f256f2ef99f sp 00007f2510ff1ad8 error 4 in libc-2.15.so[7f256f1b5000+1b5000]

Cheers,
Ole

Moinsen nochmal,

der Patch im Live-Plugin hat anscheinend noch mehr verändert. In den Aufnahmen werden die Ordner
nicht mehr sauber eingerückt (siehe Screenshot - Lilyhammer und Star Trek Enterprise).

Screenshot

Cheers,
Ole

Dazu gibts hier einen Thread:

LIVE-Plugin - Einrücken von Unterverzeichnissen

Bei mir wir alles korrekt eingerückt, aber andere Nutzer haben das Problem auch.

Hallo TheChief,
das mag ja sein, aber...

Bis zur Installation von minis Update aus seahawks Repo wurde auch bei mir korrekt eingerückt, danach nicht mehr.
Aktuell bin ich wieder auf die Version aus yaVDR-Testing zurück (0.3.0+git20130915-4yavdr2~precise) und alles ist wieder schön.

root@htpc:~# apt-cache policy vdr-plugin-live
vdr-plugin-live:
  Installiert: 0.3.0+git20130915-4yavdr2~precise
  Kandidat:    0.3.0+git20130915-4yavdr2~precise
  Versionstabelle:
     0.3.0+git20130915-5yavdr2~precise 0
        500 http://ppa.launchpad.net/seahawk1986-hotmail/tntnet-testing/ubuntu/ precise/main amd64 Packages
 *** 0.3.0+git20130915-4yavdr2~precise 0
       1002 http://ppa.launchpad.net/yavdr/testing-vdr/ubuntu/ precise/main amd64 Packages
        100 /var/lib/dpkg/status
     0.2.0-17 0
        500 http://de.archive.ubuntu.com/ubuntu/ precise/universe amd64 Packages

Die Basis beider Versionen ist gleich, also gehe ich mal von einem Problem im geänderten Patch aus.

Cheers,
Ole

Moin!

Dies ist die Änderung am recimages-Patch:

diff -Nru vdr-plugin-live-0.3.0+git20130915/debian/patches/recimagesv3.diff vdr-plugin-live-0.3.0+git20130915/debian/patches/recimagesv3.diff
--- vdr-plugin-live-0.3.0+git20130915/debian/patches/recimagesv3.diff	2013-09-18 16:44:02.000000000 +0000
+++ vdr-plugin-live-0.3.0+git20130915/debian/patches/recimagesv3.diff	2014-03-12 20:01:13.000000000 +0000
@@ -194,14 +194,17 @@
  		// select additional (not build in) javascript.
  		// WARNING: no path components with '.' in the name are allowed. Only
  		// the basename may contain dots and must end with '.js'
-@@ -323,6 +326,11 @@ namespace vdrlive {
+@@ -323,6 +326,14 @@ namespace vdrlive {
  				   "image/$2");
  		}

 +		// rec images
-+		app.mapUrl("^/recimages/([^/]*)/([^/]*)\\.([^./]+)", "content")
-+			.setPathInfo("/tmp/$1_$2.$3")
-+			.pushArg("image/$3");
++		MapUrl(app,
++                           "^/recimages/([^/]*)/([^/]*)\\.([^./]+)",
++                           "content",
++                           "",
++			   "/tmp/$1_$2.$3",
++			   "image/$3");
 +
  		// select additional (not build in) javascript.
  		// WARNING: no path components with '.' in the name are allowed. Only

Wie soll das einen Einfluss auf die Einrückung haben? Es werden die gleichen Funktionen wie vorher aufgerufen, nur syntaktisch anders und es bezieht sich nur auf ein Mapping der recimages-URLs. Wenn das einen Einfluss hat, dann ist irgendwo anders im Patch oder live was schief.

Lars.

Zitat von mini73

Wie soll das einen Einfluss auf die Einrückung haben?

Gute Frage, eigentlich keinen. Wenn sich aber ausser diesem Patch nichts am paketierten Plugin
geändert hat, liegt es doch nahe, oder? Wie gesagt: mit der Vorgängerversion passt das Einrücken wieder.

Edit: Und ein DirDiff sagt mir, dass sich nur der Patch bzw. tntconfig.cpp geändert hat.

[A]=/root/install/vdr-plugin-live-alt/vdr-plugin-live-0.3.0+git20130915
[B]=/root/install/vdr-plugin-live/vdr-plugin-live-0.3.0+git20130915
Usage:   <Enter>/'o'=open,'s'=sync,'\dj'=next,'\dk'=prev, 'q'=quit
Options: 'u'=update,'x'=set excludes,'i'=set ignore,'a'=set args
Diff Args: -r --brief


==> Dateien [A]/debian/changelog und [B]/debian/changelog sind verschieden.
    Dateien [A]/debian/patches/recimagesv3.diff und [B]/debian/patches/recimagesv3.diff sind verschi
    Dateien [A]/tntconfig.cpp und [B]/tntconfig.cpp sind verschieden.

Edit2: Ist's dann doch eher ein Problem mit tntnet?

Cheers,
Ole

Naja, ich hab auch den recimages-Patch (da der ja mal von mir stammte ;)) und bei mir passt es. Hab aber lange kein git pull mehr gemacht. Eventuell hat sich ja was im git geändert?

OleS wegen der Crashes:
Vielleicht kannst du mal einen Backtrace mit allen denkbaren Debug-Symbolen erstellen (für libcxxtools und tntnet habe ich in meinem PPA noch Debug-Pakete mitbauen lassen - die also bitte noch mal aktualisieren lassen). Soweit ich das aus dem Backtrace, den Urknall hier im Thread gepostet hatte gesehen habe, braucht man mindestens diese Debug-Pakete:

libc6-dbg
libstdc++6-4.6-dbg
libcxxtools-dbg
libtntnet-dbg
vdr-dbg
vdr-plugin-live-dbg

Bin dabei...

Cheers,
Ole

Also manchmal ist der Wurm drin. Ich habe gerade noch einmal die alten Versionen der cxxtools und tntnet
installiert und anschließend wieder das Update gemacht. Dabei ist mir aufgefallen, dass tntnet nicht neu gestartet
wird (socket already in use). Diesen habe ich gekillt und danach neu gestartet und schon war die Version 2.2 startbar
(kontrolliert in /var/log/upstart/tntnet.log).

Jetzt läuft der VDR mit entsprechenden debug-Symbolen und ich bekomme ihn nicht zum segfault... grummel!

Wäre ja zu schön, aber ich teste weiter.

Cheers,
Ole