[gelöst] vdr-plugin-live - Bug? - Verlust von Aufnahmen

    Folgendes Problem ist mir aufgefallen:


    angenommen, man schneidet eine vormals geschnitten Aufnahme mit Namen %***.... noch einmal, so entsteht die Aufnahme %%***...

    Löscht man jetzt das Original und nennt umgehend die geschnittene Aufnahme in den gleichen Namen um, wie die eben gelöschte Aufnahme, dann verliert man auch die zuletzt geschnittene Aufnahme.


    Test-Szenarium (löschen und umbenennen unter live) :

    1. Man nehme eine Test-Aufnahme und kopiere diese ein zweites Mal in das Verzeichnis mit z.B. Vorangestellter "1"
    2. Nun lösche man die Aufnahme ohne die vorangestellte "1"
    3. Jetzt die Aufnahme mit vorangestellter "1" umbenennen und die "1" entfernen
    4. Jetzt sollten beide Aufnahmen verschwunden sein.

    In dem Fall wurde die umbenannte Aufnahme in das Unterverzeichnis ****.del verschoben und durch VDR gelöscht.


    Der Versuch, das Verhalten mit VDR am OSD nachzustellen erzeugte zu dem ****.del Verzeichnis zusätzlich ein ****.rec Verzeichnis und führte nicht zum Verlust der Aufnahme.


    Kann dieses Verhalten jemand nachvollziehen?

    (in der Hoffnung, ich habe es verständlich beschrieben...)



    Achso, hier tntnet 3.0 im Einsatz, denke aber, dass es damit nichts zu tun hat.

    Gentoo Linux ~ VDR 2.6.6 ~ DD Octopus NET V2 S2 Max - SAT>IP ~ LENOVO ThinkServer TS200V ~ Intel(R) Core(TM) i5 CPU680@3.60GHz ~ 16GB RAM ~ NVIDIA T400

    Einmal editiert, zuletzt von heifisch ()

    Zitat von heifisch

    Achso, hier tntnet 3.0 im Einsatz, denke aber, dass es damit nichts zu tun hat.

    Da muss ich dir widersprechen: Unter tntnet 2.1 ist das Problem nicht, unter tntnet 3.0 geht das Kopieren schon nicht, damit ist nach dem Löschen des Original beides weg. Ich schaue mir das mal morgen an.

    Gefällt mir 1

    Ich habe mir das mal angeschaut, es gibt sogar zwei Probleme:

    1. unter tntnet 3.0 funktionieren die Checkboxen in edit_recording nicht, somit u.a keine Funktion, um eine Aufnahme zu kopieren. Fix ist bei MarkusE hier im git. heifisch: bitte testen.


    2. Das von dir beschriebene Problem tritt entgegen meiner obigen Aussage auch unter tntnet 2.1 auf, selten geht es aber auch. Scheint ein timing Problem zu sein. Hier habe ich noch keine Idee, an was das liegen könnte. MarkusE : bitte schaue auch mal rein, ob du dafür eine Ursache sehen kannst.

    Zitat von kfb77

    1. unter tntnet 3.0 funktionieren die Checkboxen in edit_recording nicht, somit u.a keine Funktion, um eine Aufnahme zu kopieren. Fix ist bei MarkusE hier im git. heifisch: bitte testen.


    Kopieren von Aufnahmen funktioniert jetzt bei mir unter tntnet 3.0.


    Zitat von kfb77

    2. Das von dir beschriebene Problem tritt entgegen meiner obigen Aussage auch unter tntnet 2.1 auf, selten geht es aber auch. Scheint ein timing Problem zu sein. Hier habe ich noch keine Idee, an was das liegen könnte. MarkusE : bitte schaue auch mal rein, ob du dafür eine Ursache sehen kannst.


    Ich glaube, das Problem tritt so lange auf, bis VDR die zum löschen gekennzeichnete Aufnahme entsorgt hat.

    Ich habe jetzt extra mal ein wenig länger gewartet.

    Gentoo Linux ~ VDR 2.6.6 ~ DD Octopus NET V2 S2 Max - SAT>IP ~ LENOVO ThinkServer TS200V ~ Intel(R) Core(TM) i5 CPU680@3.60GHz ~ 16GB RAM ~ NVIDIA T400

    Das VDR Log vom rename direkt nach dem delete über Live bestätigt genau das, was wirklich passiert: Umbenennen der Aufnahme (1ARD-Buffet -> ARD-Buffet) entfernen der vorher gelöschten Aufnahme (*.del) und dann fälschlicherweise auch das löschen der umbenannten Aufnahme. Ich suche noch ...

    Ich habe es gefunden: In deiner Konstellation gibt es nach dem rename einen redirect auf den delete. Damit ist die Aufnahme weg.

    Was der redirect in einer anderen Konstellation möglicherwiese für einen Sinn hat, konnte ich nicht raus bekommen. Wenn man ihn raus nimmt, funktioniert es. Getestet mit tntnet 2.1 und tntnet 3.0.

    Fix ist hier, bitte ausgiebig alle Funktionen von Live testen bevor MarkusE das übernimmt. Vielleicht habe ich noch was übersehen, wofür es diesen redirect im Code gibt.

    Gefällt mir 2

    Das Umbenennen in der Konstellation funktioniert jetzt. Danke!


    Allerdings ist mir eine weitere Ungereimtheit aufgefallen:

    Angenommen ich habe 2 identische Aufnahmen "ARD-Buffet" und "1ARD-Buffet".


    Wenn ich jetzt "1ARD-Buffet" in "ARD-Buffet" umbenenne, verliere ich eine Aufnahmen.

    In dem Fall wäre es ja nicht so schlimm, weil diese ja identisch sind.

    Aber wenn das mal nicht der Fall wäre (man hat hinten was weg geschnitten), würde man ohne Vorwarnung eine Aufnahme verlieren.


    Wie wird die Eindeutigkeit der Aufnahmen erzeugt?

    Wird das aus dem Verzeichnispfad (Name und Anfangszeit) gemacht?


    z.B.


    Star_Trek\:_Discovery/%Leuchtfeuer/2022-03-15.23.36.7-0.rec

    Star_Trek\:_Discovery/%1Leuchtfeuer/2022-03-15.23.36.7-0.rec


    Das Umbenennen von %1Leuchtfeuer in %Leuchtfeuer würde dann wieder den gleichen Pfad erzeugen.

    Wozu ist die 0 vor dem .rec?

    Sollte da etwas hoch gezählt werden oder gehört das noch zum Zeitstempel?

    Ich habe im Quelltext von Live bezüglich Aufnahmen etwas von md5hash gesehen, konnte aber auf die Schnelle nicht erkennen, aus was der hash gebildet wird.

    Zu eindeutigen Aufnahmen führt das derzeit jedenfalls nicht.

    Gentoo Linux ~ VDR 2.6.6 ~ DD Octopus NET V2 S2 Max - SAT>IP ~ LENOVO ThinkServer TS200V ~ Intel(R) Core(TM) i5 CPU680@3.60GHz ~ 16GB RAM ~ NVIDIA T400

    Zitat von heifisch

    Wenn ich jetzt "1ARD-Buffet" in "ARD-Buffet" umbenenne, verliere ich eine Aufnahmen.

    Ja klar, das ist genau das, was im Filesystem auch passiert.

    Mit "mv 1ARD-Buffet ARD-Buffet" ist auch 1ARD-Buffet weg, egal, ob es gleich war, oder nicht.


    Zitat von heifisch

    Wozu ist die 0 vor dem .rec?

    Das ist die VDR Instance, default ist 0.

    Code
    -i instance, --instance=instance
Use instance as the id of this VDR instance (default is 0). In an environment where several instances of VDR use the same video directory, this parameter can be set to a positive integer value that's unique for each instance, so that they won't interfere with each other in case they record exactly the same broadcast. The number given here will be part of the directory name in which the recordings will be stored.

    Damit verschiedene Namen garantiert sind wenn mehrere VDRs auf den gleichen Storage schreiben.

    Zitat von kfb77

    Ja klar, das ist genau das, was im Filesystem auch passiert.

    Mit "mv 1ARD-Buffet ARD-Buffet" ist auch 1ARD-Buffet weg, egal, ob es gleich war, oder nicht.


    Klar, aber sollte sich ein GUI so verhalten?


    VDR am OSD lässt dieses Verhalten nicht zu!

    Da kommt "Fehler beim Ändern des Ordners oder Namens!"


    Zitat von kfb77

    Das ist die VDR Instance, default ist 0.

    Code
    -i instance, --instance=instance
...

    Damit verschiedene Namen garantiert sind wenn mehrere VDRs auf den gleichen Storage schreiben.


    Danke für die Aufklärung.


    Gentoo Linux ~ VDR 2.6.6 ~ DD Octopus NET V2 S2 Max - SAT>IP ~ LENOVO ThinkServer TS200V ~ Intel(R) Core(TM) i5 CPU680@3.60GHz ~ 16GB RAM ~ NVIDIA T400

    Zitat von heifisch

    Klar, aber sollte sich ein GUI so verhalten?

    Nein, nicht unbedingt, da gebe ich dir Recht. Das ist aber kein Bug, sondern ein Feature Request mit html Anteil. Und das fasse ich mangels KnowHow nicht an.

    Zitat von kfb77

    Ja klar, das ist genau das, was im Filesystem auch passiert.

    Mit "mv 1ARD-Buffet ARD-Buffet" ist auch 1ARD-Buffet weg, egal, ob es gleich war, oder nicht.

    Das stimmt so nicht ganz.

    Wenn das beides reguläre Dateien sind, dann ist das so. Wenn das aber, wie beim VDR, Verzeichnisse sind, dann wird in diesem Fall "1ARD-Buffet" in das Verzeichnis "ARD-Buffet" verschoben und nicht gelöscht.


    Grüße

    kamel5

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.8 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

    Ich habe schon was gefunden in tools.cpp:



    Zeile 21 (im obigen Ausschnitt):

    Offensichtlich wird ohne Rücksicht auf Verluste target.c_str() gelöscht.

    Wenn ich folgende Zeile auskommentiere:


    Code
    //                      RemoveFileOrDir(target.c_str());


    bekomme ich wie erwartet, die Fehlermeldung:


    Konnte die Aufnahme nicht umbenennen oder verschieben.


    Da stellt sich mir die Frage, warum das vorherige Löschen des Zielverzeichnis erforderlich war?

    Zitat von kamel5

    dann wird in diesem Fall "1ARD-Buffet" in das Verzeichnis "ARD-Buffet" verschoben und nicht gelöscht.

    Was aber im Falle vom VDR meist das gleiche ist, weil ja die Dateinamen gleich sind. Höchstens mehr/weniger *.ts Files.


    heifisch : Und genau in so einem Fall würde deine Änderung ein unbeabsichtigtes Ergebnis erzeugen: Wenn der originale Inhalt des Verzeichnises mehr ts Files hat, würden die mit den höheren Nummer stehen bleiben und nicht zur neuen Aufnahme passen.


    Edit: Stimmt nicht, der move wird ja nicht gemacht, weil er auf einen Fehler läuft. Müsste funktionieren. Mal sehen, was MarkusE dazu meint.

    Einmal editiert, zuletzt von kfb77 ()

    Gefällt mir 1
    Zitat von kfb77

    heifisch : Und genau in so einem Fall würde deine Änderung ein unbeabsichtigtes Ergebnis erzeugen: Wenn der originale Inhalt des Verzeichnises mehr ts Files hat, würden die mit den höheren Nummer stehen bleiben und nicht zur neuen Aufnahme passen.


    Nein, das passiert gerade eben nicht!

    Das Umbenennen wird abgebrochen mit o.g. Fehlermeldung.

    Das wäre genau das Verhalten, wie auch unter VDR OSD.


    Die Funktion MoveDirectory wird auch nur einmal im Code verwendet in recman.cpp:



    Code
    vdr /usr/local/src/vdr-plugin-live # grep -Ri MoveDirectory
recman.cpp:             if (!MoveDirectory(oldname.c_str(), newname.c_str(), copy)) {
tools.cpp:      bool MoveDirectory(std::string const & sourceDir, std::string const & targetDir, bool copy)
tools.h:        bool MoveDirectory(std::string const & sourceDir, std::string const & targetDir, bool copy = false);


    Das Auskommentieren sollte dann auch keine unvorhersehbaren Effekte haben.


    Was die Motivation vom Autor war, bei einem rename das Ziel ohne Rückfragen zu löschen erschließt sich mir nicht.

    Gentoo Linux ~ VDR 2.6.6 ~ DD Octopus NET V2 S2 Max - SAT>IP ~ LENOVO ThinkServer TS200V ~ Intel(R) Core(TM) i5 CPU680@3.60GHz ~ 16GB RAM ~ NVIDIA T400

    Gefällt mir 1
    Zitat von kfb77

    Was aber im Falle vom VDR meist das gleiche ist, weil ja die Dateinamen gleich sind. Höchstens mehr/weniger *.ts Files.

    Nein.


    VDR-Intern funktioniert das so, um bei Eurem Beispiel zu bleiben:

    Star_Trek\:_Discovery/%Leuchtfeuer/2022-03-15.23.36.7-0.rec

    Star_Trek\:_Discovery/%1Leuchtfeuer/2022-03-15.23.36.7-0.rec


    Wenn Du im Filesystem verschiebst:

    mv Star_Trek\:_Discovery/%1Leuchtfeuer Star_Trek\:_Discovery/%Leuchtfeuer


    entsteht daraus das:

    Star_Trek\:_Discovery/%Leuchtfeuer/2022-03-15.23.36.7-0.rec

    Star_Trek\:_Discovery/%Leuchtfeuer/%1Leuchtfeuer/2022-03-15.23.36.7-0.rec


    Nach Neueinlesen der Aufzeichnungen im VDR gibt es dann im Ordner Star_Trek\:_Discovery eine Aufnahme mit dem Namen:

    %Leuchtfeuer

    und ein Verzeichnis mit dem gleichen Namen, und darin befindet sich eine weitere Aufnahme mit dem Namen:

    %1Leuchtfeuer


    Beide Aufnahmen sind unabhängig.


    Grüße

    kamel5

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.8 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

    Du hast Recht, das Beispiel war "quick and dirty".

    Der move sieht auch so aus (andere Aufnahme):

    Code
    mv 1Der_Alte/2022-03-25.20.13.2-7.rec/* Der_Alte/2022-03-25.20.13.2-7.rec/

    Es sind zwei Probleme und zwei Lösungen:

    Im "copy" Branch ist der Bug behoben, dass mit tntnet 3.0 das Kopieren einer Aufnahme nicht funktioniert.

    Um das ungewollte Überschreiben von bestehenden Aufnahmen beim Rename zu verhindern (egal welches tntnet), braucht es zusätzlich noch das.

    Gefällt mir 1

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden