vdrnfofs mit Python 3

  • Löschen klingt "interessant", da ja eigentlich nicht existierende Dateien "behandelt" werden sollen :)

    --
    vdr User #2022 - hdvdr2: Lenovo SFF M83, Intel(R) Core(TM) i5-4670S, 12 GB Ram, zram-swap/tmp, ubuntu-focal, softhddevice-vdpau
    ddbridge-6.x mit 2xDVB-S2 und (Flex) 2xDVB-C/T Tunern, nvidia-GF720 SFF passiv (nvidia-dkms-465.24), System SSD btrfs,

    snapper, 8TB HDD XFS/cow /srv/vdr, yavdr-ansible-2.5.3-seahawk, vdr-epg-daemon mit Frodo-plugins, Kernel 5.12.1

    vdradmin-am, live+webstreaming, vdrmanager (Smartphones als FB), ffmpeg-4.3.1-libfdk_aac, vdr-plugin-hbbtv. Folding@home läuft auf CPU.

  • Die sind ja nicht "nicht existierend" sondern haben eine reale Aufnahme dahinter.


    Beim Löschversuch der ".nfo" könnte ich mir vorstellen einfach Erfolg zu simulieren damit das Betriebssystem keine Fehler wirft.


    Beim Löschversuch der ".mpg" müsste man dann via SVDRP ermitteln welche Aufnahme an diesem Pfad hängt um die sauber via "DELR" zu löschen. Faktisch entfernt das natürlich dann ".nfo" und ".mpg" gleichzeitig.


    Aber erstmal nur ein Gedankenexperiment. Noch habe ich gar nicht versucht wie gut man von einer "LSTR"-Ausgabe auf die Pfade schließen kann und ohne das geht das geplante sowieso nicht.

  • Kannst du das als Pull-Request für python-fuse einstellen?

    https://github.com/libfuse/python-fuse/pull/28

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Das ging ja erfreulich schnell: https://github.com/libfuse/python-fuse/commits/master - ich habe python-fuse bei den Arch Linux Pakten mal als out-of-date geflagged.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Hätten die drei Zeilen nicht wegbleiben können?

    Ja, das ist ein Überbleibsel von einem früheren Versuch, bei dem ich zwischendrin noch einen NULL-Pointer Check machen und dabei eine Exception werfen können wollte.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Dauert bei Arch wohl mal wieder länger :cursing:


    Ich glaube übergangsweise baue ich das bei vdr4arch mit rein. Weil das vdr4arch-Repo üblicherweise als letztes eingetragen werden sollte muss jeder, der auf das Problem mit den Zeichensätzen läuft, dann halt explizit die Version aus dem vdr4arch-Repo installieren. Das fliegt dann wieder raus sobald es bei Arch aktuell ist und ins AUR kann ich damit auch nicht.


    Zum Thema "löschen" hab ich auch bisschen recherchiert. Ich halte das mittlerweile für ziemlich sicher machbar. Frage ist nur was Windows da ggf. draus macht. Ich habe zwei Dateien die beide auf eine Aufnahme zeigen. Wenn ich beim Löschen der ".nfo" oder der ".mpg" jeweils direkt die Aufnahme entsorge und damit die zweite Datei auch weg ist, dann gibt das ziemlich sicher eine Fehlermeldung (eigentlich zu löschende Datei ist ja dann schon weg).


    Ich würde also beim Löschen der ".nfo" jeweils das Löschen nur "faken" ("Erfolg zurückmelden"). Ein "F5" und die Datei wäre also wieder da. Löschen der ".mpg" allerdings würde via SVDRP an den VDR als "DELR" laufen.


    Das würde dann fehlschlagen wenn Windows beim Löschen einer Datei danach nochmal "gegenprüft". Die ".nfo" wird eben nie gelöscht während das Löschen der ".mpg" beides weghaut.


    Oder aber ich binde ".mpg" fest an die Aufnahme und mache die ".nfo" generell "schreibgeschützt". Diese Lösung wäre weniger "hacky", setzt aber voraus das beim Löschen einer Aufnahme die ".nfo" nicht "mitmarkiert" wird. Sonst gibt's dann wieder Fehlermeldungen. Wird eine ".mpg" gelöscht verschwindet die ".nfo" dann automatisch mit.


    Meinungen?

  • eine "ro" Option für die nicht wollen das man löschen kann ??

    Zum Guggen: yavdr0.6 + Silverstone GD04 + Intel DH57DD + Intel G6950 + Nvidia GT630 + Unicable/Jess-Sat (JPS0501-12) mit DD/L4M Max8 + 4TB WD-red + bequiet SFX300W
    Zum Testen : yavdr-Ansible + GMC Toast + B365M+i3-8100+ Nvidia GT1030 + L4M CineS2v6 o. SAT>IP Plugin mit DD-O'net
    VaaS (VDR-as-a-Service): yavdr06 + ML03+DH67BL+G530+2GB RAM + 2TB WD-EARX + Zotac GT610 + L4M v5.4 + bequiet SFX300W
    Squeezeboxserver: DN2800ML im Streacom F1CS NAS: HP ProLiant MicroServer NL36+ Smart Array P212

  • Ich weiss nicht, ob ich das Tool ohne ro einsetzen möchte ...


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • Ich weiss nicht, ob ich das Tool ohne ro einsetzen möchte ...

    Das ist ja erstmal jedem selber überlassen.


    Das Löschen über SVDRP wird ohnehin ein optionales Feature das standardmäßig nicht aktiv ist, denn es funktioniert nur wenn vdrnfofs auf der gleichen Maschine läuft wie der VDR-Dienst selbst. Außerdem gehe ich davon aus das es da anfangs noch reichlich Inkompatibilitäten geben wird bis wirklich mal Pfad zu Aufnahme 100%ig sauber matcht. Wenn das Feature nicht beim Mounten mit aktiviert wird, dann verhält sich vdrnfofs wie jetzt auch. Und wer das noch sauber haben will sollte beim Mounten dann noch "ro" als Parameter mitgeben das der Kernel direkt einen Fehler "Readonly Filesystem" werfen kann.


    Für mich wäre es aber endlich mal eine Möglichkeit eine Aufnahme vom VDR runterzubekommen ohne den VDR alle Aufnahmen neu einlesen zu lassen. Ich könnte mir Aufnahmen dann auf den Desktoprechner verschieben die ich schneiden will und nach dem Schneiden als MKV ablegen. Oder eine Aufnahme direkt über den SFTP-Mount anschauen und nach dem Schauen ggf. direkt löschen ohne nochmal am VDR zu fummeln. Und vor allem entscheidet der VDR selbst ob die Aufnahme gelöscht werden darf. Wenn über SVDRP kein Löschen möglich ist, dann geht das natürlich als Fehler zum "Anfragenden" zurück.


    Es würde meinem normalen "VDR-Betrieb" einfach viel besser entsprechen, denn die paar Aufnahmen die ich tatsächlich behalte schneide ich am Desktop und lege sie dann so ab das Kodi da sauber Metadaten aus dem Internet nachladen kann. Was "dauerhaft behalten wird" bleibt bei mir nie als VDR-Aufnahme stehen. Und ich kenne mindestens einen weiteren VDR-Nutzer der genau das gleiche benötigt.


    Es beschränkt sich dabei natürlich rein auf Löschen und damit auch Verschieben (was ja im Prinzip auch nur ein Kopieren mit nachfolgendem Löschen ist). Man bekommt Aufnahmen so runter aber keinesfalls drauf.

  • Würdest Du physisch löschen. oder nach .del renamen.


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • Wie schon geschrieben: Ich würde selber gar nicht löschen.


    Mein Ziel ist es mit dem Pfad zur Aufnahme (der ist vdrnfofs ja bekannt) über das SVDRP-Kommando "LSTR" auf die "VDR-Interne Aufnahme-ID" zu matchen und wenn das gelingt dem VDR via "DELR" SVDRP-Kommando mitzuteilen das eben diese ID gelöscht werden soll. Der VDR entscheidet dann ob gelöscht werden kann und wenn ja löscht der VDR (wird dann wohl erstmal nach ".del" umbenennen).


    Heißt im Umkehrschluss eben auch: Wenn der VDR-Dienst nicht läuft oder der SVDRP-Zugriff aus anderem Grund fehlschlägt, dann schlägt auch jeder Löschvorgang fehl.

  • Ich hatte in meinem Patch für python-fuse aus Versehen einen Memory-Leak eingebaut, weil ich übersehen habe ein temporäres Objekt wieder zu dekrementieren - zum Glück hat da jemand genau hingesehen: https://github.com/libfuse/python-fuse/pull/36

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    The post was edited 1 time, last by seahawk1986 ().