Posts by kamel5

  • 1 TB Speicher für einen Raspberry Pi 2 - USB-Stick oder SSD kaufen?

    Ich habe bisher auch Sticks an meinen Raspis gehabt, war mit der Performance aber nie so recht im Dauerbetrieb zufrieden. Nachdem jetzt einer defekt war, habe ich den durch eine externe SSD ersetzt und damit läuft es gefühlt schneller.

    Nun ist das zwar ein Raspi4 mit USB 3.0, aber auch an USB 2.0 sollte eine SSD besser sein.

    Es braucht ja für einen Raspi2 auch nicht die schnellste SSD. Und da gehen die Preise ja schon bei 50€ für 1TB los. Zusätzlich noch ein externes 2,5 Zoll Gehäuse für 10€, und man ist immer noch deutlich günstiger als beim Stick.

    Bei einem 2A Netzteil erwarte ich eigentlich auch keine Probleme, da es bei der SSD ja keine so hohen Anlaufströme gibt, wie bei einer normalen Festplatte. Ich kann es aber nur definitiv für meinen Raspi4 mit 2,5A Netzteil sagen, da gibt es keine Probleme.


    Grüße

    kamel5

  • [ANNOUNCE] VDR Version 2.6.3 freigegeben

    Quote from 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

  • Löschen von Aufnahmen und symlinks

    Ich habe zwar nicht ganz so viel "Platte", aber auch schon knapp 50TB im Server, da wäre mir allerdings ext4 auch zu unsicher.

    Ich habe vor Jahren mal mit btrfs experimentiert und konnte mich damit nie so richtig anfreunden, das Händling ist mir einfach zu unübersichtlich und dann fehlte mit damals die native raid5 Unterstützung.

    Ich habe mich dann nach langen Überlegen für zfs als Dateisystem entschieden, und habe das bis heute nicht bereut.

    Ein Backup (täglich) mache ich da nur für meine wichtigen persönlichen Daten, wie Fotos, Videos vom Handy, Dokumente etc. Sonstige Videos (Aufzeichnungen vom VDR und andere mkv's) lasse ich außen vor, das bekommt man im Fehlerfall meistens irgendwo wieder her.


    Grüße

    kamel5

  • Löschen von Aufnahmen und symlinks

    Quote from wmautner

    Bei Hard- oder reflinks gibt es aber keine "toten Link"-Einträge - da muß am Script ohnehin was geändert werden.

    Was mich wundert: xfs ist gerade für große Dateien und Dateisysteme gut gerüstet und hat bei mir so überhaupt keine Probleme bereitet.

    Auch btrfs wird immer besser und stabiler, und so ich weiß, aber schon lange nicht mehr getestet habe, läßt sich ext4 auch in btrfs konvertieren, sofern noch genügend Platz auf der Partition ist. Es gibt auch sogar unter ubuntu/debian das "fstransform"-Tool, das sollte ext4 in xfs konvertieren können. Bei neueren Kernels ist der reflink-Support schon standardmäßig aktiv, so ich weiß.

    Bei so einem großen Dateisystem würde ich solche Experimente ohne Backup aber nicht machen.

    Ich habe auch schon mal ext4 in btrfs transformiert und hatte hinterher immer wieder Probleme.


    Grüße

    kamel5

  • Löschen von Aufnahmen und symlinks

    Quote from nobanzai

    D.h. ich muss mein Hauptverzeichnis sowie das .rec Verzeichnis im Script selber anlegen und dann die Dateien rüber linken.

    Das würde den Fall abdecken, dass etwas aus "neue Aufnahmen" entfernt werden, aber im eigentlichen Aufnahmeverzeichnis stehen bleiben soll.

    Genau.

    Quote from nobanzai

    Was ich leider bisher vergessen habe: Wenn aus dem eigentlichen Aufnahmeverzeichnis etwas entfernt wird, wird momentan vom Script auch der Rest im "neue Aufnahmen" Verzeichnis weg geputzt. Erkannt wird das über den dann toten .del-Link.

    Sieht jetzt aus wie folgt. Die Loops sind nur deswegen drin, weil ich die Meldungen für jede einzelne Datei möchte. Sonst könnte man den finds auch jeweils ein "-delete" mitgeben.

    Das funktioniert dann nicht mehr so einfach. Für das System sind das dann 2 halb verschiedene Verzeichnisse, obwohl nur einmal Platz gebraucht wird.

    Veränderungen im Originalverzeichnis wirken sich dadurch bei ext4 auf untersciedliche Art im kopierten Verzeichnis aus:

    Löschungen im Originalverzeichnis wirken sich nicht aus.

    Veränderungen an Dateien im Originalverzeichnis wirken sich aus.

    Neue Dateien im Originalverzdichnis werden nicht autom. übernommen.


    Grüße

    kamel5

  • Löschen von Aufnahmen und symlinks

    OK, das hilft Dir doch aber nicht weiter. Wenn dem symlink nicht gefolgt wird, dann kannst Du doch mit dem Zielverzeichnis überhaupt nichts machen.

    Quote from nobanzai

    ls -l 00-neue_Aufnahmen/* 00-neue_Aufnahmen/Doctor_Who_-_01x05_-_Der_dritte_Weltkrieg:

    total 4

    lrwxrwxrwx 1 vdr video 113 8. Feb 03:00 2023-02-08.01.50.24-0.rec -> /var/spool/video/video0/Science_Fiction-Fantasy/Doctor_Who/01x05_-_Der_Dritte_Weltkrieg/2023-02-08.01.50.24-0.rec

    Mal an diesem Beispiel, wenn dem symlink nicht gefolgt wird, kannst Du auch die Aufnahme unter "00-neue_Aufnahmen" nicht abspielen.


    Grüße

    kamel5

  • Löschen von Aufnahmen und symlinks

    Quote from nobanzai

    mach mal keinen bind mount, sondern einen normalen mount. Das müsste doch klappen, oder?

    Wenn Dein primäres Ziel, die Sicherheit der originalen Aufnahme ist, dann hilft Dir mount auch nicht weiter.

    mount stellt nur das originale Verzeichnis woanders bereit. Natürlich könnte man ein "mount -o ro" machen, ob da aber der VDR mit klar kommt, ohne Schreibrechte, eher nicht.


    Wenn Du mit einem geringen Risiko leben kannst, dann ist das mit dem symlink schon i.O.

    Wenn nicht, dann musst Du eine Kopie der originalen Aufnahme anlegen. Wenn Du genug Plattenplatz hast (als Cache) würde ich einfach eine normale Kopie machen, im anderen Falle mit hardlink, wie oben schon geschrieben oder auch mit "cp --reflink", wenn es das Dateisystem unterstützt, so weit ich das verstanden habe, kann das im Moment btrfs oder xfs.

    Zum testen mal "cp --reflink=always originaldatei kopie" eingeben. Wenn es eine Fehlermeldung gibt, kann es das Dateisystem nicht.

    Quote from SHF

    Eine Möglichkeit zur Anzeige der letzten 50 oder 100 Aufnahmen in umgekehrter chronologischer Reihenfolge fände auch ich klasse.

    So was in der Art kann man mit dem Plugin "recsearch" machen. Man kann dort zwar im Moment nicht die Aufnahmen auf eine Menge x begrenzen, man kann sich aber die Aufnahmen der letzten x Tage anzeigen lassen. Vielleicht hilft das ja schon. Und eine Erweiterung auf x Aufnahmen ließe sich möglicherweise auch noch einbauen.


    Grüße

    kamel5

  • Löschen von Aufnahmen und symlinks

    Ich würde das hier pragmatisch sehen. Wenn die Aufnahme fertig ist und Dein Script läuft, kannst Du natürlich nur die Dateien, die dann vorhanden sind, verlinken. Die resume-Datei könnte man sowieso ignorieren, und alles Andere, was dann später dazu kommt, gibt es natürlich nur in dem entsprechenden Verzeichnis.

    Die Frage ist, was kommt denn später noch dazu. Soviel kann das ja nicht sein. Du könntest Dein Script z.B. mit einer kurzen Verzögerung laufen lassen.

    Und wenn es Sachen sind, die sowieso automatisch unabhängig von der Aufnahme im Hintergrund stattfinden, dann werden die auch autom. auf beide Verzeichnisse angewendet, nehmen dann aber auch 2 mal Platz weg.


    Grüße

    kamel5

  • Löschen von Aufnahmen und symlinks

    Quote from nobanzai

    Hm, warum weiß der VDR nicht, dass es ein symlink ist?

    Naja, das hat bisher vielleicht keiner gebraucht, und ist deshalb nicht verfügbar.

    Quote from nobanzai

    Beim Hardlink ist es nicht so einfach zu erkennen.

    Hardlink ist eigentlich ganz simpel. Da brauchst Du nichts weiter zu beachten.


    Für den VDR sind dann "00-neue_Aufnahmen/Doctor_Who_-_01x05_-_Der_dritte_Weltkrieg/2023-02-08.01.50.24-0.rec" und "Science_Fiction-Fantasy/Doctor_Who/01x05_-_Der_Dritte_Weltkrieg/2023-02-08.01.50.24-0.rec" zwei vollkommen verschiedene Verzeichnisse, die nur dadurch miteinander verbunden sind, das die darin liegenden Dateien quasie die selben sind, sie nehmen also nur einmal Platz weg. Beim Löschen wird dann "00-neue_Aufnahmen/Doctor_Who_-_01x05_-_Der_dritte_Weltkrieg/2023-02-08.01.50.24-0.rec" zu "00-neue_Aufnahmen/Doctor_Who_-_01x05_-_Der_dritte_Weltkrieg/2023-02-08.01.50.24-0.del" und wird gelöscht. Der andere Pfad bleibt davon unberührt.


    z.B.: ln vdr.conf vdr.conf.bak

    führt zu:

    -rw-r--r-- 2 root root 4621 17. Dez 12:01 vdr.conf

    -rw-r--r-- 2 root root 4621 17. Dez 12:01 vdr.conf.bak


    Du siehst vorne an der roten "2", das diese Datei zwar nur einmal existiert, aber zweimal im Dateisystem auftaucht...

    Wenn Du jetzt eine davon löschst, bleibt die andere unverändert übrig.

    rm vdr.conf.bak

    führt zu:

    -rw-r--r-- 1 root root 4621 17. Dez 12:01 vdr.conf


    Dadurch kann der VDR die Aufnahme in "00-neue_Aufnahmen" unabhängig von der anderen Aufnahme löschen, ohne das Du da irgendwas beachten musst.


    Grüße

    kamel5

  • Löschen von Aufnahmen und symlinks

    Quote from nobanzai

    Allerdings möchte ich nicht, dass beim Löschen der Aufnahme unter "neue Aufnahmen" die Aufnahme aus dem Originalordner entfernt wird, sondern nur der Ordner samt dem Link darunter unter "neue Aufnahmen".

    Das wird so einfach nicht funktionieren, da der VDR ja nicht weiß, das es ein Link ist.


    Die einzige Idee, die ich da jetzt spontan hätte, wäre mit einem Hardlink, anstelle eines Softlink zu arbeiten, dann wären das für den VDR zwei unterschiedliche Geschichten. Allerdings funktioniert das nicht für Ordner, sondern nur für Dateien. Da Du aber sowieso ein Script laufen lässt , könntest Du auch die Dateien etsprechend anstelle des Ordners hard linken. Getestet habe ich sowas aber auch noch nicht.


    Grüße

    kamel5

  • [ANNOUNCE] VDR Version 2.6.3 freigegeben

    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.

    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

  • [Announce] vdr-plugin-tvscraper 1.1.10

    Ich muss das nochmal aufwärmen.


    Abstürze habe ich keine mehr, aber wahrscheinlich erst einmal nur wegen CheckDirExists().

    Eine Sache fällt mir aber noch auf. Dazu habe ich mal in der Datei "movieOrTv.c" folgende Fehlermeldung eingebaut:

    Code
    void deleteOutdatedRecordingImages(const cTVScraperDB *db) {
// check recording. Delete if this does not exist
if (!CheckDirExists(config.GetBaseDirRecordings().c_str() )) {
    esyslog("tvscraper, ERROR, %s not found", config.GetBaseDirRecordings().c_str());
    return;
}
std::error_code ec;

    und in "tools/filesystem.c":

    Logausgabe dazu:

    Das Verzeichnis ist vorhanden, siehe weiter oben, wird aber trotzdem als Fehler ausgegeben.

    Man sieht hier, das er bei dieser Prüfung:

    "if ((statfsbuf.f_type!=0x01021994) && (statfsbuf.f_type!=0x28cd3d45)) return false;"

    "false" zurück gibt.

    OK, ich nutze zwar kein externes EPG, müsste hier aber nicht die Prüfung trotzdem positiv verlaufen?

    Warum wird auf diese beiden Dateisysteme geprüft?

    Wenn man die ausschließen will, dann wäre die Abfrage allerdings falsch.


    Grüße

    kamel5

  • [ANNOUNCE] VDR Version 2.6.3 freigegeben

    Quote from 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.

    Quote from 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.

    Quote from 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

  • [ANNOUNCE] VDR Version 2.6.3 freigegeben

    Quote from 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:

    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

  • [Announce] vdr-plugin-tvscraper 1.1.10

    Quote from MarkusE

    Letztere Meldung kommt aber nur, wenn bei VDR --log=3 gesetzt ist.

    Ja, ist bei mir eingestellt.

    Auch "using base directory" gibr es.

    Code
    Feb 05 09:24:27 home-05.home.de vdr[4275]: [4275] tvscraper: using base directory /etc/vdr/plugins/tvscraper/


    Quote from MarkusE

    Die Konfiguration ist in der README.md besch

    Ja, habe ich gelesen. Da steht aber nichts zu den Verzeichnissen "epg" und "recordings". Oder habe ich da was übersehen.

    Ich habe auch bisher in die "override.conf" keine Änderungen eingetragen.


    Gestern hatte ich nochmal 2 Abstürze:

    Code
    #15 0x00007fded7bb53e7 in std::filesystem::__cxx11::directory_iterator::directory_iterator(std::filesystem::__cxx11::path const&, std::filesystem::directory_options, std::error_code*)
    (this=0x7fde7b7fdb30, p=filesystem::path "/etc/vdr/plugins/tvscraper/recordings/" = {...}, options=<optimized out>, ecptr=0x0)
    at /usr/src/debug/gcc-12.2.1-4.fc37.x86_64/obj-x86_64-redhat-linux/x86_64-redhat-linux/libstdc++-v3/include/bits/new_allocator.h:90
        skip_permission_denied = false
        ec = std::error_code = {"generic": ENOENT}
        dir = {<std::filesystem::_Dir_base> = {dirp = 0x0}, path = filesystem::path "", entry = {_M_path = filesystem::path "", _M_type = std::filesystem::file_type::none}}
#16 0x00007fdebe2529d0 in std::filesystem::__cxx11::directory_iterator::directory_iterator(std::filesystem::__cxx11::path const&)
    (this=0x7fde7b7fdb30, __p=filesystem::path "/etc/vdr/plugins/tvscraper/recordings/" = {...}) at /usr/include/c++/12/bits/fs_dir.h:387
#17 0x00007fdebe2348ba in deleteOutdatedRecordingImages(cTVScraperDB const*) (db=0x22a5f30) at /home/vdr/DVB/Test/vdr/PLUGINS/src/tvscraper/movieOrTv.c:996

    Das scheint aber jetzt mit Deinem letzten commit auch abgefangen zu werden.


    Das ist der Inhalt vom Verzeichnis tvscraper:

    Die Frage ist jetzt, warum gibt es überhaupt den Absturz, denn beide Verzeichnisse gibt es ja. Sie sind allerdings leer.

    Und die anderen beiden Verzeichnisse "movies" und "series" sind befüllt und werden auch aktualisiert.

    Der VDR läuft bei mir unter "root".


    Grüße

    kamel5