[Announce] vdr-plugin-tvscraper 1.1.13

  • 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/


    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

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

    Git-Repo: gitlab.com/kamel5

  • Im git ist noch ein Update.


    Ich rufe directory_iterator() jetzt mit dem ec Parameter auf, damit sollte es keine Dumps mehr geben.


    Ich hätte jetzt nicht gedacht, dass ein directory_iterator eine Ausnahme erzeugt, nur weil das Verzeichnis leer ist. Ist aber so. Steht auch in der Doku :( . Habe ich jetzt gelesen ...


    ~ Markus

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • 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

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

    Git-Repo: gitlab.com/kamel5

  • Hallo kamel5 ,


    Vielen Dank für Deine Analyse!


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

    Glaube ich nicht. Ich rufe ja jetzt "std::filesystem::directory_iterator(config.GetBaseDirEpg(), ec)". Und laut Manual (habe ich ja jetzt gelesen :) ) gibt es damit nur noch bei out of memory Exceptions. Probiere es doch mal aus, und lösche die "CheckDirExists()." Zeilen in "movieOrTv.c".


    Aber danke für Deine Analyse, Du hast einen Fehler gefunden.

    Ich hatte CheckDirExists() einfach von Lous übernommen, und nicht weiter geprüft. Ich habe es jetzt umbenannt, in CheckDirExistsRam. Da es prüft, ob das Verzeichnis existiert, und in einem RAM Dateisystem ist.


    Dann eine neue Methode DirExists geschrieben, die einfach nur prüft, ob das Verzeichnis existiert.

    Ein Update ist im git, aber noch relativ ungetestet.


    ~ Markus

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • Probiere es doch mal aus, und lösche die "CheckDirExists()." Zeilen in "movieOrTv.c".

    Ja, das hätte ich machen können, ich wollte aber wissen, warum es bei mir nicht geht. :)


    Mit dem letzten commit gibt es keine Fehlermeldungen mehr.


    Grüße

    kamel5

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

    Git-Repo: gitlab.com/kamel5

  • Danke für Eure Tests!


    Bitte macht wegen "Wenn ich in der Programmübersicht (mit epg2vdr) meine Tips anzeigen lasse stirbt sporadisch der VDR weg ..." einen neuen Thread auf. Das hat mit tvscraper nichts zu tun.


    ~Markus

    Hallo Markus,

    der VDR mit tvscraper im Client Betrieb killt, wenn ich in der Programmübersicht die Auf/Ab-Taste halte, um zu einem bestimmten Eintrag zu scrollen...


    Das kann kann ich bei der Nutzung als Client (--readOnlyClient) jederzeit nachstellen. Sobald intensiv auf die DB auf dem Server zugegriffen wird kommt es zum Verzögerungen der Ansicht bis hin zum Absturz des VDR.

    Testhalber habe ich auf dem VDR Client den tvscraper als Master gestartet und die lokale Datenbank erstellen lassen. Das scrollen durch die Programmübersicht ist so deutlich schneller und kein Abstürze. Leider bekommt so aber der Client nicht mit, wenn auf dem Server eine Aufnahme startet und somit werden laufende Aufnahmen nicht gescraped.

    Scheinbar läuft der VDR bei schnellen, häufigen Zugriff über das Netzwerk auf die Server DB gelegentlich in ein Timeout?

    Falls es dafür keine Lösung gibt, ist es eigentlich Möglich per svdrpsend das scrapen einer einzelnen Aufnahme zu starten? dann könnte ich z.B über das Reccommands Menü manuell die fehlenden BD Einträge abholen lassen.

  • > Absturz des VDR.

    Kannst du einen Backtrace erstellen?


    > per svdrpsend das scrapen einer einzelnen Aufnahme zu starten

    Wie würdest Du die Aufnahme identifizieren, was würdest Du bei svdrpsend mitgeben, um damit tvscraper weiß, was er scrapen muss?


    ~ Markus

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • Die Möglichkeit des Scrapens einzelner Aufnahmen, würde ich auch sehr nützlich finden.

    Ich habe immer wieder mal fehlerhafte Ergebnisse, die ich dann versuche, durch Anpassung Verzeichnisnamen und info-Datei zu korrigieren.

    Bisher habe ich dann das Scrapen mit scre gestartet, aber das dauert lange bei +2800 Aufnahmen.

    Und wenn das nicht zum Erfolg führt, fängt man von vorn an.


    Ich finde gerade wieder einige falsch erkannte Duplikate, die eigentlich schon mal gepasst hatten... ("Zurück in die Zukunft" 1 und 2, "Planet der Affen" original und remake).

    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

  • In der reccmds.conf können Commands angelegt werden, die über das Menü im OSD des VDR erreicht und gestartet werden können. Die in der reccmds.conf definierten Befehle werden angezeigt, wenn man sich in der Liste des Aufzeichnungen im OSD des VDR befindet und sich auf einem Filmnamen positioniert hat und dann Befehle

    der Fernbedienung gedrückt hat. Nun kann man den gewünschten Befehl auswählen und starten. Die Befehle sollten durch Drücken ihrer Nummer gestartet werden, drücken auf OK scheint nicht immer zu funktionieren.

    Die Befehle werden mit dem Verzeichnis-Name der jeweiligen Aufnahme als Argument ausgeführt. Der Befehlsaufruf wird in die syslog Datei geschrieben (/var/log/messages), z.B.:

    Code
    Dec 21 19:38:25 linux vdr: [3555] executing command '/usr/local/bin/test.sh "/video/Der_Grand_Canyon/2007-03-14.21:10.50.99.rec"'


    Der Befehl könnte dann z.B so aussehen: svdrpsend plug tvscraper scrp $1


    Mit dem Backtrace erstellen habe ich versucht, aber irgendwie bekomme ich das trotz Anleitung nicht hin :( (yavdr 07)

  • Hi,


    im git ist ein update.

    Damit geht dann z.B.:

    Code
    svdrpsend PLUG tvscraper scre '/video/Action/Zurück_in_die_Zukunft/Zurück_in_die_Zukunft_II/2022-06-16.22.00.19-0.rec'

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • Ich finde gerade wieder einige falsch erkannte Duplikate, die eigentlich schon mal gepasst hatten... ("Zurück in die Zukunft" 1 und 2, "Planet der Affen" original und remake).


    tvscraper und live betrachten dann 2 Sendungen als verschieden, wenn es verschiedene Einträge in thetvdb bzw. themoviedb zu den Sendungen gibt.

    Also "Zurück in die Zukunft" 1 und 2 sind verschieden. Wenn nicht, hat tvscraper eine der Sendungen falsch identifiziert (vermutlich ein Bug ...).


    ~ Markus

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • Hallo Markus,

    der VDR mit tvscraper im Client Betrieb killt, wenn ich in der Programmübersicht die Auf/Ab-Taste halte, um zu einem bestimmten Eintrag zu scrollen...


    Das kann kann ich bei der Nutzung als Client (--readOnlyClient) jederzeit nachstellen. Sobald intensiv auf die DB auf dem Server zugegriffen wird kommt es zum Verzögerungen der Ansicht bis hin zum Absturz des VDR.


    Ich habe das getestet, und konnte es nicht reproduzieren. Ich habe mit aktuellem git von tvscraper getestet, da sind Optimierungen drin.

    Testumgebung: LAN mit 100 mbit, Client1 / Server wie in meiner Signatur.

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • Hallo MarkusE.


    Vielen Dank für die Erweiterung.


    tvscraper und live betrachten dann 2 Sendungen als verschieden, wenn es verschiedene Einträge in thetvdb bzw. themoviedb zu den Sendungen gibt.

    Also "Zurück in die Zukunft" 1 und 2 sind verschieden. Wenn nicht, hat tvscraper eine der Sendungen falsch identifiziert (vermutlich ein Bug ...).


    ~ Markus


    Das spuckt das Log aus:


    Hier noch die info:


    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

  • Hi,


    Im git ist ein Update:

    - bug fix: römische Zahlen

    - bug fix: die Zuordnung eines Films zu einer Aufzeichnung wurde bei Änderungen nicht upgedated


    Damit sollte Zurück in die Zukunft II korrekt identifiziert werden.


    ~ Markus

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • Im git ist ein Update:

    - bug fix: römische Zahlen

    - bug fix: die Zuordnung eines Films zu einer Aufzeichnung wurde bei Änderungen nicht upgedated


    Damit sollte Zurück in die Zukunft II korrekt identifiziert werden.


    Die anderen Fehler sind damit auch beseitigt.


    Vielen Dank.

    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

  • Fehler gefunden !

    Meine Netzwerkverbindung zum Server habe ich jetzt mal gemessen und nur 32Mb/sec erhalten. Habe dann die drei 1Gb Switche neu gestartet und jetzt ist die Geschwindigkeit wieder bei 950Mb/sec.

    Das erklärt die langsame EPG Anzeige im Skin der Poster Daten im Server-Client Betrieb und die Abstürze des VDR. Vielleicht sollte ich den betreffenden Switch mal erneuern.

    Sorry für den Fehlalarm :)

Jetzt mitmachen!

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