[gelöst] epgsearch löscht zuviele Timer

  • Bekommst du weiter vorne im Log ne Fehlermeldung von xmltv2vdr das epgsearch nicht gestoppt werden kann?

    Nein, das funktoniert:

    Code
    Jun  5 03:20:02 vdr1 vdr: [14291] EPGSearch: Leaving search timer thread
    Jun  5 03:20:02 vdr1 vdr: [14291] EPGSearch: searchtimer thread ended (pid=14284, tid=14291)


    Und nach dem Import wird es wieder angeschmissen:

    Code
    Jun  5 03:24:24 vdr1 vdr: [14910] EPGSearch: searchtimer thread started (pid=14284, tid=14910)
    Jun  5 03:24:24 vdr1 vdr: [14910] EPGSearch: search timer update started


    Interessant ist auch die Tatsache, das die Timer nach dem Update der xmltv-Datenbank (processed xmltv events) und noch vor dem Ändern des VDR-EPG (importing) gelöscht werden:

    Code
    Jun  5 03:24:21 vdr1 vdr: [14896] xmltv2vdr: 'epgdata2xmltv' processed 12360 xmltv events
    Jun  5 03:24:22 vdr1 vdr: [14284] [core.pids] 0/0: now tuned to source 5300ff40(S19.2E) transponder 1b63b
    Jun  5 03:24:22 vdr1 vdr: [14284] deleting timer 1 (5 0808-0845 'Bezaubernde Jeannie~Tony, bleib bei deinen Leisten!')
    Jun  5 03:24:22 vdr1 vdr: [14284] deleting timer 1 (5 0833-0910 'Bezaubernde Jeannie~Aller Abschied ist schwer')
    Jun  5 03:24:22 vdr1 vdr: [14284] deleting timer 1 (21 2013-0000 'Im Rausch der Tiefe')
    Jun  5 03:24:22 vdr1 vdr: [14896] xmltv2vdr: 'epgdata2xmltv' importing from db


    Gruß


    Joe_D


  • Nein, das sind neue, vom hinzugekommenen Tag,


    Ups, übersehen.


    Also laut VDR Quelltext gibt es drei Möglichkeiten für die Ausgabe "deleting timer".
    1. Per Menübefehl
    2. Per SVDRP
    3. Automatisch wenn sie in der Vergangenheit liegen. (wird im VDR Main loop aufgerufen)


    Kann es sein das der VDR ne falsche Uhrzeit vom Transponder bekommt (aber der VDR kein Recht hat die Systemzeit danach zu stellen)? Das wäre jetzt die einzige Idee die ich noch habe. Weil nach dem Blick in den Quellcode findet das löschen vom VDR direkt statt.


    cu


  • Also laut VDR Quelltext gibt es drei Möglichkeiten für die Ausgabe "deleting timer".
    1. Per Menübefehl
    2. Per SVDRP
    3. Automatisch wenn sie in der Vergangenheit liegen. (wird im VDR Main loop aufgerufen)


    Ja, soweit bin ich im Moment auch. 1 und 2 fallen aus - das wäre in den Logs zu sehen.


    Zitat

    Kann es sein das der VDR ne falsche Uhrzeit vom Transponder bekommt (aber der VDR kein Recht hat die Systemzeit danach zu stellen)? Das wäre jetzt die einzige Idee die ich noch habe.


    Eigentlich nicht, 'Systemzeit stellen' ist aus, die wird per ntp aktuell gehalten. Oder nimmt VDR *immer* die Zeit vom Transponder?


    Was mir schon aufgefallen ist: Der VDR macht fast genau in dem Moment einen Kanalwechsel - und ich hab keine Ahnung warum. Hängt das mit der Namen/PID Aktualisierung zusammen? Denn EPG-Scan steht auf 0.


    Pit

    VDR2: ASRock J4105-ITX, DVBSky S952, openSUSE Tumbleweed, VDR 2.4.7

    softhddevice/vaapidevice, DFAtmo, xmltv2vdr, tvscraper, tvguideng, VDRAdmin-AM (alles git, aber alt)

  • Hm, kannst du den VDR selber bauen?


    Ich würde jetzt im VDR Quelltext alle Zeilen mit
    ---
    isyslog("deleting timer %s", *ti->ToDescr());
    ---
    So ändern das zu sehen ist welcher dieser da überhaupt triggert.


    z.B.
    ----
    isyslog("deleting timer (menu.c -> cMenuTimers::Delete) %s", *ti->ToDescr());
    ----
    usw.


    Wenn du den dann hast dann schauen von wo der aufgerufen wird. Dort dann weitere syslogs (halt gezielt bis zur Quelle durchhangeln). Dann sollte sich der Trigger finden lassen.



    Normal (im Sinne das jeder das Problem kennt) ist das jedenfalls nicht.


    cu

  • Hm, kannst du den VDR selber bauen?


    Klar doch - oder gibt's schon fertige 1.7.28-er?


    Zitat

    Ich würde jetzt im VDR Quelltext alle Zeilen mit
    ---
    isyslog("deleting timer %s", *ti->ToDescr());
    ---
    So ändern das zu sehen ist welcher dieser da überhaupt triggert.


    Zwei Dumme und so... :D
    Hab' ich grad schon gemacht und werd's mal verfolgen


    Danke für's Brainstormen erstmal!

    VDR2: ASRock J4105-ITX, DVBSky S952, openSUSE Tumbleweed, VDR 2.4.7

    softhddevice/vaapidevice, DFAtmo, xmltv2vdr, tvscraper, tvguideng, VDRAdmin-AM (alles git, aber alt)

  • Mein cronjob, der checkt, ob mir Timer gelöscht wurden, ist jetzt angesprungen.
    Und ich bestätige jetzt mal, was hier schon im Thread steht.
    Das ist nicht epgsearch , sondern der vdr, wie mir die pid und das epglog zeigt.
    syslog:


    Wobei der Dino-Planet noch nichtmal von epgsearch ist.
    Die PID 10019 ist vom VDR.
    Zur fraglichen Zeit im epgsearch.log:

    Code
    Son 17.06.2012 06:18:00: timer conflict check started
    Son 17.06.2012 06:18:00: timer conflict check finished
    Son 17.06.2012 06:35:00: search timer update started
    Son 17.06.2012 06:35:04: analysing repeats for search timer 'Friends'...
    Son 17.06.2012 06:35:04: 7/7 events need a timer for search timer 'Friends'
    Son 17.06.2012 06:35:04: skip timer for 'Friends~Die guten Vorsätze' (Son 17.06.2012 - 13:34); search timer: 'Friends' - already done
    Son 17.06.2012 06:35:04: skip timer for 'Friends~Das Arbeitslachen' (Son 17.06.2012 - 13:59); search timer: 'Friends' - already done
    Son 17.06.2012 06:35:04: skip timer for 'Friends~Die beste Massage der Welt' (Son 17.06.2012 - 14:23); search timer: 'Friends' - already done
    Son 17.06.2012 06:35:05: skip timer for 'Friends~Das kollektive Geheimnis' (Son 17.06.2012 - 14:46); search timer: 'Friends' - already done
    Son 17.06.2012 06:35:05: skip timer for 'Friends~Mädchenprügel' (Son 17.06.2012 - 15:10); search timer: 'Friends' - already done


    Der will die also wieder rein machen, kann aber nicht, weil er meint, das schon getan zu haben.


    Also der VDR und zweifellos hat auch der externe Import damit zu tun.

    Synchronisieren und Backup auch unter Linux! 250MB extra für euch und mich bei Dropbox-Anmeldung (zu den kostenlosen 2GB), wenn ihr meinen Referral nutzt.

  • Trying to make sense of this thread with Google translate and bit unsure if there's currently solution? I'm having same problem, when xmltv2vdr plugin updates EPG something is triggered and all(?) timers for that day get deleted. Configuring epgsearch to put deleted timers back helps, but any manual timers are lost for good. Also any currently active timers get stopped when EPG is updated. I'm running latest xmltv2vdr and epgsearch versions (pulled from git 24.6.2012) on VDR 1.7.28. EPG processing seems to be quite resource intensive as there's sometimes dropped frames. Enlarging buffers helps but doesn't completely fix that part. Hardware should be more than fast enough for this purpose (Core-i5, 4GB ram and 160GB Intel G2 SSD).


    Timers are deleted by code in timers.c. I added comments after each "deleting timer" string present in sources. I guess I could comment that out and delete expired timers manually until proper fix is found.


    Log below is from last night when running couple days older xmltv2vdr version. I've tried with latest as of right now and same problem is present.


  • Hi johu,


    please try latest GIT version of xmltv2vdr - i changed a few things a few minutes ago.


    Code
    Jun 24 03:41:49 foofoo vdr: [20764] deleting timer (timers.c) 334 (103 1800-1910 'World's Greatest Motorcycle Rides: New Zealand Pt1')
    Jun 24 03:41:49 foofoo vdr: [20764] deleting timer (timers.c) 334 (103 1900-2010 'World's Greatest Motorcycle Rides: New Zealand Pt2')
    Jun 24 03:41:49 foofoo vdr: [19243] xmltv2vdr: 'vdrepg01' importing from db

    That's very confusing, cause xmltv2vdr is changing vdr events only after the "importing from db" line and the timers got deleted before :(


    Greetings


    Joe_D

  • Hi johu,


    please try latest GIT version of xmltv2vdr - i changed a few things a few minutes ago.

    Hi. I just updated to git commit 7e4be58b957cac92e5fbb345fc919012b4cb9d32. After restart xmltv2vdr EPG update cycle was ran successfully without deleting timers. I'll let you know if problem still occurs, but looks good so far.

  • Looks like there's still something causing unexpected timer deletions during xmltv2vdr epg update cycle. I moved epg update to time when there's usually nothing to record and enabled "recreate deleted timers" on epgsearch as a workaround. Could this problem be something in epgsearch not liking xmltv2vdr? Spotted note below on epgsearch docs that sounds it might be related. I'll try adding commands to stop epgsearch when xmltv2vdr is running to see if it helps.


    Important: if you get your EPG from external sources make sure that search timer updates are disabled while your EPG is updated. The reason for this is that epgsearch will remove timers without events assigned to them. This situation can exist while the new EPG is feeded to VDR. A simple way to disable search timer updates is to use the SVDRP command SETS in your EPG update script.

  • Dass mit dem Import läuft bei mir jetzt recht stabil. Da wird nichts mehr rausgeworfen.
    Aber epgsearch löscht trotzdem noch Timer auch ohne, dass der Import läuft.


    Ich hab gesagt, Timer setzen mit 1 Wiederholung.


    epgsearch.conf

    Code
    90:Being Human:0:::0:0:0:0:1:0:0:0:::1:0:0:1:%Serie%:76:99:5:10:0:0:0::1:1:1:1:0:0:0:0:0:0:0:0::1:0:0:0:0:0:0:0:0:0:90::0


    Was bedeutet: erlaubte Wiederholungen 1


    timers.conf

    Code
    1:S19.2E-133-5-776:2012-08-16:2055:2155:76:99:Serien~Being Human~01x01-Zimmer ohne Aussicht:<epgsearch><channel>10 - SIXX</channel><searchtimer>Being Human</searchtimer><start>1345143300</start><stop>1345146900</stop><s-id>90</s-id><eventid>8701</eventid></epgsearch>


    1 Timer ist gesetzt.
    Der 2. war auch gesetzt. Ist aber heut einfach rausgeflogen. Warum?


    epgsearch.log

    Code
    Don 16.08.2012 13:46:03: analysing repeats for search timer 'Being Human'...                                                                                                                             
    Don 16.08.2012 13:46:03: 2/5 events need a timer for search timer 'Being Human'                                                                                                                          
    Don 16.08.2012 13:46:04: modified timer 59 for 'Being Human~Zimmer ohne Aussicht' (Don 16.08.2012 - 21:00); search timer: 'Being Human'                                                                  
    Don 16.08.2012 13:46:04: delete timer for 'Being Human~Zimmer ohne Aussicht' (Fre 17.08.2012 - 00:34, channel 10)                                                                                        
    Don 16.08.2012 13:46:04: delete timer 73


    Selbe Zeit im syslog

    Code
    Aug 16 13:46:04 titan vdr: [9838] connect from 127.0.0.1, port 48505 - accepted                                                                                                                          
    Aug 16 13:46:04 titan vdr: [9838] timer 59 (10 2055-2155 'Serien~Being Human~01x01-Zimmer ohne Aussicht') modified (active)                                                                              
    Aug 16 13:46:04 titan vdr: [9838] closing SVDRP connection                                                                                                                                               
    Aug 16 13:46:05 titan vdr: [9838] connect from 127.0.0.1, port 48506 - accepted                                                                                                                          
    Aug 16 13:46:05 titan vdr: [9838] deleting timer 73 (10 0029-0127 'Serien~Being Human~01x01-Zimmer ohne Aussicht')                                                                                       
    Aug 16 13:46:05 titan vdr: [9838] closing SVDRP connection


    timersdone.conf

    Code
    S19.2E-133-5-776:1345143334:1345146912:90:Being Human:Zimmer ohne Aussicht:Don 16.08. 20|55 - SIXX
    S19.2E-133-5-776:1345156171:1345159656:90:Being Human:Zimmer ohne Aussicht:Fre 17.08. 00|29 - SIXX
    S19.2E-133-5-776:1345143346:1345146914:90:Being Human:Zimmer ohne Aussicht:Don 16.08. 20|55 - SIXX
    S19.2E-133-5-776:1345156157:1345159630:90:Being Human:Zimmer ohne Aussicht:Fre 17.08. 00|29 - SIXX
    S19.2E-133-5-776:1345143347:1345146919:90:Being Human:Zimmer ohne Aussicht:Don 16.08. 20|55 - SIXX


    Kann das jemand erklären oder noch besser weiterhelfen?


    Faudeer

    Synchronisieren und Backup auch unter Linux! 250MB extra für euch und mich bei Dropbox-Anmeldung (zu den kostenlosen 2GB), wenn ihr meinen Referral nutzt.

  • Da es heut schon wieder passiert ist, antworte ich gleich mal selber.
    WIE ES SCHEINT, liegt es bei mir an doppelten EPG Einträgen. Bei SIXX hab ich das Problem, dass viele EPG Einträge doppelt vorhanden sind.
    Gestern hatte ich von einem Suchtimer noch 3 Timer gesetzt bekommen. Und heute ist im EPG für 2 der Sendungen ein weiterer gleicher EPG Eintrag hinzugekommen.
    Und genau diese beiden wurden von EPG Search auch gelöscht.
    Der 3. hat keinen 2. EPG Eintrag bekommen und wurde auch nicht gelöscht.


    Das ist also nicht unbedingt ein EPG Search Fehler, sollte aber wohl auch gelöst werden.


    [EDIT]Ja, mit einem frischen EPG und nur einem Eintrag pro Sendung, sind auch alle 3 Timer wieder da.[/EDIT]

    Synchronisieren und Backup auch unter Linux! 250MB extra für euch und mich bei Dropbox-Anmeldung (zu den kostenlosen 2GB), wenn ihr meinen Referral nutzt.

    Einmal editiert, zuletzt von Faudeer ()

  • Doppelte EPG Einträge darf es aber gar nicht geben. Aber ich kann es bestätigen, ist ein EPG Eintrag doppelt (selbe Event ID, leicht unterschiedliche Startzeiten) dann wird der von epgsearch sicher ignoriert.


    Also die Frage ist wo kommen die bei dir her? SIXX sendet häufiger neues EPG mit leicht abweichenden Startzeiten, aber damit kommt der VDR problemlos klar.


    cu

  • Tja, wenn ich das wüßte ....


    Gehört zwar nicht hierher:
    Ich habe ein yavdr und da gibt es ja auch einen Thread zu dem Thema in dem es heißt, xmltv2vdr hilft. Hab ich probiert und bei mir sind die doppelten Einträge erstmal weg.
    Falls wer an einer echten Lösung baut und meine Testhilfe brauch, ich bin dabei.


    Faudeer

    Synchronisieren und Backup auch unter Linux! 250MB extra für euch und mich bei Dropbox-Anmeldung (zu den kostenlosen 2GB), wenn ihr meinen Referral nutzt.

Jetzt mitmachen!

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