epgsearch für vdr 2.3.x

  • Nur mal so interessehalber: was macht eigentlich das epgsearch Timer-Menü so toll anders als VDR, daß es den ganzen Aufwand wert ist?

    Wie msv schon schrieb, epgsearch ist für viele wie mich ein must have. Das Ersetzen des Timermenus für mich allerdings überhaupt nicht. Ich habe den Patch noch nie verwendet und werde es auch nie tun, bin sehr zufrieden mit dem Original des VDR.


    Allerdings nutze ich die EPG Übersicht von vdr-plugin-epgsearch, nicht weil ich unzufrieden mit dem Original des VDR, sondern weil ich da schlicht schneller in den Suchmustern/-aufträgen von epgsearch bin und nicht erst durchs Hauptmenu muss. Die grafische Fortschrittsanzeige bei "now" ist ein wenig hübscher als die ASCII Anzeige bei VDR ... aber das ist eher wieder eine streibare Geschmackssache ... :)


    clausmuus


    Schickst Du mir bitte ein Patch, mit Header Infos, damit ich Deine Änderung an den Patches als "Pull Request" einchecken kann?


    [Edit] Und vorallem passt der Diff gar nicht zu Upstream: https://projects.vdr-developer…vdr-plugin-epgsearch.git/ ... ?


    Gruß
    Frank

    HowTo: APT pinning

    2 Mal editiert, zuletzt von fnu ()

  • Hi,
    zu den Vorteilen von epgsearch:
    Man sieht direkt in den Detailinfos einer Sendung, wann sie wiederholt wird.


    Und Suchtimer für Serien sind natürlich auch ein Grundfeature, dass ich nicht missen möchte, ebenso, wie die damals von mir angeregte Schnellsuche nach einer Sendung.


    MfG,
    Stefan

    Test-VDR1: HP rp5700 Fertigsystem, Core2Duo E6400, 2GB RAM, FF-SD C-2300, nvidia Slim-GT218 x1 | easyVDR 2.0 64Bit
    VDR3: in Rente

    VDR4: MSI G31M2 v2, Digitainer2-Geh., t6963c 6" gLCD, E5200, 2GB, 3TB WD Red, GT730, 2x TT S2-3200; easyVDR 3.5 64bit
    VDR5: Gigabyte
    GA-G31M-S2L, Intel E2140, Zotac GT730 passiv, Digitainer2-Geh., t6963c 6 " gLCD, 2 TB WD Red, 2x TT S2-3200 (an 1 Kabel) easyVDR 3.5 64bit
    VDR6:
    Intel E5200, GT630 passiv, F1 750 GB, t6963c gLCD, 2x TT S2-3200 | easyVDR 3.5 64bit
    VDR-User #1068
    www.easy-vdr.de

  • Zu EPGSearch: Die Konfliktprüfung ist ein muss, wenn man viele Serien aufnimmt. Ich nutze das fast täglich. Konflikte kann man sehr gut lösen, da man dort direkt nach wiederholungen suchen kann.

  • Zu EPGSearch: Die Konfliktprüfung ist ein muss, wenn man viele Serien aufnimmt. ...


    Zum Thema "Konfliktprüfung" würde mich interessieren, ob es eine Möglichkeit gibt, epgsearch beizubringen mit verschlüsselten Sendern in Verbindung mit einem CAM umzugehen?


    Der VDR unterstützt ja mittlerweile grundsätzlich mal MTD/MCD, leider aber unterstützten das ja bekanntermaßen nicht alle CAMs.


    Die Frage ist nun, ob man epgsearch evtl. sagen kann, welches CAMs MTD, bzw. MCD unterstützten und dann ggf. einen Konflikt meldet?

  • 3PO: epgsearch hat mehr oder weniger den Code von device.c im vdr kopiert, um Konflikte zu erkennen. Das ganze ist allerdings auf einem älteren Stand. Mit verschlüsselten Sendern und CAMs kann ich nichts testen, deshalb traue ich mich da nicht ran.


    Ich habe aber noch 3 Commits in der Pipeline
    1) Suchtimer erzeugen ihre Timer nur noch lokal, weil alle Mechanismen zur Prüfung auf Wiederholung , manueller Veränderung etc. auf lokale Dateien zurückgreifen müssen
    2) noch ein Locksequenzfehler
    3) Im Setup kann der Konfliktcheck für manuell erzeugte Remotetimer eingeschaltet werden.

  • Leider ist beim Übertragen eines Patches der letzte Teil verlorengegangen. Zu 0001-Searchtimers... gehört noch der Teil im Anhang - sorry

  • Hallo,


    ich habe beim Testen noch 2 Sachen gefunden:


    - 1. Problem mit Searchtimer-Update:


    Wenn unmittelbar nach dem Starten des VDR 2.3.x beim search-timer-update Prozess neue Timer erkannt werden, gibt es eine Fehlermeldung bei der SVDRP-Verbindung und die Update-Funktion hängt bis zum Beenden des VDR. Bereinigen kann man das nur, wenn man vdr-2.2.0 benutzt. Danach kann man auch vdr-2.3.x wieder verwenden. Später gefundene neue Timer werden, soweit ich das sehen konnte, dann auch wieder korrekt angelegt.


    Folgende Logs, einmal vdr-2.3.x mit Hänger und danach mit vdr-2.2.0:


    vdr-2.3.x:


    vdr-2.2.0:


    Beim Beenden des VDR (kein Absturz) gibt es dann einen coredump:


    backtrace-epgsearch-update.txt.gz


    In den beiden Logs jeweils Zeile 6 wird bei vdr-2.3.x der Timer 0 genannt, bei vdr-2.2.0 Timer 1. Ist dieser Unterschied nur kosmetischer Natur oder könnte sich dahinter auch noch ein Problem verbergen?


    - 2. Lockproblem:


    Wenn eine Suchtimeraufnahme (nicht bei einer händisch erzeugten Aufnahme) endet, gibt es diesen folgenden invalid lock sequence report:


    Leider habe ich im Moment nur diesen ausführlichen Report für vdr-2.3.7. Bei vdr-2.3.8 existiert aber das gleiche Problem, auch bei nicht verschlüsselten Sendern.


    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

  • kamel5:
    Den Bad File Descriptor hatten wir schon mal, der sollte sich mit dem Aufrufparameter "-f /usr/bin/svdrpsend" umgehen lassen. Trotzdem wüsste ich gerne, was bei dem internen Socketmechanismus schiefgeht.
    Kannst du den vdr neu übersetzen mit DumpSVDRPDataTransfer = true in svdrp.c? Dann findet man im sysout vom vdr die komplette SVDRP-Kommunikation.
    Zum Locksequenzfehler muss ich Klaus einbeziehen.

    vdr-2.6.4

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

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

  • kamel5
    Danke. Der Locksequenzfehler macht so für mich keinen Sinn. Ich kann ihn bei mir nicht nachvollziehen. Hast du eine Ausgabe mit 3.1.8, es ist ja in letzter Zeit einiges geändert worden an dem Locksequenzdebugging?

    vdr-2.6.4

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

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

  • Hast du eine Ausgabe mit 3.1.8,

    VDR 2.3.8 ... ?

    HowTo: APT pinning

  • DumpSVDRPDataTransfer = true in svdrp.c?

    Hmm, ich habe das jetzt so laufen und der Fehler tritt auch wieder auf, aber eine zusätzliche Ausgabe habe ich bisher nicht gesehen.
    Ich habe den VDR mit --log=3 und epgsearch mit --verbose=3 am laufen. Habe ich da noch was übersehen?
    Wenn nicht, liegt das Problem wohl bereits vor der ersten Datenkommunikation vor.


    Die letzte Ausgabe ist wie bisher:


    vdr[17902]: [17939] SVDRP < 127.0.0.1:36908 server created
    vdr[17902]: [17930] ERROR (svdrp.c,404): Bad file descriptor


    Am anderen Problem bin ich noch dran.


    fnu
    schon klar.


    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

  • Hast du in die Standardausgabe vom vdr geschaut? Der Dateiname vdr.out oder ähnlich hängt von der Installation ab. Die Ausgaben vom svdrpdebugging landen da.
    Den Sequenzfehler habe ich jetzt doch auch reproduzieren können, da warte ich auf eine Antwort von Klaus

    vdr-2.6.4

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

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

  • Hast du in die Standardausgabe vom vdr geschaut?

    OK, ich habe es jetzt auch gefunden, Ausgabe war auf tty8


    Code
    > ���: NEWT 1:94:2017-07-25:0508:0610:50:99:Serien~Death in Paradise~Familienbande:<epgsearch><channel>94 - Fox HD</channel><searchtimer>Death In Paradise</searchtimer><start>1500952080</start><stop>1500955800</stop><s-id>36</s-id><eventid>60669</eventid></epgsearch>


    Den Sequenzfehler habe ich jetzt doch auch reproduzieren können,

    Super, da lasse ich das erst mal ruhen.

    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

  • Der Sequenzfehler wird wahrscheinlich ein größerer Umbau.
    Dafür bin ich jetzt weitergekommen mit dem SVDRP-Fehler, den auch Rookie hatte. Seit vdr 2.3.1 gibt es im vdr selber cSVDRPClient : : Send(), den gleichen Namen gibt es im epgsearch schon lange. Es scheint mir Compilerabhängig zu sein, welche Routine aufgerufen wird, die im vdr selber findet natürlich keinen offenen Socket, deshalb "Bad File Descriptor".
    Ich werde wohl die Routinen umbennen, ein eigener Namespace scheint mir nicht sinnvoll zu sein, oder was sagen die C-Spezialisten?
    Vorerst würde ich empfehlen, im Plugin-Aufruf "-f /usr/bin/svdrpsend" mitzugeben, dann passiert das nicht.

    vdr-2.6.4

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

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

  • Vorerst würde ich empfehlen, im Plugin-Aufruf "-f /usr/bin/svdrpsend" mitzugeben, dann passiert das nicht.

    Bei mir hat nur --svdrpsendcmd=/usr/bin/svdrpsend geholfen, ehrlich gesagt weiß ich nicht wieso sollte eigentlich identisch sein.


    rookie

    VDR 4: AMD Kabini 5310, Asrock AM1H-ITX, Gen2Vdr V6, Cine S2, Atric , Harmony 515 , Streacom ST-F7CB EVO

Jetzt mitmachen!

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