Arte EPG verhindert Suchtimeraufnahmen

  • Ich verstehe zuerst nicht, wie EPG-Einträge gemischt werden können, wenn nicht die Id des Kanals identisch ist. Und identische Einträge in der channels.conf sollten doch nicht vorkommen?

    vdr-2.4.0
    softhddevice, chanman, cdda, dbus2vdr, dvd, dynamite, epgsearch, femon, filebrowser, graphlcd, graphtftng,
    menuorg, osdteletext, radio, recsearch, streamdev-server, vdrmanager, vnsiserver

    linux-3.13.0 M3N78-VM (Nvidia 8200) CIne CT-V7 DVB-C
    yavdr-0.6 als Basis mit vielen Änderungen

  • Hab gerade festgestellt, daß auf meinem Testsystem mit vdr (2.2.0-5build1) xenial der besagte EPG-Eintrag nicht vorhanden ist, bei identischer Kanalliste

  • So, die heutige Aufnahme auf Arte hat auch geklappt :).



    Weißt Du denn welcher das ist?

    Nein.

    Das würde auch einiges an Aufwand machen das festzustellen.

    Hab gerade festgestellt, daß auf meinem Testsystem mit vdr (2.2.0-5build1) xenial der besagte EPG-Eintrag nicht vorhanden ist, bei identischer Kanalliste

    Das kann durchaus sein.

    Da arbeiten zwei EPG-Quellen gegeneinander, das Ergebnis hängt vom Timing ab.

    Es sind also Abhängigkeiten von der Anzahl der DVB-Karten, deren Tuninggeschwindigkeit oder was auch immer denkbar.

    Bei mir kommen die Einträge ja auch immer nur in Blöcken (siehe oben), eine wirkliche Erklärung habe ich dafür auch nicht.


    Ich verstehe zuerst nicht, wie EPG-Einträge gemischt werden können, wenn nicht die Id des Kanals identisch ist. Und identische Einträge in der channels.conf sollten doch nicht vorkommen?

    Das Problem ist, dass nur die Id ausgewertet wird, die mit dem Paket kommt. Es wird nicht ausgewertet wo her das Paket kommt!


    Beispiel:

    Kanal A (wie Arte ;)), mit einer eindeutigen Kanal ID I (römisch 1), läuft auf Transponder 1.

    Die EPG-Daten-Pakete von diesen Kanal mit der ID I werden auch auf dem Transponder 1 gesendet.

    Der vdr nimmt jetzt alle EPG-Daten-Pakete, in denen steht, dass sie für den Kanal mit der ID I sind und baut daraus das EPG für unseren Kanal A.


    Ein anderer Kanal, nennen wir ihn XY, auf einem beliebigen anderen Transponder, nennen wir ihn 2345, sendet jetzt auch EPG-Daten-Pakete fmit der Kanal ID I. Diese EPG-Daten-Pakete enthalten keine sinnvollen Programmdaten, sind (fälschlicherweise) korrekt mit Kanal ID I für Kanal A adressiert.

    Klar, Kanal XY sollte das eigentlich nicht, weil er überhaupt nichts mit Kanal A zu tun hat, er macht es aber trotzdem.

    Nun nimmt der VDR auch diese Datenpakete und baut sie ins EPG von Kanal A ein, was natürlich Chaos im EPG führt.


    Mein Patch sorgt jetzt dafür, das EPG-Daten-Pakete für Kanal mit der ID I nur noch von dazugehörigen Transponder 1 zugelassen werden. (Kanal XY bekommt nur EPG-Daten von Transponder 2345, usw.)

    Da ich die Paket-Quelle vom Filter verwende und mich nicht auf den Inhalt des Paketes verlasse, ist er auch garantiert immun gegen falsch adressierte Pakete.

    Gruss
    SHF


  • Mein Vorschlag von hier würde zwar alle solchen Events in der Zukunft ausschließen, aber sobald sie in die "now/next" Table kommen, würden sie wieder geparst werden. Denn wie hier zu sehen ist, befindet sich der störende Event in Table 0x4F (also "now/next other TS").

    Die Änderung müsste also so aussehen:

    Bitte testen!


    Klaus

  • Nach dem ich gestern den Filter deaktiviert hatte, wurde auf Arte nichts mehr aufgenommen. Diesmal hab ich aber ein Logfile von EPGsearch!


    Interessant sind die Zeilen 26 und 33, denke ich:

    Was da genau passiert ist, verstehe ich aber noch immer nicht.

    Als wenn da jemand eine Idee hätte...



    Jetzt kommt aber erstmal der Test von Klaus Filter.

    Gruss
    SHF


  • Inzwischen konnte ich nachvollziehen, was EPGsearch macht und es funktioniert gemäss Spezifikation - irgendwie.


    Der Timer wird nach ändern des Events gelöscht, da das "defekte" Event nicht mehr auf die Suche passt.

    Es existiert zwar auch eine Sicherung für einen EPG-Ausfall ("no event"), aber die greift nicht. Das "defekte" Event ist nunmal ein Event und prinzipiell in Ordnung.


    Nicht mehr angelegt wurde der Timer wegen der Einstellung "Timer nach löschen neuprogrammieren". Steht die auf "nein", was auch bei mir der Fall war (warum auch immer), werden Timer pro Event nur einmal angelegt.

    Als workaround reicht es "Timer nach löschen neuprogrammieren" auf "ja" zu setzen, dann klappt es wieder mit dem Aufnehmen. Zumindest in den meisten Fällen wird es klappen, eine 100% Sicherheit gibt es aber nicht.


    Diese Funktion war eigentlich dafür gedacht, vom Benutzer gelöschte Timer gelöscht zu lassen. Warum auch von EPGserach selber gelöschte Timer nicht neu programmiert werden sollen verstehe ich aber nicht.

    Entweder das Löschen aus der "timersdone.conf" geht schief oder es ist Absicht.




    Den geänderten EIT-Filter habe ich ausprobiert.

    Ich habe zwar die Abfrage invertiert und in die EIT() gesetzt, aber das sollte keinen Unterschied machen

    Code
    1. if (!(Tid == 0x4E || Tid >= 0x50 && Tid <= 0x5F))
    2. return;

    Das war lediglich um mir das Umschalten zwischen den Filtern im Betrieb zu gestatten, zwecks Vergleich.


    Was das fragliche Event angeht: Da haben wir Glück, auch der Filter beseitigt es aus dem EPG von Arte.



    Da ich jetzt aber neugierig war und wissen wollte, ob auch wirklich alle transponderübergreifenden Events abgefangen werden, habe ich (optional) noch das folgende nachgeschaltet:

    Code
    1. if (channel->Transponder() != Src_Channel->Transponder()) isyslog("InvalidEPG tp:%d -> ch:%d Tid:%d ", Src_Channel->Transponder(), channel->Number(), Tid);


    Zunächst kam, wie erwartet nichts. Auch der gestartete EPG-Scan lief -geschätzt- bis zur Hälfte ohne eine Meldung, aber dann ging es los:

    Code
    1. InvalidEPG tp:111836 -> ch:27 Tid:55
    2. InvalidEPG tp:111836 -> ch:28 Tid:51
    3. InvalidEPG tp:111836 -> ch:172 Tid:52
    4. InvalidEPG tp:111836 -> ch:29 Tid:50
    5. InvalidEPG tp:111836 -> ch:153 Tid:4E
    6. InvalidEPG tp:111836 -> ch:29 Tid:51
    7. InvalidEPG tp:111836 -> ch:172 Tid:53
    8. InvalidEPG tp:111836 -> ch:153 Tid:50
    9. ...

    Es kam so viel, dass ich den Test umgehend abbrechen musste.

    Das ist so viel, das können nicht nur ein paar fehlerhafte Pakete sein.


    Aber es kommt noch besser: Ich habe nicht schlecht gestaunt, als ich Kanäle und Transponder identifiziert hatte :wow.

    Es ist nämlich niemand anderes als die ARD, die sowas senden. Der Transponder ist der "Haupttransponder" mit dem ersten Programm und die Kanäle sind sämtlich diverse Dritte.



    Nach der Erfahrung möchte ich nochmal dringend für eine echte Transponderbindung plädieren.

    Nur die wird in Zukunft derartige Problem zuverlässig beseitigen.

    Und wenn doch mal was im EPG schief läuft, ist man sicher, dass der Fehler vom Transponder des Kanals kommt. Das erleichtert die Fehlersuche ungemein.


    Das soll aber nicht heissen, das ich es ungetestet auf die User los lassen würde. Mir wäre das, bei beiden Varianten, zu heiss.


    IMHO wäre es sinnvoll, dass es auch mal jemand, der die "on demand" Kanäle von SKY benutzt, ausprobiert. Die scheinen ja immer etwas heikel mit den Updates zu sein und ich kann da nichts testen.

    Gruss
    SHF


  • Deshalb deaktiviere ich epgsearch-Timer, statt sie zu löschen.

    Dito, bei nächtlicher Wiederholung z. B., weil sie sonst wieder erscheinen - die Neuprogrammierungsfunktion scheint also aktiv, ist bei mir aber bekanntermaßen nicht als Workaround geeignet

    Dieser Beitrag wurde bereits 1 Mal editiert, zuletzt von rudibert ()

  • Deshalb deaktiviere ich epgsearch-Timer, statt sie zu löschen.

    Mach ich auch, allein schon aus Gewohnheit so. Ich war Jahrelang mit einer frühen Version ohne dieses Feature unterwegs.


    die Neuprogrammierungsfunktion scheint also aktiv, ist bei mir aber bekanntermaßen nicht als Workaround geeignet

    Eventuell verbessert es die Chancen, wenn du Arte als Startkanal setzt.


    Schau aber trotzdem noch mal im Menü nach Einstellungen->Plugins->epgsearch->Suche und Suchtimer->Timer nach Löschen neuprogrammieren.

    Die Funktion hat, denke ich eine, Macke.



    Entweder das Löschen aus der "timersdone.conf" geht schief oder es ist Absicht.

    Ich denke inzwischen ersteres.

    Der Timer wird mittels dieser Funktion gelöscht.

    Ab Zeile 755ff soll auch der Eintrag in der timersdone.conf gelöscht werden, so dass der Timer erneut programmiert werden kann.

    Der aus der timersdone.conf zu entfernende Timer wird u.a. anhand des Event bestimmt. Das kommt vom zu löschenden Timer.

    Wenn dieser aufgrund einer Änderung des Events zum Löschen ansteht, wird das problematisch, weil das das Event beim Löschen nicht mehr mit dem beim Erstellen zusammenpasst.




    Für die, die die Transponderbindung fürs EPG mal selber probieren wollen, habe ich noch mal einen minimal Patch angehängt.

    Dieses mal aufs nötigste reduziert, nur 4 Änderungen in der eit.c

    Die Version 22 ist für VDR 2.2 und früher, die 24 ab der aktuellen 2.3.9.

    Dateien

    Gruss
    SHF


    Dieser Beitrag wurde bereits 2 Mal editiert, zuletzt von SHF ()

  • Schau aber trotzdem noch mal im Menü nach Einstellungen->Plugins->epgsearch->Suche und Suchtimer->Timer nach Löschen neuprogrammieren.

    Die Funktion hat, denke ich eine, Macke.

    Danke - Hab es doch anschalten müssen. Mal sehen ob es was bringt

    Macke hin oder her - ist immerhin eine beta!…

    Dieser Beitrag wurde bereits 1 Mal editiert, zuletzt von rudibert ()

  • So, inzwischen hab ich auch einen Patch für EPGsearch gebastelt.

    Damit werden beim Vergleichen mit der timersdone.conf Titel und Beschreibung ignoriert und nur noch nach Kanal, Start- und Endzeit und SuchtimerID gearbeitet.

    Das sollte jetzt eigentlich dazu führen, dass der Timer aus der timersdone.conf gelöscht wird, auch wenn sich das Event geändert hat.

    Bislang ist das aber noch ungetestet! Da die geänderte Funktion aber nur in diesem Zusammenhang aufgerufen wird, sind wenigstens keine Nebenwirkungen an anderer Stelle zu befürchten

    Dateien

    Gruss
    SHF


  • Meine Gedanken dazu:

    Mit eingeschaltetem VPS beim Suchtimer würde das Problem nicht auftreten, weil das ARTE-Event von 6:00-6:00 keine VPS-Zeit trägt.

    Das "set to event" kommt vom VDR. Der findet den Schedule ab 6:00 vor dem von 12:50 und sagt, zu der im Timer angegebenen Zeit läuft etwas ganz anderes. Das ist erstmal OK.

    Das muss dann epgsearch berücksichtigen. Ich muss mir noch mal die GetTimer()-Routine im searchtimer_thread anschauen.

    Mit dem timerdone_eventchanged.diff kann es immer noch passieren, wenn der Suchtimerupdate z.B. 10 Minuten vor dem event läuft, dass der timer erstmal gelöscht wird und auch entsprechend in der timerdone, aber erst beim nächsten Suchtimerlauf wiederhergestellt wird (oder dann nicht mehr, weil zu spät).


    Verursacher ist aber erstmal der Erzeuger des falschen EPG-Eintrags. Eigentlich dürfte doch die eventid und die channel-Id nicht gleich sein.

    vdr-2.4.0
    softhddevice, chanman, cdda, dbus2vdr, dvd, dynamite, epgsearch, femon, filebrowser, graphlcd, graphtftng,
    menuorg, osdteletext, radio, recsearch, streamdev-server, vdrmanager, vnsiserver

    linux-3.13.0 M3N78-VM (Nvidia 8200) CIne CT-V7 DVB-C
    yavdr-0.6 als Basis mit vielen Änderungen

  • Mit eingeschaltetem VPS beim Suchtimer würde das Problem nicht auftreten, weil das ARTE-Event von 6:00-6:00 keine VPS-Zeit trägt.

    VPS hab ich noch nicht probiert.

    Könnte ich bei Gelegenheit aber noch mal machen.

    Das muss dann epgsearch berücksichtigen. Ich muss mir noch mal die GetTimer()-Routine im searchtimer_thread anschauen.

    Soweit ich das nachvollziehen konnte, findet EPGsearch den Timer zwar, löscht ihn aber weil das Event nicht mehr zur Suche passt.

    (Bei mir Titel und Startzeit)

    Mit dem timerdone_eventchanged.diff kann es immer noch passieren, wenn der Suchtimerupdate z.B. 10 Minuten vor dem event läuft, dass der timer erstmal gelöscht wird und auch entsprechend in der timerdone, aber erst beim nächsten Suchtimerlauf wiederhergestellt wird (oder dann nicht mehr, weil zu spät).

    Ja, das könnte passieren.

    Der Patch soll auch primär den Bug, dass von EPGsearch selbst gelöschte Timer nie wieder angelegt wird, beseitigen. Das ist IMHO nämlich definitiv nicht sinnvoll.


    Wenn das Event zum Beginn der Aufnahme falsch ist, ist es aber genauso ein Problem.

    Man könnte zwar generell darauf verzichten einmal gesetzte Timer zu löschen oder zu kürzen, aber ob das sinnvoll ist?


    Ich bin auch noch nicht dazu gekommen das zu testen was passiert.

    Eventuell erstellt EPGsearch den neuen Timer nämlich schon beim selben Durchlauf.


    Verursacher ist aber erstmal der Erzeuger des falschen EPG-Eintrags. Eigentlich dürfte doch die eventid und die channel-Id nicht gleich sein.

    So wie es in diesem Fall war, ist es, je nach Auslegung des Standards, durchaus zulässig.

    Es wird gefordert, dass die eventids innerhalb eines TS eindeutig sind. (oder war es innerhalb eines Kanales eines TS? ist aber hier auch unerheblich...)

    Die Fraglichen Events wurden aber auf einem anderen Transponder als dem von Arte gesendet. Korrekt deklariert als EPG für einen anderen Kanal (und nur deshalb funktioniert Klaus Patch!) mit dessen channel-Id (der von Arte). Die EventID ist in diesem Transponder auch eindeutig (bzw. ich nehme es mal so an, da ich den Transponder nicht kenne).

    Diese EventID überschneidet sich aber mit einer im "echten" EPG von Arte.

    Da ich nirgends die Forderung gelesen habe, dass das EPG zu einer Channel-ID aus unterschiedlichen Quellen identisch sein muss, ist das durchaus auch zulässig.

    Gruss
    SHF


  • Mit eingeschaltetem VPS beim Suchtimer würde das Problem nicht auftreten, weil das ARTE-Event von 6:00-6:00 keine VPS-Zeit trägt.

    Das hilft leider nicht.

    Der Timer wurde trotz VPS heute gelöscht

    Gruss
    SHF


  • Obwohl ich bei mir so einen störenden Eintrag in die epg.data reingemischt habe, kann ich das Verhalten (zumindest mit 2.3.9) nicht reproduzieren. Zur Analyse bräuchte ich eine mit -v3 erstellte epgsearch.log und am besten noch setup.conf, epgsearch.conf, timersdone.conf, epgsearchdone.data (die letzteren am besten vor und nach dem Löschen). Evtl. auch noch die beiden relevanten Einträge der epg.data.

    vdr-2.4.0
    softhddevice, chanman, cdda, dbus2vdr, dvd, dynamite, epgsearch, femon, filebrowser, graphlcd, graphtftng,
    menuorg, osdteletext, radio, recsearch, streamdev-server, vdrmanager, vnsiserver

    linux-3.13.0 M3N78-VM (Nvidia 8200) CIne CT-V7 DVB-C
    yavdr-0.6 als Basis mit vielen Änderungen

  • Obwohl ich bei mir so einen störenden Eintrag in die epg.data reingemischt habe, kann ich das Verhalten (zumindest mit 2.3.9) nicht reproduzieren.

    Der komische Event allein ist nicht das Problem, da muss noch irgendwas anders dazu kommen.

    Der Timer existiert ja eine ganze Weile trotz des Events und wird irgendwann plötzlich gelöscht.


    Meine Vermutung ist, dass das "echte"EPG kurz aussetzt oder Arte die EventIDs einmal täglich wechselt.

    Zur Analyse bräuchte ich eine mit -v3 erstellte epgsearch.log

    Mit oder ohne EPG?

    Ohne EPG habe ich die relevanten Teile hier schon gepostet.

    Mit EPG müsste ich noch machen, das schaffe ich aber wohl erst nächste Woche.


    timersdone.conf, epgsearchdone.data (die letzteren am besten vor und nach dem Löschen)

    In der timersdone.conf erscheint der Timer beim Erstellen und irgendwann verschwindet er daraus auch wieder.

    Ich kann aber leider nicht sagen wann, da die Timer zu den unmöglichsten Urzeiten gelöscht werden (typischer weise zwischen 5 und 6 Uhr Morgens).


    In der epgsearchdone.data tauchen sie nicht auf, da ich "Wiederholungen vermeiden" bei dem Testimer nicht verwende um das als Ursache auszuschliessen

    Gruss
    SHF


  • Das hilft leider nicht.

    Der Timer wurde trotz VPS heute gelöscht

    Kann ich bestätigen, obwohl es mit VPS doch häufiger zur Aufnahme kommt

  • SHF :

    wie ist denn eigentlich der letzte Stand in der Sache? Benutzt du jetzt irgendwelche Patches, um das Problem zu beheben?

    SAT Hardware: Gibertini SE75 | DuraSat Dur-Line UK-24 | DD OctopusNET V2 Rack (Firmware 1.0.81) mit MaxS8
    Server: Asus M5A78L-M/USB3 | Sempron 145@2Cores | 8GB ECC RAM | PicoPSU | Debian Stretch 64Bit | VDR 2.4.0 mit SAT>IP, epgsearch, epg2vdr, vdr-epg-daemon
    Clients: RaspberryPI 2/3 | Yocto Poky Linux (Openembedded) 2.5+git | Linux Kernel 4.14+git | VDR 2.4.0 mit SAT>IP, RpiHDDevice, SkinDesigner, Remote, Graphlcd-ax206dpf, Extrecmenu, Femon, Mlist


    R.I.P: Gigaset M740 mit VDR von open7x0.org