sectionsd doppelte Events fixen - wie?

[seife]

Damit die Entwickler hier mal diskutieren (User auch, aber bitte mit Lösungsvorschlägen, nicht mit "Super daß das jemand macht!!11!111!"), hier ein extra Thread.
Es geht um z.B. http://forum.tuxbox-cvs.sourceforge.net ... =2&t=47613 Problem #1.

Mein Lösungsansatz dazu wäre:

- beim Einlesen bekommen alle Events einen Timestamp
- Events vom aktuellen Transponder, deren Timestamp älter als 1h ist, werden gelöscht (das könnte im Housekeeping-Thread passieren, der sowieso läuft)

Problem dabei:
- bisher werden vermutlich Events, die schon vorhanden sind, einfach ignoriert. Jetzt müßte dabei der Timestamp aktualisiert werden -> teurer, aber vermutlich nicht viel.
- jedes Event braucht ein paar Bytes mehr im Speicher

Dafür wäre es vermutlich wesentlich billiger (CPU-Zeit) und einfacher als tatsächlich anhand von Überlappungen (es ist ja nicht so, daß die Zeiten immer genau gleich sind, manchmal verschieben die sich ja noch im eine Minute oder so) den korrekten Event rauszufinden.

Hat jemand ne bessere Idee? Habe ich irgendwas übersehen?

[ingrid]

Super daß das jemand macht!!11!111!

Spaß beiseite...
Ich poste hier nochmal meine "grobe Idee", um den Ideenpool ein wenig anzuregen (Brainstorming):

Wenn man von Transponder A auf Transponder B schaltet und dort länger als z.B. 5 Sekunden bleibt, wird der EPG von Transponder B fallen gelassen und neu eingelesen. (Das einlesen könnte evtl. schon von Anfang an passieren? Also gelesen, aber nicht in die "EPG-Liste eingetragen". Müsste man mal schauen...)
So schont man das Ganze ein wenig, wenn man "durch die Gegend" zappt.

Hat nichts mit seife's Ansatz zu tun, hab's einfach nochmal in die Runde geworfen...

[seife]

Vom Prinzip her ist das ähnlich, nur dass dein Ansatz die Timestamps einspart. Allerdings weiß ich nicht, wie teuer die "Lösche das EPG von genau diesem Transponder"-Aktion ist...

[ingrid]

Ergänzung zu seife's Ansatz:

Dafür wäre es vermutlich wesentlich billiger (CPU-Zeit) und einfacher als tatsächlich anhand von Überlappungen (es ist ja nicht so, daß die Zeiten immer genau gleich sind, manchmal verschieben die sich ja noch im eine Minute oder so) den korrekten Event rauszufinden.

Ich hatte auch schon dran gedacht, das Ganze irgendwie anhand der Überlappungen oder auch der Inhalte der Events zu überprüfen. Wie seife aber schon sagt, sind die Zeiten nicht immer gleich und sogar die Inhalte der Events ändern sich (Titel, Text, ...). Kommt halt drauf an, warum die den Event korrigieren. Manchmal scheinen sich die Praktikanten zu vertippen, dann korrigieren die das und knallen uns den Event um die Ohren. Also wäre es wirklich problematisch, die Events direkt zu vergleichen. Irgend 'ne Kleinigkeit ist immer anders, sonst würden die den wahrscheinlich auch nicht neu senden...

Aber das mit den Timestamps hört sich interessant an... Der Preis wäre sicherlich auch ok, das würde aber bestimmt nur die Praxis zeigen. Ich überlege die ganze Zeit, ob uns der Ansatz nicht doch wieder irgendwie in den Rücken schießen könnte... Könnte es sein, dass mit dem Ansatz trotzdem noch doppelte Events auftreten könnten? Die brauche die ja nur schnell genug zu senden, oder?

[Nirvana]

Ich bin striktens dagegen auch nur ein Bit Speicherplatz für den Mist, den Provider machen zu investieren.
Falls doch bitte abschaltbar machen.

Geeignete Methode:
if EPG für Transponder = Pro7 and Table >=60 Then Verwerfe Event

Vorteil: Kostet keinen Speicher
Downside: Programmvorschau gibt's nur auf dem Pro7 TP.

Könnte man schnell wieder rückgängig machen.

[palace]

Manchmal ändern sich die Zeiten ja auch um sportliche ein bis 2 Minuten...

Mein Vorschlag wäre - ganz ohne Timestamp - schon beim Einlesen der Events zu schauen, ob es in einem Zeitfenster (bspw: +- 5Min) bereits ein Event gleichen Namens | Datums | Uhrzeit +- 5 Min. gibt und dieses dann zu ersetzen(?)...

Edit: Konfigurierbar fänd ich gut; bspw durch Erzeugen einer Datei, die die betroffenen Transponder enthält; dann spart man sich mit einem "if" unnötige CPU Zeit.

[prodigy7]

Gibt es das Problem bei Enigma eigentlich auch?

[PT-1]

Ich bin striktens dagegen auch nur ein Bit Speicherplatz für den Mist, den Provider machen zu investieren.
Falls doch bitte abschaltbar machen.

Geeignete Methode:
if EPG für Transponder = Pro7 and Table >=60 Then Verwerfe Event

Vorteil: Kostet keinen Speicher
Downside: Programmvorschau gibt's nur auf dem Pro7 TP.

Könnte man schnell wieder rückgängig machen.

@Nirvana

Englische Commenst bitte;-

[seife]

Ich bin striktens dagegen auch nur ein Bit Speicherplatz für den Mist, den Provider machen zu investieren.

Ich im Prinzip auch, deswegen hatte ich mich auch noch nicht drangesetzt

Geeignete Methode:
if EPG für Transponder = Pro7 and Table >=60 Then Verwerfe Event

Hm. Kommen die falschen Events tatsächlich alle nur über die anderen Transponder rein, hast du das mal beobachtet? Das wäre natürlich interessant und die einfachste Lösung...
Oder habe ich das jetzt falsch geparst?

[Houdini]

ich meine mal beobachtet zu haben dass die gleichen events von den unterschiedlichen Transpondern eine unterschiedlich eventid haben, deswegen gibts die dann doppelt.

Geeignete Methode:
if EPG für Transponder = Pro7 and Table >=60 Then Verwerfe Event

Hört sich interessant an und ist schnell ausprobiert - das trifft aber auf die gesamte Pro7Sat1 Gruppe zu

[ingrid]

Slightly OT:

Ich habe mal Nirvana's Rat befolgt und 'nen Brief aufgesetzt. Es scheint ja wohl die Hoffnung zu bestehen, dass die Sendergruppe sich doch bewegt: http://forum.tuxbox-cvs.sourceforge.net ... hp?t=47620

Mal sehen, vielleicht brauchen wir's ja wirklich nicht programmtechnisch fixen. Wäre natürlich die beste Lösung... Input in dem Brief-Thread welcome!

[Trial]

@prodigy7,
Enigma bekommt die selben, falschen Informationen und stellt bisher richtigerweise alles schön so da wie es der Sender schickt. Es nervt schon ziemlich. Letzte Woche dachte ich aber beim Zappen das es auch andere Sender außer Pro7+Zubehör beträfe habs mir aber nicht weiter gemerkt.

Ralf

[ingrid]

Nur mal so 'ne Frage: Könnten die Docs hier irgendwas bringen?

Guidelines on implementation and usage of service information:
ETR 211 (V.2: 08/97)
A005 Rev. 1 (03/98)

Ansonsten gibt's auch noch mehr von den DVB-Docs. Ich befürchte aber, dass die Leute, die sich mit dem SI-Gedöhns auskennen, diese Unterlagen zur Implementation/Benutzung der SI-Daten eh schon haben...?

Da es ja wohl scheinbar nur ein Problem des Tuxbox-Projektes (Neutrino/Enigma) ist (k.A. ob ich mich jetzt zu weit aus dem Fenster lehne), könnte man nicht evtl. mal bei VDR & Co. nachschauen, ob man sich dort nicht implementationstechnisch schlau machen könnte? Wenn andere OSS-Projekte sowas auch schon hinbekommen haben, dann brauch ja für Tuxbox das Rad nicht neu erfunden werden, oder?

Wenn sonst noch jemand den einen oder anderen Strohhalm hätte, an den man sich klammern könnte....

[ingrid]

Ich habe das hier mal rüberkopiert: http://forum.tuxbox-cvs.sourceforge.net ... p?p=353453

Mal für uns dumme User (sorry): Was genau hätte das für Konsequenzen? Bei jedem Umschalten EPG komplett weg? Kannst Du ein Beispiel geben?

Achtung: ich kenne mich mit dem DVB-SI Zeug nur vom sectionsd-lesen aus

Tabelle 0x60 - 0x6F übertragen EPG-Daten von Sendern, die auf anderen TS gesendet werden.
Wenn du nach dem Booten auf ARD lange genug stehen läßt, dann hast du nach ein paar Minuten (so lange dauert es u.U. bis der sectionsd zur Tabelle 0x60 kommt) EPG von allen ARD-Anstalten (evtl. sogar vom ZDF, bin mir nicht sicher). Eine Theorie ist nun, dass diese falschen Events beim Unterschichtenfernsehen genau über diese Tabelle kommen.

Code: Alles auswählen

--- sectionsd.cpp       12 Jan 2008 16:57:22 -0000      1.259
+++ sectionsd.cpp       14 Mar 2008 05:46:18 -0000
@@ -6723,7 +6723,8 @@ static void *eitThread(void *)
        dmxEIT.addfilter(0x4e, 0xfe); //2  actual and other TS, cur/next
        dmxEIT.addfilter(0x50, 0xf0); //3  actual TS, scheduled
        dmxEIT.addfilter(0x4e, 0xff); //0a actual TS, current/next
-       dmxEIT.addfilter(0x60, 0xf0); //4  other TS, scheduled
+//     dmxEIT.addfilter(0x60, 0xf0); //4  other TS, scheduled
+       dmxEIT.addfilter(0x4e, 0xff); //4  TESTING, DISABLED OTHER TS
 //     dmxEIT.addfilter(0x60, 0xf1); //4a other TS, scheduled, even
 //     dmxEIT.addfilter(0x4e, 0xff); //0a actual TS, current/next
 //     dmxEIT.addfilter(0x61, 0xf1); //4b other TS, scheduled, odd

Damit wird die Auswertung von 0x60-0x6f abgeschaltet (quick'n'dirty, für alle Sender). Könnt ihr ja mal probieren.

Das andere (nicht über mehere Transponder cachen) will man sicher nicht. Das ist nämlich praktisch ein "starte sectionsd mit jedem Transponderwechsel neu").

[ingrid]

Hier wäre das Binary zum Testen: sectionsd.zip

[ingrid]

Sag mal seife, ich weiß es ist total besch..., einen weiteren Workaround im CVS zu haben... Aber wäre es theoretisch möglich, den 0x60-Table nur auf dem problematischen Transponder abzuschalten?
Also sowas in der Art: (Pseudocode)

Code: Alles auswählen

if (transponder != ProSiebenSat1Group)
     dmxEIT.addfilter(0x60, 0xf0); //4  other TS, scheduled
else
     dmxEIT.addfilter(0x4e, 0xff); //4  TESTING, DISABLED OTHER TS

Das Ding ist ja, alle anderen Sendergruppen haben das Problem nicht, vielleicht könnte man das Problem so relativ einfach in den Griff bekommen? Wäre nämlich schon irgendwie schade, das komplett abschalten zu müssen, weil's ja schon nett ist, z.B. die ZDF-Events zu bekommen, wenn man ARD schaut. (Dein Patch macht auch genau das, was Du beschrieben hast. Und ja, ohne Patch bekommt man z.B. ZDF über ARD und umgekehrt, da hast Du völlig Recht.)

[ingrid]

Mal 'ne Zwischenmeldung: Sieht ganz gut aus, keine doppelten Events. Naja, dann wissen wir jetzt jedenfalls, woher die überhaupt kommen. Jedenfalls habe ich's jetzt gepeilt. Seife wusste das bestimmt die ganze Zeit...

Mal 'ne blöde Frage am Rande: Es ist doch theoretisch jetzt so, dass der sectionsd dadurch, dass er die Tables > 0x60 nicht mehr auswertet, weniger zu tun hat, oder? Keine Ahnung, ob ich mir das einbilde, aber irgendwie kommt's mir sogar so vor, dass die Box dadurch generell "einen Tacken" performanter ist. Bisher war's immer so, dass man die Arbeit des sectionsd in Spitzenzeiten schon irgendwie "spüren" konnte, wenn man auf der Box irgendwas gemacht hat. Das scheint jetzt nicht mehr zu sein.
Wie gesagt, kann sein, dass ich mir das einbilde. Aber ich glaube, ich lasse den Patch bei mir erst einmal drin.

Ich hatte ja oben im Pseudocode was gepostet, dazu nochmal 'n Gedanke: Ich hab's nicht aktiv beobachtet, aber mal theoretisch gesprochen... Wenn z.B. im ZDF "Wetten, dass...?" überzieht (soll ja vorkommen...) und die da Ihre Folgeevents updaten, damit der EPG wieder stimmt, könnte es dann theoretisch möglich sein, dass dort auch doppelte Events auftreten würden? Ich habe nämlich irgendwie das Gefühl, dass uns das bei den ProSiebenSat.1-Sendern nur andauernd über den Weg läuft, weil die halt permanent ihre Zeiten anpassen und andere Sender da einfach keinen Wert drauf legen. (Wäre ja sogar positiv, Service am Zuschauer von Seiten ProSiebenSat.1... Die Begründung "Service/minutengenauer EPG zu jeder Zeit" haben die ja auch in dem Brief erwähnt... )

In dem Fall wäre mein Pseudocode natürlich Bullshit, weil wir dann das Problem auf den ProSiebenSat.1-Sendern gelöst haben aber trotzdem auf machen Sendern noch auf den Bug stoßen könnten.

Vielleicht wäre dann seife's Patch schon die Lösung, die wir brauchen. Dann muss man halt drauf verzichten, dass z.B. ZDF EPG bekommt, obwohl man ARD schaut. Naja, nicht superschön, aber man könnte damit leben, oder? Jedenfalls allemal besser als doppelte Events, die ja mindestens die Infobar-Anzeige wertlos machen.

Also, bis jetzt bin ich ganz zufrieden mit der momentanen Lösung. Was meint Ihr?

[seife]

Mal 'ne Zwischenmeldung: Sieht ganz gut aus, keine doppelten Events. Naja, dann wissen wir jetzt jedenfalls, woher die überhaupt kommen. Jedenfalls habe ich's jetzt gepeilt. Seife wusste das bestimmt die ganze Zeit...

Falsch, ich habe das auch nur geraten. Nirvana wußte es und er hat ja auch oben schon pseudocode gepostet, der es fixt. Dein pseudocode geht deswegen nicht, weil dieser codeteil nur einmal beim starten des sectionsd aufgerufen wird, und du willst das ja nicht vom Startkanal abhängig machen ;-)

(Beim letzten Satz bin ich mir nicht 100% sicher und will gerade auch nicht nachschauen, man korrigiere mich also, wenn ich falsch liege).

Mal 'ne blöde Frage am Rande: Es ist doch theoretisch jetzt so, dass der sectionsd dadurch, dass er die Tables > 0x60 nicht mehr auswertet, weniger zu tun hat, oder?

Ja, das ist so.

[ingrid]

Falsch, ich habe das auch nur geraten. Nirvana wußte es und er hat ja auch oben schon pseudocode gepostet, der es fixt. Dein pseudocode geht deswegen nicht, weil dieser codeteil nur einmal beim starten des sectionsd aufgerufen wird, und du willst das ja nicht vom Startkanal abhängig machen ;-)

Stimmt, habe Nirvana's Pseudocode irgendwie vergessen. Prinzipiell drückt es auch genau die Richtung aus, in die ich wollte. Als er das gepostet hatte, hab ich das Problem noch nicht wirklich verstanden. Sehr schön. Nirvana, wärst Du bereit, das in echten Code umzusetzen? Du schreibst ja, das wäre relativ "einfach".
Seife's Patch beweist ja auch, dass es wirklich was bringt, die Tables > 0x60 bei dem Problemtransponder zu ignorieren.

Wäre echt cool, wenn einer unser beiden sectionsd-Gurus das umsetzen könnte... Gibt dann auch 'n virtuelles Bier... und ewigen Dank...

(Wobei der sectionsd dann natürlich wieder ein wenig langsamer wird, aber das ist dann nun mal so. War ja bisher nicht anders. Und die Neutrino@dreambox-Jungs juckt das bestimmt eh nicht, oder?)

[ingrid]

Mist, zu früh gefreut. Da kommen wohl noch woanders doppelte Events her. Bin gerade aufgestanden und hab ProSieben kontrolliert. Über Nacht haben sich die Events wieder doppelt reingeschlichen. Zwar nur doppelt, aber trotzdem... Es ist zwar besser geworden, aber weg ist es immer noch nicht. Die Box stand über Nacht in Soft-Standby auf MTV...

[ingrid]

Tja, jetzt sind die Events sogar 3x drin. Also alles wie gehabt, es bringt gar nichts, die Tables > 0x60 zu ignorieren, die Multi-Events kommen anders rein.

[usul1]

Schau doch mal beim VDR Quellcode rein.

Dort werden die Events aktuallisiert (das merke ich wenn sich die Timer verschieben (passend zum aktuallisierten EPG)) und tauchen trozdem nicht doppelt auf. Also werden die VDR Devs da schon irgendwas richtig gemacht haben.

cu
usul

[ingrid]

Das meinte ich ja weiter oben auch schon mal... Nur müsste das halt jemand machen, der sich auch damit auskennt.

[Nirvana]

Was VDR macht ist doch klar: Der speichert die Table mit ab, aus der er das Event hat und wenn die Table aktualisiert wird, dann ersetzt er die Table und mit ihr alle Events.

[usul1]

Das speichert der VDR in seiner Datenbank die den Neustart überlebt (auch mal zur Info für die anderen Mitlesenden):

Code: Alles auswählen

C S19.2E-1-1107-17500 SAT.1
E 48899 1205616300 3600 50 F
T Genial daneben - Die Comedy Arena
D Deutschlands Top-Comedians stellen sich unter der Leitung von Hugo Egon Balder kuriosen, aber auch schweren Fragen aus allen Wissensbereichen. Sie müssen die Fragen auf jeden Fall beantworten, auch wenn sie keine Ahnung haben - umso lustiger werden die Erklärungsversuche. Heute sind dabei: Hella von Sinnen, Bernhard Hoëcker, Herbert Feuerstein, Horst Lichter und Dieter Nuhr.
X 1 01 deu 4:3
X 2 03 deu deutsch
X 2 05 deu dolby digital
e

Die Erklärung zum Format gibts hier: http://www.vdr-wiki.de/wiki/index.php/Epg.data

Na wenn das alles ist dann machen ja die Sender doch nichts falsch und das Problem liegt doch beim sectionsd. Oder verstehe ich das falsch?

cu
usul