[ANNOUNCE] VDR version 2.6.4 freigegeben

Vorschlag:

Es gibt eine API Version, die deutlich sichtbar von der VDR Version abweicht.

Alternative: Konfigurierbar über Makefile wird die API Version auf die VDR Version gesetzt (default), kann aber auch den eigenen Wert behalten.

Wer die Plugins nicht neu übersetzen will, kann das dann mit einer make Option erreichen.

Wie schon versucht es irgendwie klar zu machen: Die Versionsnummern können nicht "weg". Auch wenn das definitiv meine liebste Alternative wäre. Ein stabiles API für Plugins das sich möglichst lange nicht mehr ändert und dann auch weg mit dem ständigen Plugin-Neukompilieren. Würde mir so verdammt viel Aufwand sparen beim VDR updaten... Aber auch klar: Der VDR ändert sich stetig (was ja auch gut so ist) und um alle internen Änderungen auch mit Plugins nutzen zu können ist direkter Zugriff auf VDR-Interne Strukturen sehr vorteilhaft.

Ich kann nur immer wieder betonen: Ich habe mich wahnsinnig gefreut bei diesem VDR-Update ausnahmsweise mal nicht stundenlang kompilieren zu müssen. Von mir aus gerne öfter Releases bei denen Plugins nicht neu gebaut werden müssen. Ärgerlich das hier über eine wirkliche Annehmlichkeit dann gemeckert wird. Ich weiß nicht wie viele Plugins speed kompilieren muss, aber ich habe bei jedem VDR-Update so irgendwas um die 80 Plugins zu bauen. Und nutze davon selber vielleicht 3 oder 4.

Vermutlich wäre eine von der VDR version unabhängige Nummerierung tatsächlich das optimale. Wegen mir einfach eine hochlaufende Zahl und gar keine Versionsnummer mehr. Das würde auch ein anderes Problem fixen das sich ergeben hat. Als es noch Entwickler-Versionen (die "ungeraden Versionsnummern") gegeben hat, dann wurden Plugins zu Entwickler-Versionen automatisch inkompatibel wenn eine neue Entwickler-Version mit API-Änderung gekommen ist. Das ist, wenn man regelmäßig vom GIT baut, nun nicht mehr so. Der Entwicklungsstand könnte schon inkompatible Änderungen drauf haben, aber die APIVERSION wurde nicht angepasst weil ja eben nur Entwicklungsstand. Mit einer hochlaufenden Nummer könnte Klaus theoretisch bei jeder für die API inkompatiblen Änderung diese Nummer einfach einmal hochzählen. Auch beim Bauen vom GIT werden dann inkompatible Plugins nicht mehr geladen.

Wenn die APIVERSION letztlich wirklich hart auf die VDRVERSION gemappt wird, dann würde ich mir zumindest einen Hinweis wünschen ob sich eine API-Änderung ergeben hat. Ich würde dann nämlich für Arch gerne hart zurück patchen um mir die ganze Kompiliererei zu sparen. Dafür das ich es selber kaum noch nutze ist mir der ganze VDR-Kram nämlich langsam echt zu viel Aufwand.

M-Reimer

der speed baut auch so einige, habe auch unterschiedliche Plattformen.

Aber ich bin nicht der Maßstab,soll Klaus entscheiden.

Nur so wie es ist, finde ich es nicht gelungen.

Nur durch diese Diskussion kommt es nun Worst Case dazu das es gar keine separate APIVERSION mehr gibt und man wirklich ohne Not ständig neu bauen muss. Dann hätte ich lieber den aktuellen Stand behalten und eben besser dokumentiert das die APIVERSION eben nicht zwingend der VDRVERSION entsprechen muss.

Aber stimmt schon. Letztlich entscheidet Klaus. Ich würde mich auf jeden Fall freuen wenigstens noch einen Hinweis in Changelogs zu sehen wenn kein Neubauen zu Version X nötig ist. Ich würde, wenn keine bessere Lösung kommt, dann lieber die APIVERSION auf diese im Changelog genannte Version zurück patchen statt unnötig neu zu bauen.

M-Reimer

muss ich mich jetzt bei dir entschuldigen gefragt zu haben ?

> Welchen Vorteil es bringen soll, statt der an die VDRVERSION angelehnten APIVERSION eine andere laufende Nummer zu nehmen, erschließt sich mir nicht

Na ja, wenn ich vdr 2.6.4 habe, und die Namen der Plugins enden mit 2.6.3, dann gibt es Menschen, die vermuten, dass etwas nicht stimmt.

Wenn ich vdr 2.6.4 habe, und die Namen der Plugins enden mit 73, dann ist allen klar, dass diese Nummern nichts miteinander zu tun haben.

> Vorerst lasse ich es mal so, wie es ist.

Finde ich gut. Ich habe 3 Kinder, und einer pienst immer ...

Ich habe 3 Kinder, und einer pienst immer ...

Quote from MarkusE

Finde ich gut. Ich habe 3 Kinder, und einer pienst immer ...

Cool, wenn du trotzdem noch ein wenig Zeit für deine Projekte abknapsen kannst.

Ich sag's nur ungern, aber ich habe wieder einen Deadlock, diesmal in RecordingsHandler::Finished()

Details später ...

Nach reiflicher Überlegung ... verstehe ich immer noch nicht was da passiert ist.

Beim Schneiden auf der zweiten SSD lief diese voll, so dass das Schneiden abgebrochen wurde. Dann hing der VDR mit offenem Recording Display bis ich ihn beendet habe.

(gdb) bt  
#0  0x00007f16a78d3463 in __lll_lock_wait () from /lib64/libpthread.so.0
#1  0x00007f16a78cb1d1 in pthread_mutex_lock () from /lib64/libpthread.so.0
#2  0x0000000000540f19 in cMutex::Lock (this=0x61bde0 <RecordingsHandler+96>) at thread.c:224
#3  0x000000000054167f in cMutexLock::Lock (this=0x7ffd415bd200, Mutex=<optimized out>) at thread.c:409
#4  0x00000000005063cf in cRecordingsHandler::Finished (this=0x61bd80 <RecordingsHandler>, Error=@0x7ffd415bd320: false) at recording.c:2119
#5  0x0000000000480895 in main (argc=<optimized out>, argv=<optimized out>) at vdr.c:1525

(gdb) bt
#0  0x00007f16a78d3463 in __lll_lock_wait () from /lib64/libpthread.so.0
#1  0x00007f16a78cb1d1 in pthread_mutex_lock () from /lib64/libpthread.so.0
#2  0x0000000000540f19 in cMutex::Lock (this=0x61bc00 <cControl::mutex>) at thread.c:224
#3  0x000000000054167f in cMutexLock::Lock (this=0x7f160247cc50, Mutex=<optimized out>) at thread.c:409
#4  0x00000000005009e7 in cControl::Shutdown () at player.c:110
#5  0x000000000049944d in cCutter::Active (this=0x7f1654005110) at cutter.c:714
                             calls Stop();
#6  0x000000000050bf8d in cRecordingsHandlerEntry::Active (this=this@entry=0x11858c0, Recordings=Recordings@entry=0x61bf80 <cRecordings::recordings>) at recording.c:1938
#7  0x000000000050c2dc in cRecordingsHandler::Action (this=0x61bd80 <RecordingsHandler>) at recording.c:2035
                            LOCK_RECORDINGS_WRITE in recording.c:2035
#8  0x0000000000541395 in cThread::StartThread (Thread=0x61bd80 <RecordingsHandler>) at thread.c:293
#9  0x00007f16a78c86ea in start_thread () from /lib64/libpthread.so.0
#10 0x00007f16a6139a6f in clone () from /lib64/libc.so.6

Ich sehe aber in den beiden Backtraces keine zweite Mutex, die zu einem Deadlock führen könnte.

Kann es sein, dass der Compiler da die Mutexe verwechselt weil sowohl das statische cMutex cControl::mutex in cControl::Shutdown() als auch private cMutex mutex in cRecordingsHandler::Finished() nur als &mutex angesprochen werden?

kls : Kannst Du Dir das bitte mal ansehen?

Vielleicht mal -Wshadow versuchen, falls das nicht aktiv ist?

Ok, ich werde es mit -Wshadow probieren und versuchen das nochmal nachzustellen