VDR version 2.7.5 freigegeben

Quote from kls

Würde vielleicht ein UpdateByName() auch genügen (mit dem Patch aus #25)?

Ich hab's ausprobiert mit

  if ((Usage() & ruPending) != 0) {
     if ((Usage() & ruCut) != 0) {
        cutter = new cCutter(FileNameSrc());
        cutter->Start();
        //Recordings->DelByName(FileNameDst());
        Recordings->AddByName(FileNameDst(), false);
        Recordings->UpdateByName(FileNameDst());
        }

was aber leider gar keinen Effekt hat da UpdateByName() an cRecordingInfo::Read() durchgereicht wird, es müsste aber in cRecording numFrames auf -1 eigesetzt werden, was nur im Konstruktor passiert.

Irgendwie bin ich skeptisch, ob der Patch nicht weitreichendere Auswirkungen hat, da das UpdateByName() ja an mehreren Stellen benutzt wird. Aber bisher hat das erste Schneiden und Überschreiben beim zweiten Schneiden problemlos geklappt.

kls , FireFly ,

wäre es nicht besser, das "Recordings->UpdateByName(FileNameDst());" für das cutting in "cRecordingsHandlerEntry::Active" nur dann aufzurufen, wenn kein Fehler aufgetreten ist? Also unter "// We're done:". Unter "// Now check if there is something to start:" wird es ja erst einmal nur gestartet.

Anbei mal ein entsprechender Patch.

Grüße
kamel5

So wie ich den Patch verstehe würde er nichts beim ersten Schneiden verändern, aber beim Überschreiben einer Aufnahme (zweiter Schnitt) die Fehler und Dauer erst am Ende aktualisieren. Da würde die Anzeige dann "plötzlich" umspringen, oder? Warum sollte man das beschränken und anders behandeln als beim Aufnehmen oder dem ersten Schnitt?

Quote from FireFly

So wie ich den Patch verstehe würde er nichts beim ersten Schneiden verändern, aber beim Überschreiben einer Aufnahme (zweiter Schnitt) die Fehler und Dauer erst am Ende aktualisieren. Da würde die Anzeige dann "plötzlich" umspringen, oder?

Ja.

Quote from FireFly

Warum sollte man das beschränken und anders behandeln als beim Aufnehmen oder dem ersten Schnitt?

Das wird ja beim ersten Schnitt auch nicht anders behandelt. Wenn man das direkt hinter "cutter->Start();" einfügt, wird es ja auch nur einmalig am Anfang des Schnittes aufgerufen und da ist das endgültige "numFrames" noch nicht bekannt. Ich wüsste jetzt nicht, das es im Plain-VDR beim Cut zwischendurch aktualisiert wird. Ich kann es leider hier selbst momentan nicht testen.

Im Endeffekt scheint mir hier Deine Lösung aus #40 fast die bessere Wahl.

Grüße
kamel5

Quote from kamel5

Ich wüsste jetzt nicht, das es im Plain-VDR beim Cut zwischendurch aktualisiert wird.

Ja, wird es aber solange der Schnitt oder die Aufnahme noch läuft, da in dieser Zeit numFrames = -1 ist und erst am Ende des Schnitt bzw.Aufnahme der endgültige Wert gesetzt wird.

Quote from FireFly

Ja, wird es aber solange der Schnitt oder die Aufnahme noch läuft, da in dieser Zeit numFrames = -1 ist und erst am Ende des Schnitt bzw.Aufnahme der endgültige Wert gesetzt wird.

Stimmt, das konnte ich jetzt nachvollziehen.

Wenn man über das Ganze nachdenkt, wird es ja nur dadurch nicht richtig gemacht, weil bei "cRecordings::AddByName" das beim zweiten mal ignoriert wird. Im Endeffekt würde es ja reichen, dort einen "else" - Fall aufzumachen und das "UpdateByName" dort unterzubringen.

Im Anhang mal einen Patch dazu.

Grüßr
kamel5

Hi,

irgendwie hab ich den Überblick verloren:
Gibt es einen Patch für skincurses?
Wenn ich den anwende, der hier gepostet wurde, übersetzt es zwar, aber ich bekomme:

/usr/lib/vdr/libvdr-skincurses.so.7: undefined symbol: _ZN24cSkinCursesDisplayTracks15SetAudioChannelEi

Zusatzfrage: Warum startet VDR die alphabetisch nach einem Plugin (hier skincurses) gelegenen Plugins (hier tvscraper ...) nicht mehr, wenn ein Plugin so einen Fehler bringt?
Das ist schon seit langem so, aber trotzdem etwas unschön, zumal ich skincurses zwar übersetze, aber überhaupt nicht lade.

Quote from nobanzai

Zusatzfrage: Warum startet VDR die alphabetisch nach einem Plugin (hier skincurses) gelegenen Plugins (hier tvscraper ...) nicht mehr, wenn ein Plugin so einen Fehler bringt?

Damit das nicht passiert, verwende ich schon seit Jahren folgenden Patch:

• Resilience upon plugins that cannot be loaded.patch.txt

Eventuell könnte kls das in den VDR übernehmen und beide Verhaltensweisen (ähnlich dem Emergency Exit) konfigurierbar gestalten.

Quote from nobanzai

Hi,

irgendwie hab ich den Überblick verloren:
Gibt es einen Patch für skincurses?
Wenn ich den anwende, der hier gepostet wurde, übersetzt es zwar, aber ich bekomme:

Code

/usr/lib/vdr/libvdr-skincurses.so.7: undefined symbol: _ZN24cSkinCursesDisplayTracks15SetAudioChannelEi

Hast du die "includes" (die Header) des VDR mit der neuen Version auch frisch an die entsprechende(n) Stelle(n) kopiert?

Habe öfters bei anderen Plugins ähnliche "undefined symbol"-Meldungen und die kamen dann immer genau davon. Also, dass veraltete Header-Dateien in "/usr/local/include/vdr/" oder "/usr/include/vdr/" bzw. "/usr/local/include/libsi/" oder "/usr/include/libsi/" lagen.

Quote from theonlychriss

Hast du die "includes" (die Header) des VDR mit der neuen Version auch frisch an die entsprechende(n) Stelle(n) kopiert?

Habe öfters bei anderen Plugins ähnliche "undefined symbol"-Meldungen und die kamen dann immer genau davon. Also, dass veraltete Header-Dateien in "/usr/local/include/vdr/" oder "/usr/include/vdr/" bzw. "/usr/local/include/libsi/" oder "/usr/include/libsi/" lagen.

Versteh ich nicht, was haben die Includes denn damit zu tun?
Ich hol das per git und mach einen make. Da kopiert man doch nix manuell?!?

Quote from nobanzai

Versteh ich nicht, was haben die Includes denn damit zu tun?
Ich hol das per git und mach einen make. Da kopiert man doch nix manuell?!?

Klar, ich hole mir den Code auch via git und führe ein make aus, aber:
Ich führe nie ein "make install" aus, bei dem die (neuen) Header an die richtigen Stellen kopiert werden, sondern kopiere die paar Dateien, die nach dem Kompilieren entstehen, immer manuell. Das hat halt den Nachteil, dass die Header eben nicht automatisch kopiert werden.

Falls du das auch so machst oder aus versehen jetzt einmal so gemacht hattest, könnte es das sein.
Ist ja nur meine Erfahrung/Beobachtung bei meinen unresolved symbols.

Viele Grüße,
Chriss

nobanzai .dependencies vor dem compilieren gelöscht?

Quote from FireFly

nobanzai .dependencies vor dem compilieren gelöscht?

Ich mach immer einen make clean - wenn der das richtig macht, ist die Antwort "ja".

Quote from theonlychriss

Klar, ich hole mir den Code auch via git und führe ein make aus, aber:
Ich führe nie ein "make install" aus, bei dem die (neuen) Header an die richtigen Stellen kopiert werden, sondern kopiere die paar Dateien, die nach dem Kompilieren entstehen, immer manuell. Das hat halt den Nachteil, dass die Header eben nicht automatisch kopiert werden.

Falls du das auch so machst oder aus versehen jetzt einmal so gemacht hattest, könnte es das sein.
Ist ja nur meine Erfahrung/Beobachtung bei meinen unresolved symbols.

Viele Grüße,
Chriss

Ok, jetzt hab ich dich verstanden.
Aber nein, ich kopiere nix manuell.