upnp plugin crasht vdr / libtntdb.so

TCr82 · 10. Januar 2015

Hi,

würde gerne das upnp plugin verwenden (habe vdr-testing ppa aktiv). aber sobald ich es installiere/aktiviere kommt folgendes im log und vdr schmiert ab:

Code

Jan 10 00:29:17 vdr vdr: [12852] initializing plugin: upnp (1.0.0): UPnP/DLNA-konformer Media Server für den VDR
Jan 10 00:29:17 vdr vdr: [12852] UPnP#011Initialized UPnP media server on 192.168.99.99:49152
Jan 10 00:29:17 vdr vdr: [12852] UPnP#011Exception occurred while connecting to database 'sqlite:/metadata.db': /usr/lib/tntdb/libtntdb4-sqlite.so: Kann die Shared-Object-Datei nicht öffnen: Datei oder Verzeichnis nicht gefunden
[...]
Jan 10 00:29:21 vdr kernel: [29784.203947] vdr[12852]: segfault at 0 ip 00007f290e975170 sp 00007fffa488d650 error 4 in libtntdb.so.4.0.0[7f290e956000+3b000]

Code

root@vdr:~# dpkg -l|grep tnt
ii  libtntdb2                             1.1-1                                       C++ class library for easy database access
ii  libtntdb4                             1.3-0yavdr0~precise                         C++ class library for easy database access
ii  libtntnet12                           2.2.1-0yavdr0~precise                       Tntnet libraries
ii  libtntnet9                            2.0+rev.1308-0yavdr0~precise                Tntnet libraries
ii  tntdb-sqlite2                         1.1-1                                       SQLite backend for tntdb database access library
ii  tntnet                                2.2.1-0yavdr0~precise                       modular, multithreaded web application server for C++
ii  tntnet-runtime                        2.2.1-0yavdr0~precise                       Tntnet runtime system

Code

# apt-cache policy libtntdb4
libtntdb4:
  Installiert: 1.3-0yavdr0~precise
  Kandidat:    1.3-0yavdr0~precise
  Versionstabelle:
 *** 1.3-0yavdr0~precise 0
        500 http://ppa.launchpad.net/yavdr/unstable-main/ubuntu/ precise/main amd64 Packages
        100 /var/lib/dpkg/status

jetzt habe ich sogar auch das vdr ppa von testing auf unstable umgestellt (was mich einiges an zeit gekostet hat bis wieder alles lief), da ich dachte wenn ich yavdr-unstable verwende das ich dann auch vdr-unstable brauche.

Aber das problem bleibt das gleiche. Hat wer eine Idee?

Gruß

TCr82 · 10. Januar 2015

ok, es fehlte tntdb-sqlite4 - solle man mal in den abhängigkeiten ergänzen.

Es läuft aber trotzdem nicht, der vdr stürzt andauernd ab. Im Log ist aber diesmal diesbezüglich nichts aussagekräftiges zu finden.

nur das:

Code

Jan 10 02:56:06 vdr vdr: [12766] video directory scanner thread started (pid=12727, tid=12766, prio=high)
Jan 10 02:56:06 vdr kernel: [38588.925668] init: vdr-frontend main process (12761) terminated with status 1
Jan 10 02:56:06 vdr kernel: [38588.925701] init: vdr-frontend main process ended, respawning
Jan 10 02:56:06 vdr kernel: [38588.938475] init: vdr-frontend post-stop process (12774) terminated with status 1
Jan 10 02:56:06 vdr vdr: [12727] UPnP#011Initialized UPnP media server on 192.168.99.99:49152
Jan 10 02:56:06 vdr kernel: [38588.992246] vdr[12727]: segfault at 7ff124000000 ip 00007ff139860270 sp 00007fff881d1658 error 4 in libc-2.15.so[7ff1397dd000+1b5000]
Jan 10 02:56:06 vdr kernel: [38589.236322] init: vdr main process (12727) killed by SEGV signal
Jan 10 02:56:07 vdr vdr: [12794] VDR version 2.1.6 started

glaub für heute geb ich auf

Gruß

fatzgenfatz · 30. Januar 2015

Hallo,
ich stehe vor dem selben Problem wie du, hast du inzwischen schon eine Lösung gefunden?

mfG,
f.

TheChief · 30. Januar 2015

Wie immer, Backtrace erstellen und schauen, wo es crashed.

mini73 · 30. Januar 2015

Zitat von TCr82

jetzt habe ich sogar auch das vdr ppa von testing auf unstable umgestellt (was mich einiges an zeit gekostet hat bis wieder alles lief), da ich dachte wenn ich yavdr-unstable verwende das ich dann auch vdr-unstable brauche.

unstable für precise ist nicht zu empfehlen, die Pakete sind alt und ungepflegt und werden demnächst gelöscht. Aber unstable war noch nie zu empfehlen.
Unter precise entweder (komplett) testing oder stable verwenden.

Lars.

gda · 30. Januar 2015

Zitat von mini73

unstable für precise ist nicht zu empfehlen, die Pakete sind alt und ungepflegt und werden demnächst gelöscht. Aber unstable war noch nie zu empfehlen.

Ehrlich gesagt war das upnp plugin auch noch nie zu empfehlen. Ich kann mich nicht erinnern, dass es schon mal stabil lief. Der Entwickler hat auch ganz offensichtlich das Interesse verloren und wir sollten das Plugin generell entfernen, auch aus unstable.

Gerald

mini73 · 30. Januar 2015

Es gehört ja auch nicht zur Standard-Installation, und solange es klaglos kompiliert, ist es mir egal, ob es im PPA liegt oder nicht.
Wenn es da ist, kann es ja vielleicht irgend jemand mal reparieren, der sich dafür interessiert.

Lars.

Frodo · 30. Januar 2015

Könnte man Paketen welche als nicht funktionierend bzw. fehlerhaft identifiziert wurden, anstelle von der Bezeichnung yavdr z.B. develop/unstable anhängen?
Dann wüsste jeder was ihn erwartet wenn er sich dieses Paket installiert.

mini73 · 30. Januar 2015

Das Kürzel "yavdr" hinten dran braucht mein yalptool, um alle Plugins neu bauen zu können (Versionsnummer hochzählen).
Ich könnte mir sonst höchstens ein weiteres PPA vorstellen, wo wir all die Plugins lagern, die uns egal sind.

Lars.

sebschneider · 17. Mai 2015

Bei mir hat es geholfen, in /var/lib/vdr/setup.conf den Eintrag

Code

upnp.databaseDir =

auf

Code

upnp.databaseDir = /var/lib/vdr/plugins/upnp

zu setzen.

Auf die Lösung bin ich gekommen, als ich im Stacktrace geschaut habe, wo es denn kracht:

Code

Program terminated with signal 6, Aborted.
#0  0x00007f9a5c88a0d5 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#0  0x00007f9a5c88a0d5 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007f9a5c88d7c0 in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x00007f9a5c8c732e in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#3  0x00007f9a5c8d1b26 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#4  0x00007f9a56247690 in sqlite3_free () from /usr/lib/x86_64-linux-gnu/libsqlite3.so.0
#5  0x00007f9a48178688 in tntdb::sqlite::SqliteError::SqliteError(char const*, char*, bool) () from /usr/lib/tntdb/tntdb4-sqlite.so
#6  0x00007f9a4816c0e0 in tntdb::sqlite::Connection::execute(std::string const&) () from /usr/lib/tntdb/tntdb4-sqlite.so
#7  0x00007f9a52d89176 in tntdb::Connection::execute(std::string const&) () from /usr/lib/libtntdb.so.4
#8  0x00007f9a538186bf in upnp::cMediaServer::Initialize (this=0x7f9a53a98ba0) at server/server.cpp:256
#9  0x00000000004d780c in cPluginManager::InitializePlugins (this=<optimized out>) at plugin.c:374
#10 0x000000000046cd14 in main (argc=<optimized out>, argv=<optimized out>) at vdr.c:778

Alles anzeigen

Im Frame #8 versucht das Plugin ein paar Eigenschaften der SQLite Datenbank zu setzen. Kurz vorher wird im Code die Verbindung aufgebaut, aber nicht überprüft, ob der Verbindungsaufbau erfolgreich war. Der einzige Parameter für den Verbindungsaufbau ist der Pfad zur Datenbank-Datei. Mittels gdb habe ich dann die core-Datei vom VDR-crash analysiert und gesehen, dass die Konfigurationsvariable "databaseDir", aus der der Pfad zur "metadata.db" genommen wird, leer ist. Folglich versucht das Plugin die Datenbank-Datei in "/metadata.db" abzulegen, was aus Zugriffsrechtegründen nicht möglich ist. Wenn also die Verbindung nicht aufgebaut werden kann, schlägt natürlich auch das Setzen der Datenbankeinstellungen fehl. Im Plugin ist der Code eigentlich in einem try-catch-Block, aber irgendwie scheint libtntdb lieber zu segfaulten als eine std::exception zu werfen...

Naja, jetzt funktioniert es bei mir wieder, allerdings bin ich gespannt, wann es das nächste Mal kracht.

upnp plugin crasht vdr / libtntdb.so

Jetzt mitmachen!

Teilen

Benutzer online in diesem Thema