Arte EPG verhindert Suchtimeraufnahmen

    Quote from tomhog

    Also wenn ich auf 10788:V durch die Kanäle zappe fange ich mir den 6 Uhr EPG-Eintrag ein.

    Das ist doch ein ganz anderer Transponder, wie kann denn das sein?

    Ich ging immer davon aus, dass das EPG auf dem gleichen Kanal wie der Sender kommt und kommen muss.


    Auf 10788:V sind auch keine Kanäle, die ich je gesehen habe.

    Ist es irgendwie möglich, den Transponder beim EPGscan zu ignorieren?

    Würde es schon reichen, die fraglichen Kanäle zu löschen und das hinzufügen von neuen Kanälen zu unterbinden?


    Heute Abend hatte ich mal kurz einen noch merkwürdigeren Eintrag im EPG von Arte.

    Irgendwas mit Boxen am 01.01.1970. War leider schon weg, bevor ich es sichern konnte.



    Ich hab da auch noch ein paar Fagen an die Insider zum Thema EPGscan und Timer.

    Wäre schön, wenn da jemand kurz was zu schreiben könnte. Das würde mir viel Zeit sparen.


    Die Meldungen "timer x ... set to event" [x != 1] kommen laut PID vom VDR selber.

    Ich sehe da keine Meldung von EPGsearch.

    Die Änderungen werden also vom VDRcore und nicht EPGsearch veranlasst?


    Der EPGscan tauscht den alten EPG gegen den neu erscannten EPG einfach nur aus?

    Anderenfalls müsste ich mich an der Stelle auch noch einlesen.

    Gruss
    SHF


    Die Meldungen "timer set to event" kommen vom vdr immer dann, wenn ein neues Timer-Objekt angelegt wird. Das Plugin epgsearch erzeugt z.B. ausser beim wirklichen Neuerstellen eines Timers beim Konfliktcheck für sich Clones der bestehenden Timer.

    vdr-2.6.9

    softhddevice, dbus2vdr, dvd, epgsearch, femon, graphtftng, web, menuorg,
    osdteletext, radio, recsearch, satip, tvguide, vnsiserver
    ubuntu focal, yavdr-ansible, linux-5.15 ,AsRock J4105, CIne CT-V7 DVB-C

    TomJoad

    Danke für die für die Antwort.

    Dass die Meldungen vom VDR stammen, war mir inzwischen schon klar (PID).


    Ich glaube ich war bei der Fragestellung missverständlich.

    Es geht mir um die folgen Einträge aus dem Log vom weiter oben:

    Code
    Mar  8 04:59:33 vdr vdr: [4741] timer 36 (12 0705-0730 'aaab~ARTE Journal Junior~Nachrichten von und für Kinder von 8 bis 12') set to event Don 08.03.2018 06:00-06:00 'ARTE'
Mar  8 04:59:33 vdr vdr: [4741] timer 37 (12 1245-1315 'aaaa~ARTE Journal~Die Mittagsausgabe des europäischen Nachrichtenmagazins') set to event Don 08.03.2018 06:00-06:00 'ARTE'
Mar  8 04:59:33 vdr vdr: [4741] timer 53 (12 1210-1305 'aaab~Re: Die Last der Schulden~Wenn das Geld nicht reicht') set to event Don 08.03.2018 06:00-06:00 'ARTE'
Mar  8 04:59:33 vdr vdr: [4741] timer 54 (12 1255-1405 'aaab~Stadt Land Kunst~Das Serbien von Kusturica / Zanzibar / Schloss Lunéville') set to event Don 08.03.2018 06:00-06:00 'ARTE'

    Die Timer existieren mit der Nummer und werden nur geändert, weil sich das EPG ändert.

    Jetzt die Frage:

    Wer veranlasst das? Der VDR selber oder macht das EPGsearch?




    Ich war inzwischen aber nicht untätig und habe dieses Skript auf den VDR losgelassen:

    Bash
    #!/bin/bash

while true ;do
   if [ $(svdrpsend lste S19.2E-1-1051-28724 | grep -c "El canal de televis") != "0" ] ;then
      svdrpsend clre S19.2E-1-1051-28724 >/dev/null 2>&1
      logger -t "arteEPG testskript" "EPG geloescht!"
   fi
   sleep 60
done

    Ziel war es überhaupt mal heraus zu bekommen, wann und wie oft dieser komische Event gesendet wird.


    Das Ergebnis ist echt erstaunlich:

    Das geht den ganzen Tag lang so und auch immer in den Blöcken.

    Allerdings lief dabei die ganze Zeit Arte im Live-TV.



    Im folgenden noch zusammen mit den restlichen Meldungen.

    Ich hatte immer die Vermutung, dass es mit dem EPGscan zusammenhängt.

    Aber irgend ein Schema kann ich nicht erkennen.


    Den EPGscan alle 30 Minuten, den startet wohl auch EPGsearch, nehme ich an?



    Die spanischen Kanäle von weiter oben habe ich übrigens aus der channels.conf entfernt und das Hinzufügen unterbunden.

    Die können also eigentlich nicht mehr die Ursache sein.



    Nebenbei habe ich auch noch Verwandschaft genervt und deren Receiver probiert:

    Bei keinem sind mir diese Fehler im EPG aufgefallen. Selbst bei reinen DVB-S-Geräten ist das EPG in Ordnung.

    Beim VDR bei mir dauert es maximal eine halbe Stunde, dann ist das EPG wieder durcheinander.


    Meine Vermutung ist jetzt, dass irgend ein an derer Kanal diese falschen Informationen für Arte mit liefert.

    Testweise müsste man deren Auswertung mal abschalten. Passieren sollte dadurch nichts, da die Optional sind.

    Ich nehme auch an, dass nicht viele Receiver die überhaupt auswerten.

    Gruss
    SHF


    Du kannst ja mal in epgsearch das logging einschalten mit -l "/tmp/epgsearch.log" -v 3

    Jedesmal, wenn der Searchtimer-Update läuft (Setup-Einstellung UpdateIntervall), sollten entsprechende Einträge zu finden sein.

    vdr-2.6.9

    softhddevice, dbus2vdr, dvd, epgsearch, femon, graphtftng, web, menuorg,
    osdteletext, radio, recsearch, satip, tvguide, vnsiserver
    ubuntu focal, yavdr-ansible, linux-5.15 ,AsRock J4105, CIne CT-V7 DVB-C

    Quote from SHF

    Die Timer existieren mit der Nummer und werden nur geändert, weil sich das EPG ändert.

    Jetzt die Frage:

    Wer veranlasst das? Der VDR selber oder macht das EPGsearch?

    Wenn sich der EPG eines Kanals ändert, für den ein Timer gesetzt ist, dann wird in vdr.c Timers->SetEvents(Schedules) aufgerufen um ggf. eine Neuzuordnung zu veranlassen.


    Klaus

    Quote from kls

    Wenn sich der EPG eines Kanals ändert, für den ein Timer gesetzt ist, dann wird in vdr.c Timers->SetEvents(Schedules) aufgerufen um ggf. eine Neuzuordnung zu veranlassen.

    Danke, für die Aufklärung.

    Ich hatte es zwar schon vermutet, es ist aber gut, wenn man es definitiv weiss.


    Quote from TomJoad

    Du kannst ja mal in epgsearch das logging einschalten mit -l "/tmp/epgsearch.log" -v 3

    Da muss ich mal schauen, wie das geht.

    Ich hab damals aus Zeitgründen fertige Pakete eingesetzt und muss jedes mal die Konfigurationsdateien suchen.

    Gruss
    SHF


    Also, der Fehler kommt wirklich von einem anderen Transponder rein.


    Der angehängte Patch beseitigt die Einträge im EPG, in der Einstellung "Transponder", zuverlässig. (Das vermurkste EPG löschen!)

    Heute hat der Suchtimer auch funktioniert. Ich hoffe das war kein Zufall ;).

    Die in der eit.c erwähnten "toggling events" sollte ich nebenbei übrigens auch beseitigt haben.

    Nebenwirkungen erwarte ich eigentlich keine und habe bislang auch keine bemerkt, es läuft aber erst seit knapp einem Tag.

    Um sicher zu gehen sollte sich noch jemand das Verhalten bei Premiere World (der wie der Laden jetzt heisst) ansehen. Stichwort: channel linking


    Die Einstellung "Kanal" ist noch etwas restriktiver in der Auswertung.

    Wenn ich den Aufbau des TS richtig verstanden habe und es die EIT pro Transponder nur einmal gibt, sollte das aber keinen Unterschied machen.

    Die Einstellung ist aber noch ungetestet


    Einstellung "Quelle" ist das bisherige Verhalten.


    ArteEPG2.diff

    Gruss
    SHF


    Begeistert gelesen habe ich es schon mal - morgen werd ich versuchen zu verstehen. Z. B. gegen was ich die diff laufen lassen muß.

    Wenn dieser störende Event kommt, und man öffnet das "Schedule"-Menü im VDR (wohl gemerkt das originale Menü!), sieht man dann nur noch diesen Event, oder auch alle anderen, die von diesem quasi "überdeckt" werden?

    Vielleicht kann ja mal jemand einen entsprechenden Screenshot machen.


    Klaus

    wie heißt das 'schedule'-Menü auf deutsch? Oder anders gesagt: wie komme ich da ran?

    Man muss ggf. noch in den Einstellungen von epgsearch abschalten, dass es den Haupmenüeintrag des VDR ersetzen soll (wenn der Mainmenuhooks-Patch genutzt wird).

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Mein

    VDR ist Version 2.2.0-13 und da ist mit und ohne Plugin folgende Ausgabe zu sehen:

    Also einfach eingereiht in das restliche Programm, trotz Überlappung

    Quote from rudibert

    Also einfach eingereiht in das restliche Programm, trotz Überlappung

    Manchmal wird auch ein Event, was so ca. um die Zeit beginnt, ersetzt.

    Das ändert sich aber über den Tag unter Umständen auch.


    Insgesamt war das Verhalten bei meinen Beobachtungen da recht inkonsistent.

    Das ganze EPG war, allenfalls, nur ganz kurzfristig weg.


    Quote from kls

    Dann liegt das ursprünglich beschriebene Problem an dem Script oder Plugin, welches die Suchtimer verarbeitet. VDR kann da nichts dafür.

    Das löschen und dann nicht wieder anlegen des Timers ist, nach meinem jetzigen Kenntnisstand, klar die Schuld von EPGsearch.

    Da scheint das Verhalten bei inkonsistenten EPG-Daten nicht wirklich optimal zu sein.

    Das sehe ich mir auch gerade an, aber ich wollte erst ergründen, wo der Fehler im EPG her kommt. Man muss ja irgendwo anfangen.


    Und der Fehler in den EPG-Daten kommt nicht von Arte. Das EPG auf dem Transponder ist einwandfrei!

    Dass dieses defekte Event in den EPG von Arte-SD gelangt eindeutig Schuld des VDR.

    Gut, eigentlich ist der Betreiber irgend eines anderen Transponders schuld, der den Schrott sendet, aber was will man da machen....


    Mein Patch sorgt in der Einstellung "Transponder" dafür, dass nur EPG-Daten verwendet werden, die auch von dem Transponder des Kanals stammen.

    Nach meinen Beobachtungen machen das die käuflichen Receiver so, was mich zu dem Patch inspiriert hat. Bei den Receivern, die ich probiert habe ist auch bei keinem einzigen der Fehler im Arte-EPG aufgetreten, selbst nach durch zappen aller Kanäle nicht.


    Die Annahme man kann dem EPG aller Transponder voll trauen und es ohne Prüfung einfach zusammen mergen, halte ich für gewagt.

    Fehlertolerant ist dieses Verfahren definitiv nicht, das ist offensichtlich. Wenn nur ein Transponder spinnt und Schrotteinträge für andere Kanäle sendet, kann das das EPG von praktisch allen Kanälen ruinieren.

    Ich hab in der Spezifikation auch nirgendwo gelesen, dass die Tabels über die Transpondergrenze hinweg konsistent sein müssen. Daher kann man das IMHO auch nicht annehmen.

    Ein Blick in die eit.c bestätigte mir das dann übrigens auch noch ;).

    C: eit.c
             // Unfortunately some stations (like, e.g. "Premiere") broadcast their EPG data on several transponders (like
         // the actual Premiere transponder and the Sat.1/Pro7 transponder), but use different version numbers on
         // each of them :-( So if one DVB card is tuned to the Premiere transponder, while an other one is tuned
         // to the Sat.1/Pro7 transponder, events will keep toggling because of the bogus version numbers.


if (Tid == 0x4E) { // we trust only the present/following info on the actual TS

    Was ich in der Einstellung "Transponder" mache ist übrigens genau das, was bei der "present/following info" schon gemacht wird.

    Nur traue ich konsequenter Weise nicht der Tid, sondern verwende die wirkliche Quelle (in dem Fall Transponder), von dem das Datenpaket stammt. So können keine Events von "defekten" Transpondern durchrutschen.


    Da die Transponderbindung der "present/following info" schon immer besteht und die Tables für andere Kanäle (0x6_) optional sind, sind auch eigentlich keine Probleme zu erwarten.

    Ich bin da sogar so sicher, dass ich es direkt auf meinem Prduktiv-System laufen gelassen habe und dass will bei mir was heissen.

    Gruss
    SHF


    Um die "future events" von anderen TS zu ignorieren sollte eigentlich auch das hier reichen:

    Kann das bitte mal jemand probieren, der das Arte-Problem nachvollziehen kann?


    Sollte das das Problem beheben, würde ich das noch in die 2.4.0 mit reinnehmen.


    Klaus

    Quote from kls

    Um die "future events" von anderen TS zu ignorieren sollte eigentlich auch das hier reichen:

    Das klappt aber nur, wenn allen anderen TS korrekt arbeiten.

    Da dem offensichtlich nicht so ist -wir hätten diese Problem sonst nicht- , würde ich deren Angaben aber nicht trauen.


    C
      if (channel->Transponder() != Src_Channel->Transponder())
            return;

    Aktuell ist bei mir nur dieser Filter aktiv, und das bislang 100% zuverlässig und nebenwirkungsfrei.

    Scr_Channel ist dabei der Kanal, von dem der Filter die Daten bekommt. (Das entspricht zusammen also filter->Transponder(). )

    So ist garantiert sicher gestellt, dass die Pakete nicht die Transpondergrenze überspringen können, egal was für ein Schrott drin steht.


    Quote from kls

    Kann das bitte mal jemand probieren, der das Arte-Problem nachvollziehen kann?

    Kann ich die Tage machen.

    Ich will die aktuelle Einstellung aber noch ein zwei Werktage lassen um sicher zu gehen, dass das mit den Timern klappt.

    Gruss
    SHF


    Quote from SHF

    Also, der Fehler kommt wirklich von einem anderen Transponder rein.

    Weißt Du denn welcher das ist?

    Dann kann ich den Dreck ja zumindest als Workaround schon mal rauskicken.

Participate now!

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

Register Yourself Login