epgsearch: Timer landen sofort in timersdone.conf

    Ich nutze seit ca. 1 Jahr vdr 2.4.1 aus dem seahawk1986 ppa.

    Ich nutze dort von Anfang an das epgsearchplugin mit mehreren Suchtimern.

    Die ganze Geschichte lief bisher absolut störungsfrei.

    Seit ein paar Tagen jedoch landen über die Suchtimer neu erstellte Timer sofort in der timersdone.conf,

    die Aufnahme hat natürlich nicht stattgefunden.

    Suchtimer sind immer noch die gleichen wie zu Anfang, an der Konfiguration wurde nicht geschraubt,

    da ja immer alles lief. Die Aufnahme-Platte ist zu 62% belegt, Platz also noch reichlich vorhanden,

    Überprüfung ergab keine Fehler.

    Händisch angelegte Timer werden ordnungsgemäss ausgeführt, Datum und Uhrzeit auf dem Server stimmen.

    Ich weiss keinen Rat mehr... nutze VDR seit Version 1.x und denke, das ich mich einigermassen damit auskenne.

    Hier muss ich leider passen, ich finde die Macke einfach nicht ;(

    Für Tipps, wo ich die Suche ansetzen kann, wäre ich euch also WIRKLICH dankbar! :thumbup:

    Ich habe gestern ein ähnliches Phänomen festgestellt: es fehlen etliche Suchtimer, die vorher erfolgreich angelegt wurden und in der timersdone.conf stehen. Lt. Log wurden sie beim Starten des VDR gelöscht: "SVDRP hdvdr < 127.0.0.1:41054 deleted timer 73" aber was sie gelöscht hat ist mir bisher nicht klar (Epgsearch würde ja nicht über SVDRP gehen sondern als Plugin direkt die Timer ändern, oder?).

    Was ich bisher herausgefunden habe ist, dass alle ARD-Sender jetzt offenbar die Episodennummer in Klammern an den Titel anhängen, weshalb die Suchtimer teilweise nicht mehr greifen und dann vermutlich Epgsearch den Timer löscht. Da ich gerade mit XMLTV2VDR bastele hatte ich aber zunächst das in Verdacht.

    andre1964: nutzt Du externes EPG, also epg2vdr oder sowas? Steht in (älteren) Logs dass die Timer angelegt wurden und später wieder gelöscht wurden? Greifen die Suchtimer noch?

    Quote from FireFly

    (Epgsearch würde ja nicht über SVDRP gehen sondern als Plugin direkt die Timer ändern, oder?).

    Epgsearch macht das ganze Timer-Handling (Anlegen, Löschen, Modifizieren) über SVDRP.

    Also hat hier wohl epgsearch die Hände im Spiel.

    Grüße

    kamel5

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

    Git-Repo: gitlab.com/kamel5

    Falsches Systemdatum viell. aufgrund schwacher/leerer Knopfbatterie?

    MyVDR: yaVDR-Ansible (Ubuntu 20) - softhddevice-openglosd (ffmpeg 2.8) - epgd/epg2vdr - skindesigner estuary4vdr (adaptiert) - 1920x1080@50 Hz | kodi 21 - xstream
    Aerocube M40 | 300W | ASRock H61M-GE | Intel G530 | Asus ENGT520 | 2 x TT-budget S2-3200 | ASRock Smart Remote (CIR) | 4 GB RAM | 120 GB SSD | 3 TB HDD

    Ohne Logfile schwierig ...

    Gibt es doppelte EPG Einträge ?

    Post mal syslog und epgsearch.log

    VDR

    Server: Ubuntu 24.04 headless VDR im LXC Container, Plugins: satip (Octopus NET SL SX8), live, epgsearch, epg2vdr, markad

    Clients: LibreELEC auf RasPi3 und RasPi 3+

    Quote from kamel5

    Epgsearch macht das ganze Timer-Handling (Anlegen, Löschen, Modifizieren) über SVDRP.

    Also hat hier wohl epgsearch die Hände im Spiel.


    Im README von EPGsearch 2.4.0 habe ich aber gefunden:

    Code
    -f file,  --svdrpsendcmd=file
           the path to svdrpsend for external SVDRP communication (default is
           internal communication, so this is usually not needed anymore)

    Also sollte das doch intern ablaufen, als Plugin hat es ja auch Zugriff auf das API.

    Ich habe das so verstanden, das mit dem -f file ein alternatives svdrpsend benutzt werden kann, das nicht im Suchpfad liegt.

    Ich habe z.B. diesen Parameter nicht gesetzt und es wird trotzdem svdrpsend genommen. Bei mir liegt das unter /usr/local/bin .

    Das sieht im Log dann so aus:

    Code
    Nov 30 18:04:57 home-05.home.de vdr[2428]: [4288] SVDRP home-05 < 127.0.0.1:41212 client connection accepted
Nov 30 18:04:57 home-05.home.de vdr[2428]: [4288] SVDRP home-05 > 127.0.0.1:41212 server created
Nov 30 18:04:57 home-05.home.de vdr[2428]: [4288] SVDRP home-05 < 127.0.0.1:41212 modified timer 38 (54 1207-1258 'Serien~Star Trek: Enterprise~E²') (active)
Nov 30 18:04:57 home-05.home.de vdr[2428]: [4288] SVDRP home-05 < 127.0.0.1:41212 connection closed

    Grüße

    kamel5

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

    Git-Repo: gitlab.com/kamel5

    Quote from FireFly

    nutzt Du externes EPG, also epg2vdr oder sowas?

    Nein, ausschliesslich das, was von den jeweiligen Sender ausgeliefert wird.

    Wenn ich z.B. über das live-Plugin die Sendungen suche, werden sie gefunden.

    Auch die Suchtimer finden die fraglichen Sender.

    Ich nehme z.B. täglich "Brisant" zwischen 17:00 und 18:30 auf, die Sendungen werden nach 7 Tagen wieder gelöscht.

    Wie gesagt, es hat ja jetzt monatelang einwandfrei funktioniert! Frei nach dem Motto "never change a runnning system"

    habe ich seitdem jegliche Updates vermieden.

    Quote from FireFly

    Steht in (älteren) Logs dass die Timer angelegt wurden und später wieder gelöscht wurden? Greifen die Suchtimer noch?

    Dazu ein Auszug aus den Log's. Die Timer werden offensichtlich gefunden:

    Dec 5 01:09:00 bigdata vdr: [6355] timer 0 (1 1713-1810 'Brisant') set to event Mo. 07.12.2020 17:15-18:00 (VPS: 07.12. 17:15) 'Brisant'

    Dec 5 01:09:00 bigdata vdr: [6355] timer 0 (1 1713-1810 'Brisant') set to event Di. 08.12.2020 17:15-18:00 (VPS: 08.12. 17:15) 'Brisant'

    Dec 5 01:09:00 bigdata vdr: [6355] timer 0 (1 1713-1810 'Brisant') set to event Mi. 09.12.2020 17:15-18:00 (VPS: 09.12. 17:15) 'Brisant'

    Dec 5 01:09:00 bigdata vdr: [6355] timer 0 (1 1713-1810 'Brisant') set to event Do. 10.12.2020 17:15-18:00 (VPS: 10.12. 17:15) 'Brisant'

    Dec 5 01:09:00 bigdata vdr: [6355] timer 0 (1 1713-1810 'Brisant') set to event Fr. 11.12.2020 17:15-18:00 (VPS: 11.12. 17:15) 'Brisant'

    Dec 5 01:09:00 bigdata vdr: [6355] timer 0 (1 1708-1757 'Brisant') set to event Sa. 12.12.2020 17:10-17:47 (VPS: 12.12. 17:10) 'Brisant'

    Dec 5 01:09:00 bigdata vdr: [6355] timer 0 (1 1658-1740 'Brisant') set to event So. 13.12.2020 17:00-17:30 (VPS: 13.12. 17:00) 'Brisant'

    Dec 5 01:09:00 bigdata vdr: [6355] timer 0 (1 1713-1810 'Brisant') set to event Mo. 14.12.2020 17:15-18:00 (VPS: 14.12. 17:15) 'Brisant'

    Dec 5 01:09:00 bigdata vdr: [6355] timer 0 (1 1713-1810 'Brisant') set to event Di. 15.12.2020 17:15-18:00 (VPS: 15.12. 17:15) 'Brisant'

    Dec 5 01:09:00 bigdata vdr: [6355] timer 0 (1 1713-1810 'Brisant') set to event Mi. 16.12.2020 17:15-18:00 (VPS: 16.12. 17:15) 'Brisant'

    Dec 5 01:09:00 bigdata vdr: [6355] timer 0 (1 1713-1810 'Brisant') set to event Do. 17.12.2020 17:15-18:00 (VPS: 17.12. 17:15) 'Brisant'

    Dec 5 01:09:00 bigdata vdr: [6355] timer 0 (1 1713-1810 'Brisant') set to event Fr. 18.12.2020 17:15-18:00 (VPS: 18.12. 17:15) 'Brisant'

    Dec 5 01:09:00 bigdata vdr: [6355] timer 0 (1 1713-1810 'Brisant') set to event Mo. 21.12.2020 17:15-18:00 (VPS: 21.12. 17:15) 'Brisant'

    Dec 5 01:09:00 bigdata vdr: [6355] timer 0 (1 1713-1810 'Brisant') set to event Di. 22.12.2020 17:15-18:00 (VPS: 22.12. 17:15) 'Brisant'

    Dec 5 01:09:00 bigdata vdr: [6355] timer 0 (1 1713-1810 'Brisant') set to event Mi. 23.12.2020 17:15-18:00 (VPS: 23.12. 17:15) 'Brisant'

    Kurz darauf erscheint in der timersdone.conf:

    S19.2E-1-1019-10301:1607357640:1607360700:0:Brisant::Mo. 07.12. 17|14 - Das Erste HD

    S19.2E-1-1019-10301:1607444040:1607447100:0:Brisant::Di. 08.12. 17|14 - Das Erste HD

    S19.2E-1-1019-10301:1607530440:1607533500:0:Brisant::Mi. 09.12. 17|14 - Das Erste HD

    S19.2E-1-1019-10301:1607616840:1607619900:0:Brisant:Boulevard-Magazin:Do. 10.12. 17|14 - Das Erste HD

    S19.2E-1-1019-10301:1607703240:1607706300:0:Brisant:Boulevard-Magazin:Fr. 11.12. 17|14 - Das Erste HD

    S19.2E-1-1019-10301:1607789340:1607791920:0:Brisant::Sa. 12.12. 17|09 - Das Erste HD

    S19.2E-1-1019-10301:1607875140:1607877300:0:Brisant::So. 13.12. 16|59 - Das Erste HD

    S19.2E-1-1019-10301:1607962440:1607965500:0:Brisant:Boulevard-Magazin:Mo. 14.12. 17|14 - Das Erste HD

    S19.2E-1-1019-10301:1608048840:1608051900:0:Brisant:Boulevard-Magazin:Di. 15.12. 17|14 - Das Erste HD

    S19.2E-1-1019-10301:1608135240:1608138300:0:Brisant::Mi. 16.12. 17|14 - Das Erste HD

    S19.2E-1-1019-10301:1608221640:1608224700:0:Brisant::Do. 17.12. 17|14 - Das Erste HD

    S19.2E-1-1019-10301:1608308040:1608311100:0:Brisant:Boulevard-Magazin:Fr. 18.12. 17|14 - Das Erste HD

    S19.2E-1-1019-10301:1608567240:1608570300:0:Brisant::Mo. 21.12. 17|14 - Das Erste HD

    S19.2E-1-1019-10301:1608653640:1608656700:0:Brisant::Di. 22.12. 17|14 - Das Erste HD

    S19.2E-1-1019-10301:1608740040:1608743100:0:Brisant::Mi. 23.12. 17|14 - Das Erste HD

    Die Aufnahmen wurden NICHT ausgeführt, d.h. keine Datei auf der Platte.

    Die Datei "epgsearch.log" kann ich nicht finden.

    Edited once, last by andre1964 (December 5, 2020 at 4:31 PM).

    Das sind meine Suchtimer:

    Der Suchtimertest für z.B. Brisant findet die Sendungen auch:

    Die Liste ist natürlich noch deutlich länger.

    nach dem Klick auf Suchtimer Update werden die Timer aber nicht alle gesetzt:


    Das verstehe, wer will... es hat bisher immer geklappt. ;(

    Füge mal in /etc/vdr/conf.d/50-epgsearch.conf die Zeile --logfile=/var/log/epgsearch.log unter [epgsearch] hinzu und starte dann vdr neu. Vielleicht sieht man dann was im Logfile.

    VDR

    Server: Ubuntu 24.04 headless VDR im LXC Container, Plugins: satip (Octopus NET SL SX8), live, epgsearch, epg2vdr, markad

    Clients: LibreELEC auf RasPi3 und RasPi 3+

    Ich nehme mal an, der VDR lauft unter dem User vdr ? Dann hat er keine Rechte die Datei anzulegen.

    sudo touch /var/log/epgsearch.log

    sudo chown vdr:vdr /var/log/epgsearch.log

    vdr neu starten.

    VDR

    Server: Ubuntu 24.04 headless VDR im LXC Container, Plugins: satip (Octopus NET SL SX8), live, epgsearch, epg2vdr, markad

    Clients: LibreELEC auf RasPi3 und RasPi 3+

    Mir fällt gerade was auf:

    Quote from andre1964

    Seit ein paar Tagen jedoch landen über die Suchtimer neu erstellte Timer sofort in der timersdone.conf

    Ja, das muss so sein, da stehen die Timer drin, die er bereits erzeugt hat. Das braucht epgsearch um nicht die gleichen Timer nach manuellem Löschen nochmals zu erzeugen.

    Stelle mal zum Test in den epgsearch Plugin Einstellung unter "Suche und Suchtimer" den Wert von "Timer nach Löschen neu programmieren" auf ja.

    Wie sieht es dann aus ?

    VDR

    Server: Ubuntu 24.04 headless VDR im LXC Container, Plugins: satip (Octopus NET SL SX8), live, epgsearch, epg2vdr, markad

    Clients: LibreELEC auf RasPi3 und RasPi 3+

    LMAA.... :wand

    Ich glaube, das war's!

    Zumindest die Timer sind wieder da nach dem Suchtimerupdate.

    Jetzt stellt sich mir aber die Frage, wie um alles in der Welt wurde das auf NEIN gesetzt????

    Da wir immer über Kodi TV sehen, fummelt doch keiner im VDR-OSD rum... :/

    Wenn DAS tatsächlich der Auslöser war, habe ich da mehrfach drübergelesen, ohne das zu verinnerlichen.

    Schöne Sch...

    Aber trotzdem bedanke ich mich für eure Geduld und Unterstützung!

    Das Wort "Betriebsblindheit" kommt nicht von ungefähr... :D:D:D

    Freu dich nicht zu früh, wir haben damit kein Problem gelöst, sondern nur die Auswirkung beseitigt.

    Der Wert ist per Default auf Nein, und normalerweise macht das auch Sinn.

    Dein eigentliches Problem ist, dass irgend wer oder was deine Timer gelöscht hatte. Nur wirkt sich das jetzt nicht mehr aus, weil sie wieder angelegt werden.

    Behalte das mal im Auge, wer/was hier Timer löscht.

    VDR

    Server: Ubuntu 24.04 headless VDR im LXC Container, Plugins: satip (Octopus NET SL SX8), live, epgsearch, epg2vdr, markad

    Clients: LibreELEC auf RasPi3 und RasPi 3+

    Quote from kfb77

    Freu dich nicht zu früh, wir haben damit kein Problem gelöst, sondern nur die Auswirkung beseitigt.

    Ich fürchte, Du hast recht. Gleich nach dem Suchtimerupdate füllt sich die timersdone.conf

    wieder mit den aktuellen, gerade neu angelegten Timern:

    S19.2E-1-1019-10301:1608577140:1608578400:2:Tagesschau::Mo. 21.12. 19|59 - Das Erste HD

    S19.2E-1-1019-10301:1608663540:1608664800:2:Tagesschau::Di. 22.12. 19|59 - Das Erste HD

    S19.2E-1-1019-10301:1608749940:1608751200:2:Tagesschau::Mi. 23.12. 19|59 - Das Erste HD

    S19.2E-1-1019-10301:1608836340:1608837600:2:Tagesschau::Do. 24.12. 19|59 - Das Erste HD

    S19.2E-1-1019-10301:1608922740:1608923700:2:Tagesschau::Fr. 25.12. 19|59 - Das Erste HD

    S19.2E-1-1019-10301:1609009140:1609010400:2:Tagesschau::Sa. 26.12. 19|59 - Das Erste HD

    S19.2E-1-1019-10301:1607282040:1607287800:6:Tatort| In der Familie (2/2):Fernsehfilm Deutschland 2020:So. 06.12. 20|14 - Das Erste HD

    S19.2E-1-1019-10301:1607886840:1607892600:6:Tatort| Es lebe der König!:Fernsehfilm Deutschland 2020:So. 13.12. 20|14 - Das Erste HD

    S19.2E-1-1019-10301:1608491640:1608497400:6:Tatort| Unten:Fernsehfilm Österreich 2020:So. 20.12. 20|14 - Das Erste HD

    S19.2E-1-1019-10301:1609027440:1609033380:6:Tatort| Unter Wölfen:Fernsehfilm Deutschland 2020:So. 27.12. 01|04 - Das Erste HD

    Ich habe die timersdone.conf bisher immer so verstanden, das dort bereits erledigte Aufnahmen landen,

    oder sehe ich das verkehrt?

    Kann ja alles richtig sein was epgsearch macht. Es kommt auch drauf an wie ein Timer programmiert wird, es gibt ja Optionen wo matchen können die eine neue Aufnahme verhindern.

    Deshalb wäre die Konfiguration für den Timer eine Option mal da nachzusehen.

    Gruß utiltiy

    meine VDR

    vdr03: Antec Remote Fusion, Intel DH67BL, Celeron G1620, GT630, 2x 2GB DDR3 - Hynix, SDA SATA 40GB, SDB SATA 1.5TB, L4M Cine S2 [yaVDR/vdr4arch]
    vdr04: Antec Remote Fusion Micro, Intel DH67BL, Celeron G550, GT630, 2x 2GB DDR3 - Kingston, SDA SATA 160GB WD, SDB SATA 3TB WD Red, L4M Cine S2 [yaVDR/vdr4arch]


    VDR Projects

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login