[ANNOUNCE] VDR Version 2.6.3 freigegeben

Zitat von seahawk1986

CKone hat die in seinem PPA schon eingearbeitet: https://launchpad.net/~ckone/+archive/ubuntu/jammy-vdr

Nachdem ich nun nach beherztem "dist-upgrade" und ein paar Nacharbeiten die Vorraussetzungen zur Nutzung des o.g. PPA's hatte, bin ich leider trotzdem nicht zum Ziel gekommen.

Ich nutze das vdr-2.6.3 PPA von seahawk1986 (da sind ein paar Plugins drin, die ich brauche und die CKone leider nicht im PPA hat) und füge dann das PPA von CKone hinzu. Nach einer apt Aktualisierung tauscht er auch brav allein das vdr Paket aus - soweit ok.

Leider zeigt er mir nach dem Neustart keinerlei OSD mehr an (skindesigner - es soll zapcockpit zum Einsatz kommen). Im Log sieht man nur:

Jan 18 15:26:06 yavdr vdr: [4452] ERROR: attempt to open OSD while it is already open - using dummy OSD!
Jan 18 15:26:06 yavdr vdr: [4452] ERROR: cOsd::SetAreas returned 5 (wrong alignment)
Jan 18 15:26:06 yavdr vdr: [4452] skindesigner: Error initiating displaychannel view - aborting

Wenn ich das Quellpaket aus seahawks Repo mit dem Patch aktualisiere, passiert das Gleiche.

Ich nutze softhddevice mit "-v cuvid" - was ohne Patch auch prima funktioniert. Beim vdr Start (mit Patch) steht noch folgendes im Log:

Jan 18 15:21:30 yavdr vdr: [4452] [softhddev]Trying to start OpenGL Worker Thread
Jan 18 15:21:30 yavdr vdr: [4600] oglThread thread started (pid=4452, tid=4600, prio=high)
Jan 18 15:21:30 yavdr vdr: [4600] [softhddev]OpenGL Context initialized
Jan 18 15:21:30 yavdr vdr: [4600] [softhddev]Shaders initialized
Jan 18 15:21:30 yavdr vdr: [4600] [softhddev]Vertex buffers initialized
Jan 18 15:21:30 yavdr vdr: [4600] [softhddev]Maximum Pixmap size: 32768x32768px
Jan 18 15:21:30 yavdr vdr: [4452] [softhddev]OpenGL Worker Thread successfully started
Jan 18 15:21:30 yavdr vdr: [4600] [softhddev]ERROR: Framebuffer is not complete! 8cd6
Jan 18 15:21:30 yavdr vdr: [4452] ERROR: cOsd::SetAreas returned 5 (wrong alignment)
Jan 18 15:21:30 yavdr vdr: [4452] skindesigner: Error initiating displaychannel view - aborting

Hat hier jemand eine Idee oder nutzt jemand das PPA von CKone unter ähnlichen Bedingungen ohne Probleme?

Hi,

Du musst alles aus einem ppa nutzen. Nur den VDR geht nicht. Die Plugins werden ja dagegen gebaut.

MfG Stefan

Zitat von SurfaceCleanerZ

Hi,

Du musst alles aus einem ppa nutzen. Nur den VDR geht nicht. Die Plugins werden ja dagegen gebaut.

MfG Stefan

Grundsätzlich richtig - im konkreten Fall sollten die Versionen an sich grundsätzlich passen. I

ch hatte aber auch geschrieben dass ich den Fehler auf die gleiche Art sehe, wenn ich das Source-Paket mit dem (dort ja schon enthaltenen) Patch versehe und anschließend mit erhöhter Versionsnummer nutze...

Hi,

Und du hast auch nicht nur VDR sondern auch alle Plugins nach dem Patchen neu gebaut? Möglichst, wenn drin, mit dem src der damit im ppa gebaut wurde?

Könntest noch das ppa forken und ergänzen.

MfG Stefan

Ok. So einfach war es dann wohl doch nicht - zumindest funktioniert es mit seahawk1986 's neuem Patch-PPA ohne Probleme. Tausend Dank dafür...

Ich hatte jetzt schon mehrfach den Fall, dass VDR hängen blieb. Debuggen konnte ich das zweimal, als ich eine Wiedergabe starten wollte und in diesem Moment offenbar ein Schnittprozess fertig wurde.

Es hat offenbar etwas mit dem LOCK_RECORDINGS_WRITE und dem mutex im cRecordingshandler zu tun, mir ist aber nicht klar, wo welche Locks zuvor angefordert werden. Es scheint aber mit dem Patch http://git.tvdr.de/?p=vdr.git;…a62c38bea4712272623779b5e von VDR 2.6.2 zusammen zu hängen, da damit das LOCK_RECORDINGS_WRITE in cRecordingsHandlerEntry::Active() reingekommen ist.

Vielleicht kann jemand mehr aus den Backtraces lesen?

Zitat von FireFly

Vielleicht kann jemand mehr aus den Backtraces lesen?

Ich hatte ein ähnliches Problem, allerdings ist der VDR bei mir immer beim Verschieben von Verzeichnissen hängen geblieben.

Beim debuggen bin ich dann an der gleichen Stelle wie Du gelandet (cRecordingshandler und cRecordingsHandlerEntry::Active()) und im Endeffekt beim gleichen commit.

Das Ganze war bei mir auch soweit reproduzierbar und ich habe dann einen Zusammenhang mit dem offenen Menü festgestellt, da es ohne offenem Menü nie passiert ist. Da ich bei mir die menu.c aber massiv gepatcht habe um eine "bessere" Bedienung zu realisieren, habe ich es erst einmal darauf geschoben und nicht am Plain-VDR weiter verfolgt.

Im Endeffekt kommen sich aber hier LOCKS aus der menu.c und der recordings.c ins Gehege.

Für den Fall "Verschieben" habe ich für mich eine Lösung in der Funktion "cMenuPathEdit::ApplyChanges" gefunden:

        LOCK_RECORDINGS_READ;
        NumRecordings = Recordings->GetNumRecordingsInPath(path);
      }
      if (NumRecordings > 1 && !Interface->Confirm(cString::sprintf(tr("Move entire folder containing %d recordings?"), NumRecordings)))
         return osContinue;
      bool Error = false;
+     bool Modified = false;
+     cStateKey StateKey;
      {
-       LOCK_RECORDINGS_WRITE;
-       Recordings->SetExplicitModify();
-       Error = !Recordings->MoveRecordings(path, NewPath);
-       if (!Error)
-          Recordings->SetModified();
+       if (cRecordings *Recordings = cRecordings::GetRecordingsWrite(StateKey)) {
+          Recordings->SetExplicitModify();
+          Error = !Recordings->MoveRecordings(path, NewPath);
+          if (!Error) {
+             Recordings->SetModified();
+             Modified = true;
+             }
+          StateKey.Remove(Modified);
+          }
      }
      if (Error) {
         Skins.Message(mtError, tr("Error while moving folder!"));
         return osContinue;
         }
      if (strcmp(folder, oldFolder))
         return osUserRecMoved;
      return osUserRecRenamed;

Die Lösung war hier das "LOCK_RECORDINGS_WRITE" durch das "if()" zu ersetzen. Seit dieser Änderung konnte ich keine LOCKS mehr feststellen und auch keine sonstigen negativen Auswirkungen. Mir ist aber auch noch nicht klar, ob das die Lösung ist oder nur ein workaround.

Ob sich das jetzt auf Deinen Fall anwenden lässt, kann ich nicht sagen.

Da sich ein vergleichbares Problem aber auch beim Plain-VDR zeigt, sollten wir hier vielleicht kls mit ins Boot holen, denn so ganz zufriedenstellend scheint der genannte commit im VDR-2.6.2 ja nicht zu sein.

Grüße

kamel5

kamel5: Danke für Deine Rückmeldung.

Fairerweise muss ich natürlich zugeben, dass mein VDR auch gepatched ist auch wenn ich denke, dass das alles vergleichsweise harmlose Patches sind die nicht in das Locking eingreifen wie z.B. der menu-selection-Patch.

Weil Du "Verschieben" genannt hast: da fällt mir ein, dass ich es auch schon einmal hatte beim Verschieben einer Aufnahme auf die zweite phys. Platte.

Bei mir hängt der VDR seit Version 2.6.2 auch beim Verschieben von Aufnahmen und es hilft nur ein Neustart.

Zitat von FireFly

auch wenn ich denke, dass das alles vergleichsweise harmlose Patches sind die nicht in das Locking eingreifen wie z.B. der menu-selection-Patch.

Ja, ich habe auch solche Patche drin, und konnte bisher keinen dieser Patche als Verursacher ausmachen.

Zitat von FireFly

Weil Du "Verschieben" genannt hast: da fällt mir ein, dass ich es auch schon einmal hatte beim Verschieben einer Aufnahme auf die zweite phys. Platte.

Stimmt, es muss ein extra Filesystem sein, sonst wird "cRecordingshandler" nicht benutzt.

Zitat von nasenbär

Bei mir hängt der VDR seit Version 2.6.2 auch beim Verschieben von Aufnahmen und es hilft nur ein Neustart.

Also doch ein größeres Problem.

Ich hatte schon mal überlegt, den genannten commit bei mir rückgängig zu machen (ich hatte vorher keinerlei Probleme), das bringt aber auch keine längerfristige Lösung.

Grüße

kamel5

Ich habe mal das recording.c von vanilla 2.6.1 und 2.6.3 verglichen:

# diff -y vdr-2.6.1/recording.c vdr-2.6.3/recording.c
....
void cRecordingsHandler::Action(void)                           void cRecordingsHandler::Action(void)
{                                                               {
  while (Running()) {                                             while (Running()) {
        bool Sleep = false;                                             bool Sleep = false;
        {                                                               {
          LOCK_RECORDINGS_WRITE;                              <
          Recordings->SetExplicitModify();                    <
          cMutexLock MutexLock(&mutex);                                   cMutexLock MutexLock(&mutex);
          if (cRecordingsHandlerEntry *r = operations.First()             if (cRecordingsHandlerEntry *r = operations.First()
             if (!r->Active(Recordings)) {                    |              if (!r->Active()) {
                error |= r->Error();                                            error |= r->Error();
                r->Cleanup(Recordings);                       |                 r->Cleanup();
                operations.Del(r);                                              operations.Del(r);
                }                                                               }
             else                                                            else
                Sleep = true;                                                   Sleep = true;
...

Da war ja vorher in cRecordingsHandler::Action() ein LOCK_RECORDINGS_WRITE vor dem &mutex drin !!

Das war zwar für das SetExplicitModify(), hat aber außerdem das Setzen der Mutexe in der falschen Reihenfolge verhindert!

Morgen werde ich das mal ausprobieren in der Hoffnung, dass es keine Nebenwirkungen hat ...

Das LOCK_RECORDINGS_WRITE dort wieder einzubauen, funktioniert so nicht einfach. Dann müsste auch wieder das LOCK_RECORDINGS_WRITE in cRecordingsHandlerEntry::Active() verschwinden, denn es kann, wie man so schön sagt "nur einen geben" Sonst gibt es wieder einen segfault.

Feb 08 13:01:44 vdr[256537]: [258859] WARNING: attempt to acquire write lock while already holding a write lock in the same thread - this may crash! (backtrace follows)
Feb 08 13:01:44 vdr[256537]: [258859] /usr/local/bin/vdr cStateLock::Lock(cStateKey&, bool, int) at thread.c:762
Feb 08 13:01:44 vdr[256537]: [258859] /usr/local/bin/vdr cListBase::Lock(cStateKey&, bool, int) const at tools.c:2183
Feb 08 13:01:44 vdr[256537]: [258859] /usr/local/bin/vdr cRecordings::GetRecordingsWrite(cStateKey&, int) at recording.h:276
Feb 08 13:01:44 vdr[256537]: [258859] /usr/local/bin/vdr cRecordings_Lock::cRecordings_Lock(bool) at recording.h:347 (discriminator 1)
Feb 08 13:01:44 vdr[256537]: [258859] /usr/local/bin/vdr cRecordingsHandlerEntry::Active() at recording.c:2096
Feb 08 13:01:44 vdr[256537]: [258859] /usr/local/bin/vdr cRecordingsHandler::Action() at recording.c:2193 (discriminator 1)
Feb 08 13:01:44 vdr[256537]: [258859] /usr/local/bin/vdr cThread::StartThread(cThread*) at thread.c:296
Feb 08 13:01:44 vdr[256537]: [258859] /lib64/libc.so.6 at ??:?
Feb 08 13:01:44 vdr[256537]: [258859] /lib64/libc.so.6 at :?
Feb 08 13:01:44 vdr[256537]: [258870] file copier thread started (pid=256537, tid=258870, prio=low)
Feb 08 13:01:44 systemd[1]: vdr.service: Main process exited, code=dumped, status=6/ABRT

Im Endeffekt würde das aber bedeuten, den ganzen commit rückgängig zu machen, oder auf eine andere Art und Weise die "Recordings" in cRecordingsHandlerEntry::Active() verfügbar zu machen.

Im Moment habe ich an dieser Stelle auch keine weiteren Ideen, da ich auch nicht weiß, warum dieser commit genau notwendig war.

Grüße

kamel5

Oh, ich dachte mehrfaches Locking wäre innerhalb eines Threads erlaubt.

Grund für den Fix war lt. GIT: Fixed a possible crash if an editing process is canceled while the edited recording is being replayed

Wo das dann gecrashed ist weiß ich aber auch nicht.

kamel5: Kannst Du den Patch auch mal installieren? Du konntest ja den Deadlock zuverlässiger reproduzieren als ich

Ja, habe ich gemacht und es sieht erst einmal wieder gut aus. Der ursprüngliche commit wurde ja reverted, damit sollten alle damit verbundenen Probleme beseitigt sein.

Ich werde das aber weiter beobachten.

Grüße

kamel5

Ich habe das auch schnell mal getestet. Mit dem Patch vdr-2.6.3-fix-deadlock.diff klappt bei mir das Verschieben von Aufnahmen wieder.

Ich nutzte Yavdr. Hat sonst keiner das Problem oder verschiebt niemand Aufnahmen?

Zitat von nasenbär

Hat sonst keiner das Problem oder verschiebt niemand Aufnahmen?

Naja, das Problem tritt nur unter bestimmten Randbedingungen auf:

- Verschieben auf ein anderes Dateisystem

- Verschieben eines Ordners mit mehreren Aufnahmen

Damit der Fehler auftritt muss der cRecordingsHandler benutzt werden und das ist nicht immer der Fall.

Also schon möglich, das es sonst keinem aufgefallen ist.

Grüße

kamel5

Ich hatte es auch einmal beim Verschieben auf eine andere Partition, aber ansonsten nur manchmal beim Schneiden. Zusätzlich muss ja das Menü offen sein und auch dann tritt es nur sporadisch auf.

Zitat von kamel5

Naja, das Problem tritt nur unter bestimmten Randbedingungen auf:

- Verschieben auf ein anderes Dateisystem

- Verschieben eines Ordners mit mehreren Aufnahmen

Damit der Fehler auftritt muss der cRecordingsHandler benutzt werden und das ist nicht immer der Fall.

Also schon möglich, das es sonst keinem aufgefallen ist.

Alles anzeigen

Ich verschiebe relativ häufig Aufnahmen auf meine Archivplatte. Ja, es gab Abstürze bei mir.

Schneide und verschiebe meist gleich danach, hätte vor längerer Zeit mal einen Beitrag zu dem crash verfasst.
Kann aber sein das ich auf dem Holzweg bin.