[Announce] vdr-plugin-tvscraper 1.0.0

  • Das Plugin ist hier: https://github.com/MarkusEh/vdr-plugin-tvscraper .

    Hier die wichtigsten Verbesserungen:

    • Die Erkennung funktioniert jetzt in sehr vielen Fällen korrekt. Wie es gemacht wird, steht hier: https://github.com/MarkusEh/vd…scraper/wiki/How-it-works .
    • Es ist einen neues Interface in der internen Plugin Schnittstelle verfügbar, zur verbesserten Integration mit KODI / vnsi.
    • Die Integration mit https://github.com/MarkusEh/plugin.video.vdr.recordings wurde verbessert. KODI kann die Daten von vdr-plugin-tvscraper nutzen, um die Aufzeichnungen in die KODI Bibliothek aufzunehmen. Und ja, das geht auch mit vnsi. Aber mit diesem Plugin sieht das UI einfach besser aus, auch dann, wenn KODI über vnsi mit Bildern versorgt wird (Entwicklung von -Dis). Ist jetzt meine persönliche Meinung :) .
    • Daten zu neuen EPG Ereignissen werden schneller verfügbar gemacht

    ~ 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 habe den TVScraper 1.0.0 bei mir jetzt auch installiert. Prinzipiell funktioniert das scrapen recht gut. Es werden die überwiegenden Sendungen gefunden.


    2 Probleme habe ich bei ersten Tests aber noch festgestellt:

    - das scrapen von Aufnahmen funktioniert nur eingeschränkt.

    -- nach Starten des scrapens von Aufnahmen über das Setup-Menü schlägt der vdr watchdog zu, sobald man dann das Aufzeichnungsmenü öffnen will

    -- es ist mir bisher 2x passiert, das nach Anstoßen des scrapens von Aufnahmen, dieses abbrach, weil ein epg-scrapen gestartet wurde.


    Das erste Problem liegt daran, das die LOCK's in worker.c sehr lange (über die gasamte if Schleife) gehalten werden, was bei einer Handvoll Aufnahmen vielleicht unproblematisch, bei vielen Aufnahmen aber problematisch ist.

    Der beigefügte Patch löst das grundsätzlich. Möglicherweise muss dann aber noch geprüft werden, ob es die jeweilige Aufnahme noch gibt.


    Genauso sollten auch die anderen LOCK's nochmal überprüft werden, das die nicht unnötig lange anliegen.


    Grüße

    kamel5

  • Hi kamel,


    vielen Dank für den Patch.

    Überzeugt mich jetzt aber nicht :( . Ich meine, der Patch bewirkt, dass ich ohne read-lock lesend auf Aufnahmen zugreife. Da kann dann alles mögliche schiefgehen.

    Eigentlich ist das scrapen der Aufnahmen ja eine einmalige Sache. Da könnte man doch einfach den VDR in ruhe arbeiten lassen (?).


    ~ 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

  • Überzeugt mich jetzt aber nicht :( . Ich meine, der Patch bewirkt, dass ich ohne read-lock lesend auf Aufnahmen zugreife. Da kann dann alles mögliche schiefgehen.

    Eigentlich ist das scrapen der Aufnahmen ja eine einmalige Sache. Da könnte man doch einfach den VDR in ruhe arbeiten lassen (?).


    ~ Markus

    Das ist natürlich Deine Entscheidung. Und das "schiefgehen" müsste natürlich auch abgefangen werden...

    Ja, man könnte auch den VDR in Ruhe arbeiten lassen, und dann macht es doch jeder Anwender anders.:)

    Und dann gibt es wieder unklare "lock sequence reports", usw.


    Solche langen LOCK's bergen immer die Gefahr von Ungereimtheiten. Da gab es schon oft Diskussionen zu, bei der VDR- Entwicklung.

    Wenn ich direkt bei der ersten Benutzung darüber stolpere, bei meinen vielen Aufnahmen dauert das scrapen über eine Stunde, dann ist das zumindest bemerkenswert.


    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

  • Kann man sich nicht eine Kopie der Titel der gerade verfügbaren Aufnahmen holen und das dann in einem eigenen Thread abarbeiten lassen?

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • und das dann in einem eigenen Thread abarbeiten lassen?

    Das sollte nicht nötig sein, die Abarbeitung findet schon im Hintergrund statt. Problematisch ist nur der länger (in Anhängigkeit von der Anzahl der Aufnahmen) ununterbrochen stehende LOCK auf die Aufnamen, der andere Funktionen vom VDR beeinflussen kann.

    Mit dem obigen Patch funktioniert es ja schon unauffällig. Zusätzlich bräuchte es bei jeder Aufnahme nur noch die Prüfung, ob diese noch da ist.


    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

  • Hi kamel5,


    Mir ist unklar, warum der VDR beim Öffnen des Aufzeichnungsmenüs einen write lock setzen möchte.

    Außerdem verstehe ich nicht, was passiert, wenn ich

    Code
    for (const cRecording *rec = recordings->First(); rec; rec = recordings->Next(rec)) {

    ohne read lock durchführe.

    Was passiert, wenn ein anderer Thread gleichzeitig Änderungen an recordings macht, wärend ich "rec = recordings->Next(rec)" aufrufe?

    Was passiert, wenn ein anderer Thread delete(rec) aufruft, wähend ich noch mit rec arbeite? Ich rufe also nach delete(rec) eine Methode von rec auf?


    Irgendwie befürchte ich seltsame Fehler, die schwer zu debuggen sind.

    Oder sind da im VDR Mechanismen zum Verhindern solcher Probleme?


    ~ 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

  • Würde es helfen, wenn ich den read lock nach dem Scrapen jeder einzelnen Aufzeichnung freigebe?

    Für wie lange müsste ich ihn freigeben? Ich würde dann einfach kurz warten, bevor ich mit der nächsten Aufzeichnung weitermache.

    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

  • ohne read lock durchführe.

    Was passiert, wenn ein anderer Thread gleichzeitig Änderungen an recordings macht, wärend ich "rec = recordings->Next(rec)" aufrufe?

    Was passiert, wenn ein anderer Thread delete(rec) aufruft, wähend ich noch mit rec arbeite? Ich rufe also nach delete(rec) eine Methode von rec auf?

    Genau dafür wäre dann die Fehlerbehandlung.


    Würde es helfen, wenn ich den read lock nach dem Scrapen jeder einzelnen Aufzeichnung freigebe?

    Für wie lange müsste ich ihn freigeben? Ich würde dann einfach kurz warten, bevor ich mit der nächsten Aufzeichnung weitermache.

    Muss das scrapen denn unbedingt im LOCK stattfinden? Das kann auch einige Sekunden dauern. Im Endeffekt ist es ja nur ein Read lock um die Daten der Aufnahme zu holen. Es reicht hier, vorher zu prüfen, ob es die Aufnahme noch gibt.


    Ich habe im Moment keine Zeit, mache aber gern am Nachmittag mal einen Patch, wie ich es umsetzten würde.


    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 Anhang habe ich mal einen Patch mit 2 Lösungsvorschlägen beigefügt, der den LOCK so kurz wie möglich hält und die Fehler abfängt.

    Ich habe da auch ein paar Kommentare rein geschrieben.

    Ob man die einfache oder die aufwändigere Variante nimmt, muss man überlegen. Ich glaube zwar nicht, das die einfache Variante Probleme macht, für so eine lang laufende Schleife ist aber wahrscheinlich die aufwändigere besser.

    Im Endeffekt gibt es sicher noch andere Möglichkeiten das Umzusetzen, für ein Holen der Daten über einen read lock sollte es reichen.


    Ich habe da mal noch etwas:

    Im Moment wird das scrapen des epg kurz nach Start des VDR angestoßen. Es wäre schön, wenn man diesen zeitlichen Abstand konfigurieren könnte. Vielleicht im Bereich bis zu ein paar Stunden.


    Grüße

    kamel5

  • Hi,


    1. Nehmen wir mal an, ich habe ein gültiges cRecording *rec Object, mit einem read lock erhalten.
    2. Dann gebe ich den read lock frei.
    3. Dann warte ich kurz
    4. Dann rufe ich rec->FileName() .

    Und nun die Frage: Geht der 4. Schritt immer gut? Also, ich will nicht wissen, ob die Aufzeichnung noch existiert. Ich will wissen, ob das rec Objekt noch gültig ist. Könnte während dem 3. Schritt ein anderer Prozess delete(rec) aufrufen? Eigentlich schon, weil ich ja keinen read lock habe. Oder gibt es da eine Konvention in VDR, dass das nicht passiert, und der Aufruf in 4 sicher immer gut geht, ohne Speicherschutzverletzung, ...)?


    ~ 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

  • Du meinst die Zeit zwischen den einzelnen Elementen der for Schleife?

    Das kann ich Dir im Moment auch nicht sagen. Eine Aufnahme wird ja nicht sofort gelöscht, sondern erst einmal nur umbenannt und später erst gelöscht. Solange also nicht endgültig gelöscht wurde, gibt es auch noch das Object.

    Ich würde da noch ein "if (rec)" zwischen die Zeile mit dem for und dem 2. LOCK einbauen, dann passiert zumindest nichts, wenn es kein gültiges (rec) mehr gibt.


    Ich könnte hier ja mal einen Test machen und während das scrapen läuft alle Aufnahmen löschen. Mal sehen, was dann passiert.

    Das schaffe ich aber frühestens erst am Freitag.


    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

  • Hi kamel5,


    Also in Schritt 1. habe ich ja ein gültiges (rec) c++ - Objekt erhalten. Das war in Schritt 1 != 0, dann ist es in Schritt 4 immer noch !=0. Der Wert des Pointers (rec), den ich halte, wird ja nicht geändert. Die Frage ist, welche Daten an der Stelle im Speicher stehen, auf die der Pointer zeigt.


    ~ 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 verstehe den Punkt von MarkusE. Das "rec" ist ja eindeutig ein Pointer. Und wenn da in der Zwischenzeit irgendwo "delete" drauf angewendet wird, dann ist jeder weitere Zugriff potentiell ein illegaler Speicherzugriff.


    Ohne den Code komplett gelesen zu haben: Wäre es denn möglich die in der Schleife benötigten Werte (Filename, ...) einfach noch im Lock auf Variablen zu legen? Also um danach den "rec" Pointer gar nicht mehr zu brauchen?


    Seit der VDR diesen Locking-Mechanismus nutzt habe ich persönlich etwas den Überblick verloren wann das genau wie genutzt werden sollte. Vielleicht kann kls ja hier aushelfen und sagen wie man genau mit einer Schleife über Aufnahmen laufen sollte wenn innerhalb der Schleife für jeden Aufnahme potentiell irgendwas um eine Sekunde Zeit aufgewendet wird.

  • Hallo,


    ich habe immer noch nicht verstanden, welche Stelle Du genau meinst

    Mal als Beispiel:

    Du fragst Dich also, was zwischen 4. und 5. passieren kann. Eigentlich nichts.

    Was könnte den passieren? Mir fällt da im Moment nichts ein, was problematisch für den Pointer wäre. Die Zeit zwischen 4 und 5 ist einfach sehr kurz.


    Wenn Dir das aber zu unsicher ist, gibt es auch noch die Möglichkeit den LOCK bis zum Punkt 5 zu halten. Das wird dann etwas komplexer, ist aber auch machbar.

    Wenn Du willst, kann ich Dir das auch noch zur Verfügung stellen.


    M-Reimer , beim Löschen wird die Aufnahme erst einmal nur umbenannt, das sollte den Pointer nicht verändern, oder sehe ich das 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

  • Anbei mal die Version, die den LOCK bis zum Punkt 5 hält.

    Ich hoffe ich habe kein UNLOCK vergessen. Compilieren tut es. Ausprobieren kann ich es aber im Moment nicht, es laufen gerade Aufnahmen.

    Der Zweig APIVERSNUM < 20301 müsste dann auch noch passend gemacht werden.


    Grüße

    kamel5

  • Hi,


    Im git ist ein Update. Das Problem mit den gelockten Aufzeichnungen sollte damit gelöst sein.


    ~ 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 habe da mal noch etwas:

    Im Moment wird das scrapen des epg kurz nach Start des VDR angestoßen. Es wäre schön, wenn man diesen zeitlichen Abstand konfigurieren könnte. Vielleicht im Bereich bis zu ein paar Stunden.

    Wozu brauchst Du das? Ich würde da wirklich ungern noch einen Parameter einbauen. Ich könnte die Wartezeit aber verlängern, z.B. auf 5 min.

    Es wird übrigens geprüft, ob eine Aufnahme ansteht und falls ja, wird nicht gescraped. Außer wenn der Anwender das scrapen explizit startet.

    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

  • Naja, der alte tvscraper ging immer erst Nachmittags los. Das wahr hilfreich bei Tests. Ich teste immer gerne mit allen Plugins, die ich nutze.

    Und da wahr ich meist mit meinen Tests fertig.

    Ich kann nicht einschätzen, ob es Probleme geben kann, wenn ein laufender scraper durch einen segfault im vdr beendet wird.


    Setup-Parameter muss nicht sein. Mir würde auch reichen, wenn Du mir die Stelle im Code kurz nennst, bevor ich lange suche, wo ich mir die Zeit passend einstellen kann.


    Grüsse

    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

  • worker.c, Zeile 16

    initSleep = 60 * 1000; // das ist dann 1 Minute

    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

Jetzt mitmachen!

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