[Announce] Entwurf: Channelpedia generiert automatisch unique Kanal-IDs

Hallo allerseits,

ich habe es seit dem Start von Channelpedia [1] versprochen, nun habe ich mit der Arbeit daran begonnen: Das Generieren und Verwalten von Unique Kanal-IDs, in einer ähnlichen Weise, wie es vom xmltv2vdr-Plugin verlangt/betrieben wird. Das xmltv2vdr-Plugin hat im VDR-Wiki eine Seite mit einer verbindlichen Liste von Unique-Channel-IDs [2]. Ich finde es gut, dass die Kollegen angefangen haben, so eine Liste zu pflegen, aber ich denke, es wäre besser, es an einer zentralen Stelle nach konsistenten Regeln zu tun, damit verschiedene Software-Services darauf zugreifen können und es für verschiedene Dinge nutzen können. Da xmltv2vdr durchaus für internationale Nutzer interessant ist und nicht nur für den deutschsprachigen Raum, ist eine deutschsprachige VDR-Wiki-Seite auch ein gutes Versteck für solche Daten.

Channelpedia hat den Vorteil, dass hier sowieso Kanäle das Herz des Datenbestands bilden, und das es relativ einfach ist, die Funktionalität um das Generieren, Prüfen, Korrigieren, Zuordnen von Unique IDs zu ergänzen. Grundproblem ist immer, dass es sich bei Kanaldaten um einen inkosistenten, sich ständig wandelnden Datenhaufen handelt, woraus Pflegeaufwand resultiert. Das automatische Zuweisen von Unique IDs zu Kanälen wird wahrscheinlich nie zu 100% perfekt funktionieren, aber wenn es für die wichtigsten Kanäle funktioniert, ist es trotzdem eine große Arbeitserleichterung für Plugin/Addon-Autoren oder für den Enduser, der nicht mehr im OSD die einzelnen Kanäle zu EPG-IDs-mappen muss.

Ich wollte jetzt VDR/Plugin/Addon-Entwickler darum bitten, sich meinen Entwurf bzw. die Syntax der Kanal-IDs mal anzusehen und zu kommentieren. Alles, was es bisher gibt, liegt im JSON-Format vor und ist hier abrufbar [3]. Es ist ein Entwurf, der nicht fehlerfrei ist. Bisher habe ich de-, at- und ch-Kanäle aufgenommen und alle anderen Regionen ausgeklammert.

Die Channelpedia-Engine soll in Bezug auf Unique-Kanal-IDs zwei Dinge "erledigen":

1) Ein weitgehend automatisches Generieren von unique-IDs für Kanäle, das Zuordnen der IDs zu den in der Channelpedia-DB gespeicherten Kanälen und
2) Bereitstellen von Möglichkeiten, diese Unique-IDs auf dem VDR des Nutzers per Skript zu den passenden Kanälen zuzuordnen, die sich beim End-User in der channels.conf befinden (und dies möglichst provider-übergreifend). Hierzu könnte Channelpedia theoretisch (Python-)Quellcode generieren oder einfach die Datenstrukturen, die von anderen Skripts genutzt werden können, um diese Zuordnungen zu erledigen.

Im Endeffekt sollen dann alle Mapping-Tabellen für Kanal-Logos, EPG-Daten, etc. ohne die Angabe der VDR-internen Kanal-IDs source-nid-tid-sid auskommen können. source-nid-tid-sid wird in fast allen Mapping-Tabellen verwendet, so zum Beispiel in den channelmap-confs für einige *2vdr-EPG-Plugins. [4]

Auch ein Wissen über mehrfach vorhandene Kanäle (ZDF als HD-Kanal, ZDF als SD-Kanal, ZDF noch einmal über DVB-T) könnte so aufgebaut werden, wobei die Komplexität der Nutzungszenarien ein anderes Problem ist, das hier [5] diskutiert worden ist. Wenn man drei Mal ZDF in der channels.conf hat, hat man auch dreimal inhaltlich gleiche EPG-Daten in der epg.data. Dies könnte über Unique-IDs verhindert werden, wenn man es als Problem ansieht.

Viele Grüße
hepi

EDIT: Aus welchen Bestandteilen eine Unique-ID meines Erachtens bestehen sollte, habe ich als Diskussionsgrundlage mal schriftlich festgehalten [6].

[1] Channelpedia: Prototyp für vorsortiertes Kanallisten-Verzeichnis
[2] http://www.vdr-wiki.de/wiki/in…n#Verbindliche_Kanalliste
[3] http://channelpedia.yavdr.com/gen/de_uniqueIDs.html
[4] Automatisch generierte channelmap.conf's für epgdata2vdr und tvm2vdr verfügbar
[5] Überlegungen zur channels.conf für DVB-C/S/T Mischbetrieb
[6] xmltv2vdr plugin and channel names

Auf der verlinkten Seite steht ein Hinweis auf das Firefox Addon JSONView, das reicht.

Gruß
hepi

Gesendet von meinem HTC Desire mit Tapatalk

Zitat von Keine_Ahnung

Wichtig wäre dabei das einmal vergebene Namen auch bleiben, ist das bei der automatischen Vergabe gegeben?

Richtig, das ist wichtig. Momentan ist es - da noch ein Entwurf - nicht gegeben, aber ist ein Muss für die Final-Version.

Sendernamen ändern sich aber auch mal, wenn also mal ein Sender "ZDFDoku" den Namen zu "ZDFSuperDoku" ändert, so müssten wir damit beginnen, Aliase zu pflegen. Das würde dann heißen, historisch wäre die ID "cp[v0.1].tv.de.zdfdoku" die zuerst dagewesene ID und dazu käme dann ein darauf verweisender Alias namens "cp[v0.1].tv.de.zdfsuperdoku". Nur mal ein Beispiel, was für Probleme man dann hätte.

Man könnte den Spieß aber auch umdrehen und dann die ID "cp[v0.1].tv.de.zdfdoku" als veraltetes Alias zu einer neuen ID "cp[v0.1].tv.de.zdfsuperdoku" aufnimmt, damit in einer Logosammlung das Logo zu ZDFDoku dann zum neuen Sendernamen ZDFSuperdoku zugeordnet werden kann.

Wenn sich SID, NID, TID aber nicht ändern, würde das Anlegen von Aliasen nicht zwingend notwendig, da man immer noch den Bezug zwischen Kanal und Kanal-ID eindeutig herstellen kann.

Zitat von Keine_Ahnung

BTW: Was bedeutet eigentlich dieses "cp[v0.1]"?

Ja, es ist der Versuch einer Versionierung. Damit man mehrere ID-Syntaxen handeln kann, zum Beispiel auch einen ID-Standard, der nicht aus der Channelpedia kommt und daher dann auch nicht mit dem Prefix "cp[...]" beginnt.

Aus Zeitgründen jetzt nicht mehr, demnächst.

Gruß
hepi

Zitat von seahawk1986

Die eindeutige Zuordnung scheint aktuell noch nicht für alle Sender zu klappen - z.B. gibt es für RTL die Einträge "RTL" und "RTL Television", bei letzterem fehlt dann auch noch der Eintrag für RTL bei Kabel D in München, der ja durchaus in der Channelpedia ist (http://channelpedia.yavdr.com/…en/uncategorized/#Digital Free SDTV scrambled), der DVB-T Eintrag wird berücksichtigt:

Code

RTL Television;Digital Free:346000:M256:C:6900:1401+1400:1402=ger;1403:1404:1722,1801:53601:61441:10007:0

Hi seahawk, die Ursache ist, dass in der channels.conf von KabelD-München für Audio-Language Deutsch das Kürzel "ger" drinsteht anstelle von "deu" (channelpedia prüft nur auf "deu"). Hast Du eigentlich einen Upload-Account von mir bekommen? Ich frage mich, ob in einer produktiven channels.conf KabelD München dann auch "ger" drinsteht, oder ob das "ger" von w_scan kommt? Wir sollte in jedem Fall die Münchener-KabelD-Liste regelmäßig aktualisieren, die ist ja nun auch schon ein Dreivierteljahr alt, oder?

Gruß
hepi

"RTL" und "RTL Television" sind nun zusammengefasst, gleiches gilt für "SRTL" und "SuperRTL". Ich jage aber noch ein paar andere Bugs.

Was mich noch nervt, ist, dass ich beispielsweise einige Varianten-Kanäle für Österreich/Schweiz ("RTL Austria", "VOX CH", "VOX Austria") und vergleichbare Kanäle als at/ch-Kanäle kategorisiere, obowohl ich keine Ahnung habe, ob sich diese Sender vom EPG her unterscheiden (untereinander und von den deutschen Pendants) oder nur vom Inhalt der Werbeblöcke. Will heißen: RTL Austria und RTL Television haben unterschiedliche IDs, die in keiner Beziehung zueinander stehen.

Ähnliches gilt für deutsche regionale Varianten von Sendern, doch ist dort zumindest das Länderkürzel "de" überall gleich, so dass ich zur Not zwei IDs wie cp[v0.1].tv.de.rtl und cp[v0.1].tv.de.rtlhh automatisch als verwandt miteinander erkennen könnte.

Das In-Beziehung-Setzen regionaler Varianten artet hier in nervtötende Fleißarbeit aus. Ich könnte ja sagen, dass wenn ein Sender mit "RTL" beginnt, alles, was dahinter kommt, eine regionale Beschreibung ist, jedoch gibt es auch "RTL Passion" und "RTL Crime", wobei es sich offensichtlich nicht um regionale Zuordnungen handelt. Es fragt sich, wie wichtig es ist, für diese regionalen Kanäle Zusatz-Aufwand zu treiben. Beispielsweise hat der Kanal "RTL FS" gar keine EPG-Daten, worüber mancher unerfahrene User stolpert, der eigentlich "RTL Television" nehmen sollte.

EDIT: Ein andere Perspektive ist noch: Alles, für dass es ein eigenes Kanal-Logo gibt, braucht auch eine eigene ID. Wenn es also für "RTL FS" ein eigenes Logo gibt (was ich bezweifle), dann bräuchte der Kanal schon deshalb eine eigene ID, selbst wenn diese ID unwichtig wäre für EPG-Daten.

Gruß
hepi

P.S.: ...Und die Münchener Kanäle in Channelpedia werden nun regelmäßig aktualisiert von Seahawk. Danke!

Zitat von ludi

hepi

Vielleicht solltest du mit Joe_D sprechen, damit er eine Möglichkeit im xmltv2vdr implementiert, damit die User ihre Zuordnungen zwischen den ids in der xmltv Datei und den Sendern in der Channels.conf in die Channelpedia laden können. Damit würden wahrscheinlich interessante Daten für die verschiedenen Varianten der Sender geliefert werden.

Hmm, ich glaube, ich verstehe Dich hier nicht. Ich denke eigentlich genau andersherum: Die Zuordnungen sollten nicht mehr manuell vorgenommen werden müssen, der Sinn der Sache wäre ja, die Zuordnung zwischen einer Zeile in der channels.conf und dem passenden xmltv2vdr-"Kanal" automatisch vornehmen zu lassen.

Gruß
hepi

Ein Wiki-Prinzip / Bedarf an redaktioneller Mitarbeit bleibt immer erhalten, weil die automatische Zuordnung niemals 100%ig funktioniert. Redaktionell muss man dort eingreifen, wo die Zuordnung falsch läuft und Ausnahmeregeln pflegen.

Meiner Meinung nach ist dieser Arbeitsaufwand jedoch kleiner, als wenn man alles komplett manuell macht. Das heißt, die "Redakteure" haben weniger zu tun, weil es in 85% der Fälle automatisch richtig läuft.

Gesonderte IDs für Kanal-Logos und EPG-Zuordnung will ich eigentlich vermeiden. Ich sehe momentan keinen Grund, warum man die trennen sollte. Aber ich bastele gerade im Hintergrund an einer automatischen Logo-Zuordnung und vielleicht fällt mir dabei noch was auf, was ich nicht bedacht habe.

Gruß
hepi

Zitat von Keine_Ahnung

Weil irgendwie beißt sich ja die Forderung nach einer festen (von da an für immer geltenden) ID und dem Ansatz sie automatisch aus sich ständig ändernden Parametern zu bilden. Die Sendernamen wechseln ja immer fröhlich (DMAX -> DMAX neu / DMAX alt) und die technischen Sendeparameter auch.

DMAX alt / neu wäre kein Problem, aber wenn mit einer bereits bestehenden sid-nid-tid plötzlich ein komplett anderer Sender sendet, so wie RTLNITRO das gemacht hat auf S19.2E, dann wäre es ein nervigeres Problem, weil die Grundannahme eigentlich ist, dass sid-nid-tid immer konstant einem Sender zugewiesen sind.

Bei den SKY Sportkanälen gibt es diesen Wechsel auch, aber die meisten SKY-Bundesliga-Kanäle, die zweistündlich ihren Kanalnamen wechseln, kriegen von Channelpedia auch keine Unique ID spendiert, sondern werden ausgenommen.

Gruß
hepi

Und noch etwas:

Ich habe die Seite mit den Unique IDs eben etwas überarbeitet, damit sie etwas informativer wird, ohne dass man gleich die JSON-Dateien anschauen muss:
http://channelpedia.yavdr.com/gen/de_uniqueIDs.html

Die ID-Namen dort sind nach bestimmten Regeln aufgebaut, die ich heute hier versucht habe zu erklären:
xmltv2vdr plugin and channel names

Die JSON-Dateien sind damit aber keineswegs überflüssig, denn sie enthalten die eigentlich spannenden Zuordnungen.

Gruß
hepi

Zitat von ludi

Eine automatische Zuordnung ist das Ziel, aber bis dorthin gibt es einen langen Weg, der wahrscheinlich einen großen Bedarf an Daten benötigt. Daher mein Vorschlag, die von den Leuten im xmltv2vdr vorgenommen Zuordnungen mit der Channelpedia zu sharen.

Ich weiß nicht, wie genau Du Dir Channelpedia schon angeschaut hast. Es ist schon eine vergleichsweise große Datenmenge drin - wenn wir jetzt mal nur die deutschsprachigen Sender (de, at, ch) anschauen. 70-80% der VDR-User, die Channelpedia nutzen, nutzen den VDR mit Sat-Schüssel, also S19.2E. Das heißt, würde Channelpedia nur die Kanalliste für S19.2E enthalten, würde man damit schon 70% aller User mit automatischen Unique-ID-Zuordnungen versorgen können. Man kann natürlich nie 100% aller existierenden Kanallisten aufnehmen, auch für den deutschsprachigen Raum nicht, aber es gibt halt zwischen den DVB-C-Providern und DVB-S große Ähnlichkeiten bei den Kanaldaten, so dass man wahrscheinlich mit den momentan Daten schon mehr als 80% der VDR-User erfolgreich mit Unique IDs versorgen könnte.

Versorgen meint: Ich gebe Dir ein Skript, dass Deine channels.conf abklappert und dass Dir am Ende eine Liste der dazugehörigen Unique-IDs für die deutschsprachigen Sender zurückgibt.

Bei den Zuordnungen, die ein User von xmltv2vdr vornimmt (channel <-> unique xmltv2vdr id) wäre aus meiner Sicht nicht interessant, wie die Zuordnung aussieht (niemand ordnet das EPG von Prosieben zum Sender RTL II zu, da ist der kreative Freiraum relativ eng). Ich meine, dass das Matching generell automatisch funktionieren kann (man könnte sich im OSD einen Menüpunkt Auto-Match vorstellen, der das macht), aber das der Nutzer dann danach noch wieder für einige Kanäle, für die er aus irgendwelchen Gründen doch nicht das von xmltv2vdr zugeführte EPG nutzen möchte, die Zuordnung wieder aufhebt.

Zitat von ludi

Eigentlich könnten beide Projekte davon profitieren: nehmen wir an, die Channelpedia stellt ein Service zur Verfügung, der es erlaubt, die SenderIDs abzurufen. Programme wie xmltv2vdr könnten es dann nützen, und die Zuordnungen die schon in der Channelpedia vorhanden sind automatisch tätigen; die fehlenden Zuordnungen müsste der Benutzer von xmltv2vdr dann manuell machen; aber falls er diese dann mit der Channelpedia sharen könnte, hätte der nächste Benutzer, der diese Zuordnungen benötigt, diese schon in der Channelpedia zur Verfügung.

Wie oben beschrieben kapiere ich den Sinn nicht. Jeder User wird Prosieben zu Prosieben zuordnen, ich kapiere nicht, wie die Zuordnung individell abweichen kann, so dass es sich lohnt, solche Settings zu sharen. Gib doch mal ein konkretes Beispiel dafür, wie man die Zuordnungen sharen kann.

EDIT: Ah, jetzt kapiere ich es. Wenn Zuordnungen nicht automatisch erfolgen können, liegt das daran, dass in Channelpedia die entsprechende Kanalliste nicht enthalten ist. Das heißt, der Nutzer muss dann sagen: Hier, mein DVB-C-Provider in Österreich mit den völlig anderen SID-NID-TID's für die deutschen Sender, ist noch nicht in Channelpedia erfasst. Dann können wir die Kanalliste in Channelpedia aufnehmen, um das zu ändern (und müssen dann evtl. erst in Channelpedia Gruppierungsregeln für diesen Provider definieren). Aber ich habe nicht gezwungenermaßen das Ziel, 100% aller Quellen abzudecken, 85% ist auch schon gut genug. Manche Leute müssen weiterhin die Zuordnung manuell machen, und das eben auch für Nicht-deutschsprachige Sender, für die momentan noch keine IDs generiert werden.

Zitat von ludi

Ob jetzt aus Sicherheitsgründen nur authentifizierte Benutzer ihre Zuordnungen hochladen sollten, bedarf wahrscheinlich eine separate Diskussion.

Zitat von ludi

Dies setzt nätürlich voraus, dass die Entwickler beider Projekte die Zeit finden, um gemeinsam daran zu arbeiten, was leichter gesagt als getan ist.

Wie sieht denn eigentlich Dein eigenes Tätigkeitsfeld im Bereich xmltv2vdr aus? Denkst Du Dir nur Konzepte aus oder codest Du XML-Grabber oder so? Ich würde das ganze gern praktischer diskutieren. Hast Du Dir Quellcode von xmltv2vdr oder channelpedia mal angesehen bzw. ausgeführt? Was bringt Dich in diese Diskussion hinein?

Zitat von ludi

Gestern habe ich auch fast eine Post geschrieben, wo ich mit dem Gedanken spielen wollte, die Idee von festen IDs in Frage zu stellen. Vielleicht, muss man ja nicht gleich so weit gehen, und in Betracht ziehen, dass einmal vergebene IDs über die Zeit andere Bedeutungen erhalten ohne ein konkretes Beispiel im Kopf zu haben...

Wie ich im Eingangsposting dieses Threads schon geschrieben habe, sind Fernsehkanäle in der channels.conf ein inkonsistenter Datenbrei, der sich dauernd irgendwie verändert. Das heißt, wer IDs anbietet für Kanalnamen, muss diese IDs auch regelmäßig überarbeiten. Deshalb ja die Idee, sowas über Channelpedia zu automatisieren, weil Channelpedia von Anfang an darauf ausgelegt ist, mit sich ändernden Kanaldaten umzugehen und die Kanäle trotzdem sinnvoll zu sortieren.

Ich habe momentan das Gefühl, dass unsere Diskussion in keine produktive Richtung führt. Dieser Thread richtet sich an Developer (siehe Eingangsposting) und ich würde mich freuen, wenn wir die JSON-Daten, die Channelpedia momentan auswirft für Unique-IDs praktisch auf ihre Qualität testen könnten. Um praktisch die Schwächen, die momentan darin unentdeckt stecken mögen, aufzudecken.

Gruß
hepi