doppelte EPG-Eintraege entfernen...
-
- Interessierter
- Beiträge: 50
- Registriert: Dienstag 1. Februar 2005, 13:44
Ist es nicht eher korrekt, so wie es das ZDF macht? Es gibt drei EIT-Tables auf dem ZDF-Transponder. Innerhalb einer Table gibt es keine doppelten Einträge:
Table_ID: 80 (0x50) [= Event Information Table (EIT) - actual transport stream, schedule]
Das sind die "normalen" EPG-Einträge.
Table_ID: 78 (0x4e) [= Event Information Table (EIT) - actual transport stream, present/following]
Das sind die Now/Next-Informationen, so wie sie bei Enigma in der Info-Bar angezeigt werden. Ich bin mir nicht sicher, wie das Neutrino macht. Meines Wissens landen die intern in derselben Table, was zu Problemen führt.
Table_ID: 79 (0x4f) [= Event Information Table (EIT) - other transport stream, present/following]
Das sind EPG-Informationen für andere Transport Streams (beim ZDF z.B. die ARD-Transponder).
Zwischen den Tables darf (und muss) es natürlich doppelte Einträge geben - die (so wie ich das sehe) auch verschiedene IDs haben dürfen, da sie durch die Table eindeutig identifiziert sind. Innerhalb eines Tables darf es das nicht geben.
So passiert es auch öfters (wie momentan im ZDF), dass die Sendung in der Infobar eine andere Bezeichnung hat als in der EPG-Auflistung. Das ZDF signalisiert in der Table 79 auch, wenn eine Sendung länger dauert als vorher angenommen. So wie ich die ISO interpretiere ist das korrekt so.
Table_ID: 80 (0x50) [= Event Information Table (EIT) - actual transport stream, schedule]
Das sind die "normalen" EPG-Einträge.
Table_ID: 78 (0x4e) [= Event Information Table (EIT) - actual transport stream, present/following]
Das sind die Now/Next-Informationen, so wie sie bei Enigma in der Info-Bar angezeigt werden. Ich bin mir nicht sicher, wie das Neutrino macht. Meines Wissens landen die intern in derselben Table, was zu Problemen führt.
Table_ID: 79 (0x4f) [= Event Information Table (EIT) - other transport stream, present/following]
Das sind EPG-Informationen für andere Transport Streams (beim ZDF z.B. die ARD-Transponder).
Zwischen den Tables darf (und muss) es natürlich doppelte Einträge geben - die (so wie ich das sehe) auch verschiedene IDs haben dürfen, da sie durch die Table eindeutig identifiziert sind. Innerhalb eines Tables darf es das nicht geben.
So passiert es auch öfters (wie momentan im ZDF), dass die Sendung in der Infobar eine andere Bezeichnung hat als in der EPG-Auflistung. Das ZDF signalisiert in der Table 79 auch, wenn eine Sendung länger dauert als vorher angenommen. So wie ich die ISO interpretiere ist das korrekt so.
-
- Interessierter
- Beiträge: 50
- Registriert: Dienstag 1. Februar 2005, 13:44
OK - nach Studium der ISO und etwas längerem Nachdenken relativiere ich meine Aussage.
Es heißt da:
Man kann aber trotzdem einen DVB-konformen Receiver haben, der keine doppelten Einträge hat. Man muss dafür nur wie folgt vorgehen:
Die Events aus den verschiedenen Tables dürfen nicht in ein und derselben Liste landen, sondern müssen in zwei Listen gespeichert werden. Ausschließlich die Schedule Informationen nutzt man dann zur Darstellung des vollständigen Schedules. Für die Anzeige in der Infobar nutzt man ausschließlich die Informationen aus den "present/following event" Tables. Enigma z.B. macht das meines Wissens so, weswegen es dort auch nicht das Problem mit den doppelten Einträgen gibt.
Es heißt da:
Die ID eines Events soll also innerhalb eines Services eindeutig sein.event_id: This 16-bit field contains the identification number of the described event (uniquely allocated within a service definition).
Man kann aber trotzdem einen DVB-konformen Receiver haben, der keine doppelten Einträge hat. Man muss dafür nur wie folgt vorgehen:
Die Events aus den verschiedenen Tables dürfen nicht in ein und derselben Liste landen, sondern müssen in zwei Listen gespeichert werden. Ausschließlich die Schedule Informationen nutzt man dann zur Darstellung des vollständigen Schedules. Für die Anzeige in der Infobar nutzt man ausschließlich die Informationen aus den "present/following event" Tables. Enigma z.B. macht das meines Wissens so, weswegen es dort auch nicht das Problem mit den doppelten Einträgen gibt.
-
- Semiprofi
- Beiträge: 1383
- Registriert: Freitag 18. April 2003, 15:12
-
- Tuxboxer
- Beiträge: 4332
- Registriert: Dienstag 7. Mai 2002, 17:04
ich würd mal sagen der sectionsd IST schon in den besten Händen - ver soll sich daran denn noch alles vergreifenNico 77 hat geschrieben:Nach der Theoriestunde hat glaube ich keiner was dagegen wenn du es auch in die Praxis umsetzt.
---------------------------
Alle weiteren Infos findest Du im WIKI
Bitte vor dem posten Boardregeln lesen und verstehen!
Wie erstelle ich ein Bootlog? Wo finde ich die FAQ?
Alle weiteren Infos findest Du im WIKI
Bitte vor dem posten Boardregeln lesen und verstehen!
Wie erstelle ich ein Bootlog? Wo finde ich die FAQ?
-
- Developer
- Beiträge: 331
- Registriert: Freitag 7. Februar 2003, 22:17
@vinyl
wie weit soll man das mit den unterschiedlichen tabellen treiben?
also theoretisch - habs nicht analysiert -
musst du dann auch (0x4e) present/follow act ts und (0x4f) present/follow other ts
vollkommen trennen.
es ist von der qualität der daten abhängig, das ein system das bringt, was es bringen soll.
wenn die die qualität nicht bringen, kann man immer kunden(receiverbesitzer) verarschen und einfach bestimmte sachen in bestimmten menus verbergen, was aber machst du, wenn die events die gerade laufen, dann nicht mehr im schedule enthalten sind? mal abgesehen von der eventId, die eigentlich sicherstellt, das pro service dieses event nur EINMAL vorkommen sollte.
wenn die provider müll senden, muss man ihnen das erklären. ständig workarounds für die sache ist mist.
my 2ct
gruss
mws
nachtrag: es gibt auch sender, die sender lediglich present/follow
sollen deswegen dann in der epg übersicht _keine_ einträge mehr stehen?
wie weit soll man das mit den unterschiedlichen tabellen treiben?
also theoretisch - habs nicht analysiert -
musst du dann auch (0x4e) present/follow act ts und (0x4f) present/follow other ts
vollkommen trennen.
es ist von der qualität der daten abhängig, das ein system das bringt, was es bringen soll.
wenn die die qualität nicht bringen, kann man immer kunden(receiverbesitzer) verarschen und einfach bestimmte sachen in bestimmten menus verbergen, was aber machst du, wenn die events die gerade laufen, dann nicht mehr im schedule enthalten sind? mal abgesehen von der eventId, die eigentlich sicherstellt, das pro service dieses event nur EINMAL vorkommen sollte.
wenn die provider müll senden, muss man ihnen das erklären. ständig workarounds für die sache ist mist.
my 2ct
gruss
mws
nachtrag: es gibt auch sender, die sender lediglich present/follow
sollen deswegen dann in der epg übersicht _keine_ einträge mehr stehen?
cu
mws
mws
-
- Interessierter
- Beiträge: 50
- Registriert: Dienstag 1. Februar 2005, 13:44
Ok, ok. Ich seh die Sache ja mittlerweile ähnlich. Musste das ganze nur mal selbst von vorne bis hinten durchdenken. Ich hab zwar immer noch das Gefühl, dass ich irgendwas übersehen habe - da mir aber nicht einfallen will, was das sein könnte, geb ich Dir einfach mal Recht. Schön, dass wir trotzdem drüber geredet haben.
-
- Erleuchteter
- Beiträge: 646
- Registriert: Mittwoch 16. April 2003, 14:12
Ohne mir das jetzt im Source angesehen zu haben. Wieso so kompliziert mit vielen Listen? Angenommen ich habe 2 gleiche Events mit unterschiedlicher ID. Also haben die auch die gleiche Startzeit und Dauer. Es kommt doch nun nur darauf an, das nächste Event in der Liste korrekt zu finden. Offenbar ist es z.Z. so dass alle Events nach ihrer Startzeit sortiert angezeigt werden. Richtiger wäre das nächste Event nach Beendigung des Vorgängers zu wählen.
Aber wahrscheinlich hatte Metallica das exakt so gemacht, wobei ich nicht verstehe, welche Probleme das verursachte.
Anyway, ich bin anderweitig beschäftigt.
Aber wahrscheinlich hatte Metallica das exakt so gemacht, wobei ich nicht verstehe, welche Probleme das verursachte.
Anyway, ich bin anderweitig beschäftigt.
-
- Interessierter
- Beiträge: 64
- Registriert: Montag 15. Dezember 2003, 11:16
-
- Erleuchteter
- Beiträge: 646
- Registriert: Mittwoch 16. April 2003, 14:12
Das ist nicht dein Ernst, oder? Es kann doch kein Fehler sein, das anzuzeigen, was die Provider senden. Der Nächte meldet bestimmt bald nen Bug, weil Neutrino DSDS zeigt. Das könnte ich wenistens noch verstehen...InTheCliringSt&sTheDB hat geschrieben:Kann dieses Problem im Bugtracker thematisiert werden? Macht ja letztlich wenig Unterschied, ob der Bug durch nicht konforme EPG-Feeds oder konformer Feeds entsteht, das Ergebnis von doppelten oder vierfachen EPG-Einträgen bleibt unters Strich eben buggy.
Kann das bitte jemand einstellen? Danke
Davon abgesehen:
http://rapidshare.de/files/14342862/sectionsd.html
Das Ding nach /var kopieren. In der start_neutrino statt des alten sectionsd starten lassen. Sollte keine doppelten Einträge mehr raustun.
Zusätzliche Abfrage: Nächste Startzeit muss größer sein als letzte.
Achtung: nicht in den Test-Images mit EPG 2 XML verwenden.
-
- Interessierter
- Beiträge: 64
- Registriert: Montag 15. Dezember 2003, 11:16
Also so, wie ich die ISO lese, kann die event-id von TS zu TS und sogar innerhalb eines TS unterschiedlich sein.
Da würde es imo schon Sinn machen, sich auf eine Quelle zu konzentrieren, also evtl. den aktuellen TS.
Wird eigentlich die version_number benutzt, um Infos über die Aktualisierung des EPGs zu senden, und wenn ja, werden diese Infos ausgewertet?
Code: Alles auswählen
service_id: This is a 16-bit field which serves as a label to identify this service from any other service within a TS. The
service_id is the same as the program_number in the corresponding program_map_section.
Wird eigentlich die version_number benutzt, um Infos über die Aktualisierung des EPGs zu senden, und wenn ja, werden diese Infos ausgewertet?
-
- Erleuchteter
- Beiträge: 646
- Registriert: Mittwoch 16. April 2003, 14:12
Mit deinem Quote kann ich nichts anfangen. Die Service ID ist die ID des Senders. Vinyl hat das oben doch schön herausgearbeitet, dass es ein Fehler der Sender ist und auf deren Agenda gehört.
Aber du hast ja nun eine Version die sich zu Deinen Ansprüchen konform verhält. (Wobei ich keinen Sender kenne, der doppelte Einträge produziert. Also getestet habe ich es nicht.)vinyl hat geschrieben:OK - nach Studium der ISO und etwas längerem Nachdenken relativiere ich meine Aussage.
Es heißt da:Die ID eines Events soll also innerhalb eines Services eindeutig sein.event_id: This 16-bit field contains the identification number of the described event (uniquely allocated within a service definition).
-
- Interessierter
- Beiträge: 64
- Registriert: Montag 15. Dezember 2003, 11:16
Ja, Du hast recht - erstmal vielen Dank, dass Du hier auf meine Extrawürste reagierst. Runtergeladen hab ichs, muß aber erst wieder nen anderen Snapshot draufspielen, da ich den aktuellen Snap hab. Schaff ich aber erst morgen. Ich geb dann Feedback, obs geklappt hat. Momentan hab ich auf ZDF und Infokanal doppelte Einträge.
-
- Interessierter
- Beiträge: 64
- Registriert: Montag 15. Dezember 2003, 11:16
Ich hab mir jetzt die event_id im EPG mal angeschaut. Solange ich auf dem Transponder von ZDFvision bleibe, sind die eindeutig. Wenn ich nach ARD wechsle kommen für ZDFvision die doppelten Einträge, weil die dort andere event_ids verwenden. Andersherum tritt das nicht auf, d.h. auf ARD gibts bei mir keine doppelten EPG-Einträge. ARD sendet die EPG-Infos für alle Programme von ZDFvision, also kann es auf allen Sendern dort zu diesem Problem kommen. Das hab ich übrigens auch dem ZDF mitgeteilt, mal sehen, ob und was die antworten.
Hab jetzt Nirvanas sectionsd-special-edition drauf, macht auf den ersten Blick einen sehr guten Eindruck, das Filtern der Daten funktioniert, für ZDF habe ich einmal diesen Fall:
die event_id a1e4 paßt nämlich überhaupt nicht ins Schema, d.h. die redundanten Daten sind da, werden aber wohl ins Nirvana geschickt; Filter funktioniert also wie gewünscht.
Nebeneffekt: bei in etwa gleichem Umschaltverhalten habe ich ca. 1200 kb weniger Speicherverbrauch.
Hab jetzt Nirvanas sectionsd-special-edition drauf, macht auf den ersten Blick einen sehr guten Eindruck, das Filtern der Daten funktioniert, für ZDF habe ich einmal diesen Fall:
Code: Alles auswählen
<TR VALIGN="middle" CLASS="b">
<TD><NOBR><A HREF="/fb/timer.dbox2?action=new&type=5&alarm=1141305000&stop=1141307880&channel_id=43700016d66&rs=1"> <IMG BORDER=0 SRC="/images/record.gif" WIDTH="16" HEIGHT="16" ALT="Sendung aufnehmen"></A>
<A HREF="/fb/timer.dbox2?action=new&type=3&alarm=1141305000&channel_id=43700016d66"> <IMG BORDER=0 SRC="/images/timer.gif" WIDTH="21" HEIGHT="21" ALT="Timer setzen"></A>
</NOBR></TD><TD><NOBR>02.03. 14:10 <font size="-2">(48 min)</font> </NOBR></TD>
<TD><A CLASS="elist" HREF=epg.dbox2?eventid=43700016d664b2e>Leben für die Liebe</A></TD>
</TR>
<TR VALIGN="middle" CLASS="b"><TD COLSPAN=2><IMG SRC=/images/blank.gif WIDTH=1 HEIGHT=1></TD><TD>Kapitel 29</TD></TR>
<TR VALIGN="middle" CLASS="a">
<TD><NOBR><A HREF="/fb/timer.dbox2?action=new&type=5&alarm=1141305300&stop=1141308000&channel_id=43700016d66&rs=1"> <IMG BORDER=0 SRC="/images/record.gif" WIDTH="16" HEIGHT="16" ALT="Sendung aufnehmen"></A>
<A HREF="/fb/timer.dbox2?action=new&type=3&alarm=1141305300&channel_id=43700016d66"> <IMG BORDER=0 SRC="/images/timer.gif" WIDTH="21" HEIGHT="21" ALT="Timer setzen"></A>
</NOBR></TD><TD><NOBR>02.03. 14:15 <font size="-2">(45 min)</font> </NOBR></TD>
<TD><A CLASS="elist" HREF=epg.dbox2?eventid=43700016d66a1e4>Leben für die Liebe</A></TD>
</TR>
<TR VALIGN="middle" CLASS="a"><TD COLSPAN=2><IMG SRC=/images/blank.gif WIDTH=1 HEIGHT=1></TD><TD>Kapitel 29</TD></TR>
<TR VALIGN="middle" CLASS="b">
<TD><NOBR><A HREF="/fb/timer.dbox2?action=new&type=5&alarm=1141307880&stop=1141308000&channel_id=43700016d66&rs=1"> <IMG BORDER=0 SRC="/images/record.gif" WIDTH="16" HEIGHT="16" ALT="Sendung aufnehmen"></A>
<A HREF="/fb/timer.dbox2?action=new&type=3&alarm=1141307880&channel_id=43700016d66"> <IMG BORDER=0 SRC="/images/timer.gif" WIDTH="21" HEIGHT="21" ALT="Timer setzen"></A>
</NOBR></TD><TD><NOBR>02.03. 14:58 <font size="-2">(2 min)</font> </NOBR></TD>
<TD><A CLASS="elist" HREF=epg.dbox2?eventid=43700016d664d9a>Wetter</A></TD>
</TR>
Nebeneffekt: bei in etwa gleichem Umschaltverhalten habe ich ca. 1200 kb weniger Speicherverbrauch.
-
- Einsteiger
- Beiträge: 108
- Registriert: Freitag 14. April 2006, 11:21
-
- Developer
- Beiträge: 2183
- Registriert: Mittwoch 10. Dezember 2003, 07:59
-
- Einsteiger
- Beiträge: 108
- Registriert: Freitag 14. April 2006, 11:21
jup es sind definitiv 2-* verschiedene event-id für die gleiche sendung. Ich krieg das ganze über die nhttpd api, d.h. wenn es nur im viewer gefiltert ist, ist klar wieso es über die api immer alles doppelt und mehrfach ist..
Wie auch immer - die Frage bleibt.. Wird das irgendwann seitens neutrino gerichtet (ich glaube nicht daran dass die Sender jemals etwas umstellen)?
Der Hintergrund meiner Frage liegt bei meinem kleinen Tool neutrinoTV. Für mich stellt sich die frage ob ich eben jetzt selbst diese doppelten sachen filtern soll - fände es sinnvoller wenn sie bei mir (also über die nhttpd api) gar nicht erst doppelt ankommen würde...
Grüßle
A.
Wie auch immer - die Frage bleibt.. Wird das irgendwann seitens neutrino gerichtet (ich glaube nicht daran dass die Sender jemals etwas umstellen)?
Der Hintergrund meiner Frage liegt bei meinem kleinen Tool neutrinoTV. Für mich stellt sich die frage ob ich eben jetzt selbst diese doppelten sachen filtern soll - fände es sinnvoller wenn sie bei mir (also über die nhttpd api) gar nicht erst doppelt ankommen würde...
Grüßle
A.