epgsearch für vdr 2.3.x

  • Hallo,


    ich versuche gerade für meinen neuen VDR-2.3.8 einige Plugins zu finde.

    Irgendwie find ich die sourcen zum live Plugin nicht.

    Die die hier im ersten Beitrag angeboten werden sind ja ca. 5 Jahre alt.


    Kann mir hier jemand helfen?

  • epgsearch-Git:

    https://projects.vdr-developer…vdr-plugin-epgsearch.git/


    Jetzt bekomme ich aber ein Glas Ziegenmilch ;D

  • Es wäre schön, wenn jmd in vdr-developer.org entsprechende Links setzen könnte, wenn man über projects.vdr-developer.org/projects einsteigt und zu den Plugins verzweigt, bei epgsearch wird man auf winni.vdr-developer.org geführt, wo kein aktuelles git mehr ist.

    vdr-2.6.0
    softhddevice,, dbus2vdr, dvd, epgsearch, femon, graphtftng, hbbtv, menuorg,
    osdteletext, radio, recsearch, satip, tvguide, vnsiserver

    ubuntu focal, yavdr-ansible, linux-5.10 ,AsRock J4105, CIne CT-V7 DVB-C

  • Hi,


    I get a deadlock in recdone, when two timers stop at the same time!

    the vdr watchdog will trigger after 5 minutes with

    ERROR: cStateKey::~cStateKey() called without releasing the lock first (tid=0, lock=5 Schedules, key=0x81cb90)


    One thread is in recstatus.c line 110

    Another thread is in recdoneThread waiting for timer_lock

    a gdb bt is attached


    Greetings Rene

  • There is a small gap where this can happen. I will queue the recdone-events, but this has to be thoroughly tested.

    If someone wants to test too , I attach a patch.

    Files

    vdr-2.6.0
    softhddevice,, dbus2vdr, dvd, epgsearch, femon, graphtftng, hbbtv, menuorg,
    osdteletext, radio, recsearch, satip, tvguide, vnsiserver

    ubuntu focal, yavdr-ansible, linux-5.10 ,AsRock J4105, CIne CT-V7 DVB-C

  • Hi,


    I did the same test as before, I now get in the log:

    started recdone_thread

    2 times : recdone_thread processing filename

    ended recdone_thread


    So that seems to be oke. I will keep the patch and test further.


    Thanks so far.


    Rene

  • Hallo,


    mir ist gerade ein Problem mit dem Suchtimerupdate aufgefallen, und zwar bei einer Sendung auf ONEHD in Zusammenhang mit der Sommerzeitumstellung.

    Ich habe einen Suchtimer definiert, der mir die Sendung Doctor Who aufnimmt:

    Die Sendergruppe Dr Who besteht nur aus 2 Sendern, wobei hier nur ONEHD betroffen ist.

    Die Sendung die dabei gefunden wird ist am So den 29.10:


    Doctor Who / Torchwood~Um 03:00 Uhr Beginn der Winterzeit


    Das Problem ist nun folgendes:

    EPGSearch legt die Sendung erst einmal korrekt an, erkennt aber bei weiteren Suchtimerupdates nicht, das sie schon angelegt wurde.


    Die timersdone.conf sieht jetzt schon wieder so aus:

    und die timers.conf vom vdr:

    Gerade ist schon wieder einer angelegt worden. Jetzt sind es bereits 5.


    So wie es aussieht hat das Problem wohl nicht mit der Zeitumstellung zu tun. Es wird wohl eher an den Sonderzeichen im Sendungsnamen liegen.

    Alle anderen von diesem Suchtimer gefundene Sendungen werden übrigens korrekt behandelt.
    Was noch auffällt ist das dieser Timer selbst im EPG nicht richtig dargestellt wird, auch im vdr-eigenen nicht.


    Grüße

    kamel5

    VDR 2.6.0: ASUS Prime X470-PRO, Ryzen 7 2700, 64GB, 6TB HD, GT1030, Fedora 35 Kernel 5.15 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Ich hab da auch ein paar Dutzend Timer mit einer alten epgsearch-Version und vdr2.2. Ist also ein altes Problem.


    Lars

  • Meiner Einschätzung nach kann es nur damit zusammenhängen, dass der Timer in die Zeitumstellung fällt und vom main vdr anders abgespeichert wird als er im epg gefunden wird. Deshalb gibt es dann keine Übereinstimmung und er wird immer wieder neu eingetragen.

    vdr-2.6.0
    softhddevice,, dbus2vdr, dvd, epgsearch, femon, graphtftng, hbbtv, menuorg,
    osdteletext, radio, recsearch, satip, tvguide, vnsiserver

    ubuntu focal, yavdr-ansible, linux-5.10 ,AsRock J4105, CIne CT-V7 DVB-C

  • mini73 Danke fürs Testen.

    TomJoad Es sieht wohl so aus, das der VDR hier involviert ist.


    Ich habe kls dazu mal gemailt und es sieht so aus, das es schon einen Unterschied macht, ob der Timer mit oder ohne VPS erzeugt wird. Das hilft zwar bei Sendungen mit VPS (wie der oben genannten), aber eben nicht bei Sendeungen ohne VPS. Ich konnte es auch bisher nur bei Sendungen, die während der Zeitumstellung laufen, reproduzieren.


    Ein weiterer Unterschied könnte auch die Systemzeit sein, er hat sein System auf UTC stehen und ich auf localzeit. Ich kann aber leider mein System kurzfristig nicht auf UTC umstellen und er hat bis zur Zeitumstellung auch keine Zeit zum weiteren Testen. Deshalb die Frage hier, möglicherweise kann auch jemand Anderes mal schauen, ob es sich mit Sytemzeit auf UTC genauso verhält.


    kamel5

    VDR 2.6.0: ASUS Prime X470-PRO, Ryzen 7 2700, 64GB, 6TB HD, GT1030, Fedora 35 Kernel 5.15 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5


  • Mit VPS gibt es kein Problem. Ohne VPS gibt ti->StopTime() die falsche Zeit aus, wenn zwischen Beginn und Ende der Sendung eine Zeitumstellung liegt.


    Wenn epgsearch einen Timer zum Anlegen findet (hier Doctor Who mit Anfangszeit 01:20 und Endezeit 03:30),

    wird überprüft, ob es schon einen entsprechenden Timer gibt. Im epg-Event stehen Anfangszeit und Länge der Sendung. Daraus ergibt sich die Endezeit (die sollte immer richtig sein, auch wenn zwischendrin die Zeit umgestellt wird, weil es sich um Sekunden seit 1.1.1970 handelt). Dieser Event wird verglichen mit bereits angelegten Timern über deren Start- und Stopzeiten aus ti->StartTime() und ti->StopTime() (wenn kein VPS eingeschaltet ist).

    Bei den bereits angelegten Timern gibt vdr als als Ende 02:30 aus und dieser Timer wird von epgsearch nicht dem Event zugeordnet.

    vdr speichert einen Timer mit seinen Anfangs- und Endezeiten als Uhrzeiten ab (timers.conf).

    in Matches (timers.c) wird aus den Uhrzeiten die Länge berechnet und damit aus der Anfangszeit die stopTime.

    Das geht schief, wenn wie hier die Zeitumstellung dazwischen kommt.


    Ohne Gewähr auf irgendwelche Nebenwirkungen eine Änderung in timers.c ( entfernt auch alle fälschlicherweise zusätzlich angelegten Timer beim nächsten epgsearch-update-Lauf)

    vdr-2.6.0
    softhddevice,, dbus2vdr, dvd, epgsearch, femon, graphtftng, hbbtv, menuorg,
    osdteletext, radio, recsearch, satip, tvguide, vnsiserver

    ubuntu focal, yavdr-ansible, linux-5.10 ,AsRock J4105, CIne CT-V7 DVB-C

  • Mein VDR läuft mit UTC-Zeit im BIOS und ich hatte auch Probleme mit Mehrfachtimern (Hannibal ~30 Stück)

    Alle Jahre wieder. Mal mehr mal weniger, je nach dem wie viele Timer in die Zeit der Umstellung fallen

    MP-Logos (Kanallogos für VDR) - Picons2VDR (Kanallogos für VDR) - MV_Backup (Backup mit RSync) - Skin FlatPlus (Fork)

    „In zwei Jahren wird das Spam-Problem gelöst sein.“ [Bill Gates], Microsoft-Chef, 2004

  • MegaV0lt Danke für die Info

    TomJoad Danke für den Patch. Ich habe ihn mal bei mir eingespielt und im ersten Moment löst er auch das Problem bei der oben genannten Sendung.


    Tests mit anderen Sendungen haben aber noch ein paar Probleme gezeigt:

    - bei folgender Sendung auf PhoenixHD So. 29 00:00 "Historische Ereignisse" wird der Timer nur korrekt angelegt und angezeigt wenn die Vor- und Nachlaufzeit auf 0 steht. Stehen diese Zeiten auf größer 0 wird dieser Timer sogar automatisch wieder gelöscht.

    - bei folgender Sendung auf Sky Cinema +24 HD So. 29 02:50 "Ab in den Dschungel" hilft auch Vor- und Nachlaufzeit auf 0 nicht aus, Diese Sendung wird auch dann noch nicht korrekt angezeigt, bleibt aber als Timer erhalten.

    Vom ersten Fall habe ich nur diese eine Sendung gefunden. Vom Zweiten gibt es mehrere.

    Vielleicht fällt Dir dazu ja auch noch was ein.


    kamel5

    VDR 2.6.0: ASUS Prime X470-PRO, Ryzen 7 2700, 64GB, 6TB HD, GT1030, Fedora 35 Kernel 5.15 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Im Patch war noch ein Fehler, wenn die Anfangszeit vor Mitternacht liegt. Das Problem mit Timern, die am Sonntag zwischen 02:00 und 03:00 beginnen, wird schwer lösbar sein, weil die Zeit nicht eindeutig ist. Dann müsste schon in den Timer-Einträgen in timers.conf die Länge mit abgespeichert werden. Korrigierter Patch (bezogen auf Originalvdr : winterzeit.diff

    vdr-2.6.0
    softhddevice,, dbus2vdr, dvd, epgsearch, femon, graphtftng, hbbtv, menuorg,
    osdteletext, radio, recsearch, satip, tvguide, vnsiserver

    ubuntu focal, yavdr-ansible, linux-5.10 ,AsRock J4105, CIne CT-V7 DVB-C

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

  • Mit dem letzten Patch geht es wieder schlechter.

    Es tritt dabei ein ganz komischer Effekt auf.

    Ab dem ersten Timer auf einem Kanal werden alle weiteren Sendungen mit dem Timer-Symbol dargestellt.

    Und EPGSearch legt jetzt alle Suchtimer wieder mehrfach an.

    Positiv: Für die beiden oben genannten Sendungen scheint das aber geholfen zu haben.

    VDR 2.6.0: ASUS Prime X470-PRO, Ryzen 7 2700, 64GB, 6TB HD, GT1030, Fedora 35 Kernel 5.15 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

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