Posts by heifisch

    Warum willst Du ffprobe nochmal ausführen, das kostet Zeit, steht doch Alles im logfile.


    Ich bin noch auf Ideensuche...


    Ich habe nochmal im Git nachgeschaut, der Codec wird erst seit 4 Monaten an den service_name angehängt.


    So lange verwende ich es noch nicht.

    Ich habe die HD-Aufnahmen erst mit Verwendung von Deinem Script für mich entdeckt ;-)

    Jetzt will ich aber alles in HD und möglichst platzsparend haben auch wenn ich nur SD-Augen habe...


    Ok, also würde es bei mir reichen, ins logfile zu schauen.

    Mal schauen, wie ich das umsetze...


    Gruß und Danke

    Heiko

    Hallo.


    Erstmal Danke für die tolle Arbeit!


    An welcher Zeile im logfile einer transcodierten HD-Aufnahme, würde man festmachen, dass die transcodierte Aufnahme HEVC ist?


    Ich möchte ein kleines Script schreiben, welches diese Information ins info-File mit unter S ablegt, so dass man in live sehen kann, welche HD-Aufnahme schon transcodiert wurde.


    O.T.

    Danke auch an MarkusE für die tolle Weiterentwicklung von live und tvscraper.

    Habe gerade noch einige Duplikate gefunden, die mir vorher durch die Lappen gegangen sind...


    Gruß

    Heiko

    Teste doch mal mit

    --tvscraperimages=/var/cache/vdr/plugins/tvscraper

    Danke, mache ich.

    Muss nur warten bis die Aufnahmen fertig sind.


    Aber irgend einen default scheint live ja zu verwenden, sonst hätte es ja nicht den Pfad zu den Bildern, so zusammen gebaut:

    Code
    1. https://192.168.139.150:8008/tvscraper//var/cache/vdr/plugins/tvscraper/movies/495764_poster.jpg

    > Muss ich evtl. noch etwas einstellen wie den Pfad mit "--tvscraperimages"?

    Ja. Was gibst Du denn bei --tvscraperimages mit?


    Da habe ich bisher nichts mitgegeben.

    Der Pfad zu den Bildern kommt zumindest nicht von irgend welchen Parametern, die ich mitgegeben habe.

    Hallo.


    Vorweg, hier tntnet 3.0 im Einsatz, weil das ja die häufigste Ursache bei Problemen bei mir war...


    Bei mir werden die Bilder im Reiter "Bilder" nicht angezeigt.


    Bei "Grafik in neuem Tab öffnen" kommt dann Folgendes:


    Code
    1. Error
    2. Not Found: vhost: 192.168.139.150:8008 /tvscraper//var/cache/vdr/plugins/tvscraper/movies/495764_poster.jpg


    Die Datei gibt es auf dem Rechner in folgendem Verzeichnis:


    Code
    1. vdr ~ # ll /var/cache/vdr/plugins/tvscraper/movies/495764_poster.jpg
    2. 42204118 184 -rw-r--r-- 1 root root 186695 22. Jun 04:19 /var/cache/vdr/plugins/tvscraper/movies/495764_poster.jpg



    Die Bilder im Reiter "EPG" werden korrekt angezeigt. Da sieht die URL so aus:


    Code
    1. http://192.168.139.150:8008/recimages/d91698ab7f9f6c3a3f476d24947ed258/poster.jpg


    Wird da im Fehlerfall die URL nicht richtig zusammen gebaut?

    Muss ich evtl. noch etwas einstellen wie den Pfad mit "--tvscraperimages"?


    Sonst eine tolle Bereicherung für live!!!


    Gruß

    Heiko

    Wenn ich den ursprünglichen Befehl ausführe, listet er mir die ganzen Verzeichnisse auf, also scheinen sie auf die Bedingung zu passen...



    Das rm schlägt dann natürlich fehl, da ohne "-r" ausgeführt, soll ja auch nicht die Verzeichnisse löschen...


    Aber derartige Dateien wie bei Dir habe ich bei mir nicht gefunden.


    Gruß

    Heiko

    Hallo.


    vdr-plugin-live Stand v3.1.6 vom 19.06.2022 kompiliert mit tntnet 3.0 nicht mehr.


    Make bricht mit folgendem Fehler ab:



    Da cxxtools/log.h in Abhängigkeit von >= tntnet 3.0 includet wird, glaube ich dass es damit zu tun hat.


    Code
    1. #if TNTVERSION >= 30000
    2. #include <cxxtools/log.h> // must be loaded before any vdr include because of duplicate macros (LOG_ERROR, LOG_DEBUG, LOG_INFO)
    3. #endif


    kfb77 Hast Du da eine Idee?


    Gruß und Danke

    Heiko

    Hallo,

    Code
    1. find . -size -1958c -exec rm \{\} \;


    Findet "-1958c" nicht alles was kleiner gleich dieser Größe ist?

    Bei mir findet es so auch Verzeichnisse.


    Also müsste es doch eher so aussehen:


    Code
    1. find . -size 1958c -exec rm \{\} \;


    Um Verzeichnisse in der Ausgabe auszuschließen, könnte man noch "-type f" oder mit "-iname *.jpg" gleich ausschließlich nach jpg suchen.


    Oder liege ich hier falsch?


    Gruß

    Heiko

    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
    1. vdr /usr/local/src/vdr-plugin-live # grep -Ri MoveDirectory
    2. recman.cpp: if (!MoveDirectory(oldname.c_str(), newname.c_str(), copy)) {
    3. tools.cpp: bool MoveDirectory(std::string const & sourceDir, std::string const & targetDir, bool copy)
    4. 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.

    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
    1. // 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?

    Files

    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!"


    Das ist die VDR Instance, default ist 0.

    Code
    1. -i instance, --instance=instance
    2. ...

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


    Danke für die Aufklärung.


    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.

    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.


    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.

    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.