Doppelpunkte in Dateinamen

  • Hallo,

    immer wieder werden durch das Schema F Doppelpunkte im Aufnahmenamen verwendet, die dann dafür sorgen, dass ich die Datei über die NFS-Freigabe nicht vernünftig schneiden kann.

    Beispiel:

    MacGyver: Jagd nach dem Schatz von Atlantis~2024.05.18-18:20-Sat

    (da sind sogar zwei drin; kommt von epgsearch eine geplante Serienaufnahme, obwohl es einer der beiden Filme ist, aber egal, ist ja nur ein Beispiel).

    Natürlich schaut der Dateiname korrekt aus, er wird mit #3A umschrieben.


    Gibt es eine Möglichkeit, wie man das generell unterbindet oder was muss ich genau tun, damit ich korrekt schneiden kann (mit Skript)?

    Mein Skript (aus dem Forum, bereits leicht angepasst) könnte ich anhängen, wenn gewünscht. Mir wäre es eigentlich lieber, wenn solche kritischen Zeichen gar nicht erst ins Dateisystem kämen (weil man den Terz mit anderen System bekommt).


    Einmal editiert, zuletzt von cduerr ()

  • Danke Dir, habe ich mir angeguckt und feststellen müssen, dass ich das schon habe (Zeile 10):

    Das Verhalten mit Doppelpunkten tritt also trotz --vfat auf.

    3 Mal editiert, zuletzt von cduerr ()

  • --dirnames=,,1 schaltet schon das Encoding von Sonderzeichen an - mit --vfat gibt es zusätzlich noch eine Längenbeschränkung für Datei- und Ordnernamen (das entspräche --dirnames=250,40,1, was man nicht unbedingt haben will).


    Aber irgendwie komme ich da noch nicht ganz mit - über NFS sind Sonderzeichen wie Doppelpunkte normalerweise kein Problem, die Beschränkung hat eigentlich nur Windows (und Samba ohne Unix-Extensions).

    Natürlich schaut der Dateiname korrekt aus, er wird mit #3A umschrieben.

    Die vom VDR erstellten Dateien enthalten eigentlich keine Sonderzeichen, nur die Ordnernamen - aber wenn der Doppelpunkt durch seinen Hex-Wert #3A ersetzt wird, scheint das Encoding von Seite des VDR aus zu funktionieren.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • ich habe bisher nur die Serverseite betrachtet. Es gibt zwar Samba- und NFS-Freigabe, aber die Dateinamen tauchen schon auf dem Server auf (SSH).

  • Das sollte dann zu einem Pfad wie /srv/vdr/video/Pirates_of_the_Caribbean#3A_Salazars_Rache/2021-02-01.01.00.9-0.rec für eine Aufnahme führen - mir ist noch nicht ganz klar, wieso das zu Problemen beim Schneiden führt.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Normalerweise kann man ja mit der Fernbedienung Taste 2 auch ein lokales Schneiden auf dem Client starten. Das bedeutet, dass es wahnsinnig lange dauert - die Videodaten müssen ja mindestens zweimal übertragen werden. Beim Druck auf die Taste 2 wird bei mir seit kurzem nur die Lautstärke reduziert. Vielleicht hat das mit der alternden Fernbedienung zu tun, aber ich hatte ja darüber berichtet, eigentlich war dann alles wieder gut.


    Anyway, ich würde ohnehin das Schneiden auf dem Server bevorzugen. Erstens, weil das schneller ist, weil er nicht übers Netzwerk transferieren muss. Zweitens, weil das unempfindlicher gegenüber Abstürzen ist. Drittens, weil das in einer Queue auf dem Server landet, der sich darum besser kümmern kann und ich derweil auch andere Sachen machen kann.


    Hier ist das Skript aus dem Forum. Ich glaube, der kümmert sich nicht um die Normalisierung solcher Sonderzeichen in UTF8, wie man das bräuchte - sonst ist es super. Als Workaround benenne ich kritische Dateien um, mache ein "touch .update" im /srv/vdr/video" und probiere es erneut. Frei nach dem Motto "Computer lösen Probleme, die man ohne sie gar nicht erst hätte!" :) - wäre es doch schön, wenn das Skript das automagisch miterledigen könnte. $RECNAME müsste es sein, wenn ich mich nicht irre.

  • Dann scheitert es daran, dass kein Unescaping im Skript stattfindet und du den von svdrpsend lstr zurückgegeben Namen mit dem Pfad vergleichst - man könnte da drum herum arbeiten, indem man den VDR um den Pfad der Aufnahmen der Kandidaten bittet (svdrpsend lstr $REC_ID path) und die Ordnerstruktur rückwärts vergleicht - grob könnte das so aussehen:


    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

Jetzt mitmachen!

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