Überlegungen zur channels.conf für DVB-C/S/T Mischbetrieb

  • Hallo,


    Mit dem Aufkommen, von DVB-T nehme ich an, dass der Mischbetrieb immer mehr zum Thema werden wird. (Persönlich, bin ich auch dabei einen Mischbetrieb in Betracht zu ziehen.)


    Folglich, wollte ich hier schon mal einen Thread mit Überlegungen starten, wie das Format der channels.conf des VDR erweitert werden könnte, damit beim Mischbetrieb ZDF gleich ZDF bleibt (um nur einen Beispiel zu nennen), unabhängig von welcher DVB Quelle der Sender kommt. (Im Augenblick, sieht der VDR ja zum Beispiel ZDF von DVB-T als einen anderen Sender als ZDF von DVB-C oder DVB-S an.)


    Ich könnte mir zum Beispiel folgende Erweiterung der channels.conf vorstellen: Anstatt in jeder Zeile der channels.conf nur einen einzigen Sender mit genau einer Quelle anzugeben, könnte man das Format so erweitern, dass man mehrere Quellen angeben darf.


    Nehmen wir wieder das Beispiel mit ZDF. Im Augenblick hat man zwei Zeilen in der channels.conf bei DVB-T und DVB-C Mischbetrieb; nämlich:
    ZDF dvb-t-parameter
    ZDF dvb-c-parameter
    Wäre es nicht möglich einfach daraus folgendes zu machen:
    ZDF dvb-c-parameter dvb-t-parameter


    Dies könnte dann für den VDR nicht nur bedeuten, dass es für den ZDF zwei Quellen gibt, sondern auch dass dvb-c vor dvb-t zu benutzen ist, da es an erster Stelle steht.



    Könnte man das nicht so hinkriegen, dass das neue Format abwärtskompatibel zum aktuellen Format bleibt? Nichts würde ja einen Benutzer hindern, die zwei ZDFs in zwei verschiedenen Zeilen zu lassen.


    Dem VDR muss jedoch auch bewusst sein, dass Mischbetrieb nicht gleich Dualbetrieb ist. Er soll zum Beispiel während einer Aufnahme nicht zwischen den Quellen hin und her springen, da die Sender auf den verschiedenen Quellen nicht synchron laufen.


    Wahrscheinlich gibt es noch andere Probleme bei einer solchen Formaterweiterung die mir wegen meinen mangelnden Kenntnissen gar nicht bewusst sind. Vielleicht gibt es auch bessere Ansätze den Mischbetrieb im VDR noch mehr zu unterstützen.


    Vielen Dank im Voraus für jede Stellungnahme.


    MfG


    Ludi

  • Einfacher wäre es als drittes Feld des Sendernamens (z.B.) den verbindlichen Sendernamen http://www.vdr-wiki.de/wiki/in…n#Verbindliche_Kanalliste anzugeben. Z.B.:

    Code
    1. Das Erste;ARD;ard.de:11837:hC34:S19.2E:27500:101:102=deu,103=mis;106=deu:104:0:28106:1:1101:0


    dann wüsste der VDR welche Kanäle den selben Inhalt haben (alle die den selben dritten Namesparameter haben). Und als nützlichen Nebeneffekt könnte der VDR (d.h. die Plugins dafür) die Senderlogos und externes EPG automatisch zuordnen.


    Sowas müsste man dann natürlich manuell einpflegen. Denn der VDR kann nicht feststellen welche Sender eigentlich identisch sind.


    BTW: Es gibt (gab) schon einen Patch der sowas macht.


    cu


    PS: Das führt eh zu nix, aber schön wenn man seine Wünsche nochmal niederschreiben darf ;)

  • Interessantes Thema. Historisch ist der alternative channel Patch ein Lösungsansatz, welcher heute nicht mehr funktioniert / nicht mehr gepflegt wird.


    In der Praxis geht es ja um die Zuordnung von EPG-Daten zu Channel-IDs. Ein EPG Event (eine Sendung) ist immer einem Kanal zugeordnet. Die VDR-internen Channel-IDs, die aus Parametern in der channels.conf gebildet werden, beziehen sich aber immer auf einen bestimmten Provider und sind nicht provider-übergreifend nutzbar. Im Zusammenhang mit xmlTV-EPGs wurde von den xmltv2vdr-Plugin-Fans schon angeregt, eine Liste mit Unique-IDs für alle Channels anzulegen, was auch auf der Wiki-Seite begonnen worden ist unter dem Punkt "Verbindliche Kanalliste".


    Mit Channelpedia ist nun eine Basis geschaffen worden, die im Wiki zu findenden provider-übergreifenden xmltv2vdr-Plugin-Kanal-IDs mehr oder minder automatisch zu den provider-spezifischen Kanal-IDs zu mappen.


    Beispiel ZDF:
    Unique ID a la xmltv: zdf.de
    Dieser Kanal hat auf S19.2E zwei Kandidaten: Einmal "ZDF HD" und einmal "ZDF" (SD).
    Die VDR-internen Sender-IDs dafür sind:
    S19.2E-1-1011-11110
    S19.2E-1-1079-28006
    Bei DVB-T-München wäre die VDR-interne ID für "ZDF" diese hier: T-8468-514-514


    Nun muss es eine Möglichkeit geben, diese verschiedenen IDs, welche in unserem Beispiel keinerlei Gemeinsamkeit haben, doch möglichst automatisch einander zuzuordnen in einer 1:N Beziehung und diese Beziehungen abzulegen. Da die deutschen Kabel-Provider oftmals die gleichen Werte für SID, NID und TID nutzen wie beim Satelliten (S19.2E), könnte man eine Zuordnung über diese IDs zumindest "oft" für DVB-S und DVB-C hinbekommen, vgl. diese Übersicht. Ansonsten muss man auf Namensähnlichkeit matchen.


    Diese Liste von Beziehungen muss nicht in der channels.conf abgelegt werden, kann auch in einer weiteren conf-Datei passieren.


    Channelpedia ließe sich erweitern, so dass man entweder fertig generierte Zuordnungstabellen für seine eigenen Provider bekommt oder ein Skript generiert bekommt, dass man lokal laufen lassen kann, um auf Basis der eigenen channels.conf so eine Zuordnungstabelle zu erstellen. Und EPGSearch und/oder der VDR-Core müssten erweitert werden, um das gewonnene Wissen intelligent zu nutzen.


    Eine solche Tabelle kann dann für verschiedenste Dinge genutzt werden, zum Beispiel auch für Kanallogo-Zuordnung.


    Allerdings gibt es verschiedene Probleme zu lösen:

    • Beim Beispiel ZDF haben wir oben drei Varianten in drei Qualitätsstufen. (1) HD - (2) SD vom Sat - (3) SD von DVB-T. Wie sollen die daraus resultierenden Probleme intelligent gelöst werden können, womöglich noch bei aktivem LNB-Sharing? Für welche Suctimer soll mindestens HD aufgezeichnet werden, für welche Suchtimer reicht DVB-T-Qualität?
    • Was ist, wenn es Sender mit regionalen Ausprägungen gibt, die zu 90% das gleiche EPG haben, aber die restlichen 10% verschiedene Sendungen sind?
    • Welches EIT-EPG gewinnt, wenn sich ZDF und ZDF HD unterscheiden? Die EPG Einträge würden nur noch für "zdf.de" abgelegt werden, aber nicht mehr getrennt für "ZDF HD" und "ZDF".
    • Wie löst man es, wenn ein Kanal 12 Stunden am Tag Sender A ausstrahlt und 12 Stunden am Tag Sender B?
    • Kanal XY gibt es in SD und HD, aber die HD-Variante ist verschlüsselt und nur eine Stunde am Tag frei empfangbar.
    • Bei Sat-Kanälen kann man Kanäle mit HD-Qualität erahnen am Parameter "S1" für DVB-S2. Trotzdem mutmaßt man nur, dass hier nun ein Signal in 1080i/720p kommt. Bei DVB-C erkenne ich am Kanal-String nicht, ob ein Kanal ein HD-Kanal ist oder nicht. Einzig die Suche nach "HD" im Kanalnamen hilft mir da.


    Gruß
    hepi

  • Anstatt in jeder Zeile der channels.conf nur einen einzigen Sender mit genau einer Quelle anzugeben, könnte man das Format so erweitern, dass man mehrere Quellen angeben darf.


    auch wenn ich mich wiederhole (das Thema kommt ja alle paar Jahre wieder hoch), sollte meiner Meinung nach die channels.conf so bleiben wie sie ist. Und zwar sollte sie als technische Liste die Ressourcen zur Verfügung stellen, im Hintergrund arbeiten und möglichst nicht vom User verändert werden. Dafür sollte dann eine Favoritenliste dem User zugänglich sein, in dem alles das, was beschrieben wurde und fürs User-Handling wichtig wäre, konfiguriert und bedient wird. Die Einträge der Favoritenliste zeigen dann weiterhin auf die Zeilen der etablierten channels.conf. So kann technisch alles beim Alten bleiben mit dem Kanäle finden, handeln usw. Es braucht nur eine User-Zwischenschicht mit Interface.


    Gruß Fr@nk

  • Und zwar sollte sie als technische Liste die Ressourcen zur Verfügung stellen, im Hintergrund arbeiten und möglichst nicht vom User verändert werden. Dafür sollte dann eine Favoritenliste dem User zugänglich sein, in dem alles das, was beschrieben wurde und fürs User-Handling wichtig wäre, konfiguriert und bedient wird.


    Jup, Fav. Listen fehlen den VDR wirklich.


    Trozdem sollten Metainfos IMHO in die channels.conf (oder in eine zweite verknüpfte Datenbank, jedenfalls nicht in die Fav. Liste), denn diese werden im Hintergrund benötigt und nicht vom User.


    Allerdings gibt es verschiedene Probleme zu lösen:


    Jup, die Frage ist wieweit man es treiben sollte?


    Erstmal gibts ja nur identische Sender mit verschiedenen Quellen (und damit Quallitätsstufen (HD fällt hier mit DVB-T zusammen nur unter Auflösung/Bitrate)), das könnte man über Prioritäten lösen.


    Zweitens sind Regionalprogramme für die Kanalliste interessant (die Dritten oder die Östereichvarianten der Privaten), hier handelt es sich um andere Sender (also Sat.1 DE ist ein anderer Sender wie Sat.1 AT) die man aber in der GUI verknüpfen könnte (neben Audio, Subtitle halt ne Bildauswahl für diese Alternativvarianten).


    cu

  • Trozdem sollten Metainfos IMHO in die channels.conf, denn diese werden im Hintergrund benötigt und nicht vom User.


    Die channels.conf ist ja nicht die einzige Datei, in der der VDR Daten verwaltet, die der User nicht anschauen muss.


    Die Frage, in welcher Datei es gespeichert wird, ist IMHO das kleinste Problem von allen. Alle anderen Probleme sind hier spannender und die Frage ist, ob sie überhaupt lösbar sind.


    Gruß
    hepi

  • Alle anderen Probleme sind hier spannender und die Frage ist, ob sie überhaupt lösbar sind.


    AFAIK gibt es schon komerzielle Receiver die die HD Varianten der SD Sender kennen, genauso wie sie die Regionalsender unter einen Eintrag bündeln und als alternative Videospuren (Halt wie die Auswahl des Fusballspiels bei Sky Bundesliega) presentieren.


    Also geben tuts das schon da draussen.


    Wobei das hier ne Idee ist die Klaus gefallen muss, weil einen weiteren Monsterpatch im VDR wird niemand pflegen wollen. Und damit ist das dann vermutlich etwas worüber man mal für die 1.9 nachdenken kann ;)


    cu

  • oder in eine zweite verknüpfte Datenbank, jedenfalls nicht in die Fav. Liste


    klar, ich würde jetzt den Begriff Favoritenliste nicht so eng sehen (wie man es von den Receivern und TVs her kennt). Auf jeden Fall würde ich zwischen technischen Parameterdaten und User Daten dann trennen.


    Gruß Fr@nk

  • Da VDR die Freiheit bietet, alle nur erdenklichen Empfangsarten (DVB-S, DVB-C, DVB-T, IPTV) miteinander zu kombinieren, wird es komplexer.


    Eine einfacher zu realisierende Kombination wäre DVB-S(2) + DVB-C, weil hier die "Sendequalität" praktisch gleich gut ist. Warum würde jemand das tun? Jemand würde das in der Praxis nur tun, wenn er a) einen guten Kabel-Provider hat ohne Grundverschlüsselung, der b) interessante Sender bietet, welche nicht erhältlich sind auf den angepeilten Sat-Positionen, und wenn er c) nicht mehr DVB-S2-Tuner hinzufügen kann, weil es Kabelknappheit oder Slot-Knappheit gibt.


    DVB-T wird man wahrscheinlich zu DVB-C dazunehmen (in Deutschland), wenn man keine Schüssel will und eine Grundverschlüsselung hat über DVB-C und dort keine Privatsender empfangen kann. Das ist eher eine "Notlösung", wegen der schlechteren Bildqualität über DVB-T (derzeit in Deutschland). Dieser Qualitätsunterschied macht schon etwas aus.


    Wenn HD über DVB-T(2) mal in Deutschland an der Tagesordnung ist, wird die Sache wieder anders aussehen.


    Gruß
    hepi

  • Ich will jetzt nicht zu sehr OT werden, aber wenn hier schon Kritik an der channels.conf geübt wird, dann sollte meiner Meinung nach auch gleich ein vernünftiges Bouquet Management mit eingebaut werder, so wie z.B. bei Neutrino. ;)

  • Auf jeden Fall würde ich zwischen technischen Parameterdaten und User Daten dann trennen.


    Ja unbedingt. Es ist ja jetzt z.B. praktisch unmöglich einen Sender umzubenennen aber trotzdem das automatische update aktiv zu halten. Auch ein Nachteil der sich durch die Vermischung ergibt.


    Sinnig wäre IMHO eine channels.conf die nur die automatisch erhaltenen (Senderscan, Channelpedia) Empfangsparameter hält (ohne Gruppen (":") und all das), dann eine zweite (wird von der Distribution (evtl. auch über Channelpedia) geliefert) verknüpfte für Metadaten (Quallität, Priorität, Eindeutiger Kanallname usw.). Und dann eine dritte als Fav. Liste die nur auf die beiden verknüpften verweist (die ist dann für die GUI).


    Evtl. wäre es erstmal sinnig ein Grundgerüst in dieser Art zu schaffen bevor man von alternate Channels Mechanismen träumt? ;)


    Ich will jetzt nicht zu sehr OT werden, aber wenn hier schon Kritik an der channels.conf geübt wird, dann sollte meiner Meinung nach auch gleich ein vernünftiges Bouquet Management mit eingebaut werder, so wie z.B. bei Neutrino. ;)


    Ach hat Neutrino das jetzt?


    Als ich das noch nutzte hatte Neutrino (genau wie die VDR) nur eine Kanalliste in der Gruppen reingemurkst wurden. Nur die Anzeige in der GUI war Gruppenorientiert. Enigma hatte es schon immer vorbildlich gemacht.


    cu

  • Ein anderes Praxis-Problem ist, dass meine Erfahrungen mit Channelpedia zeigen, dass es viele Nutzer gibt, die eine über Jahre verwucherte Channels-conf besitzen, die bei mehreren Sat-Positionen 3000-5000 Kanäle enthält, worin sich in der Praxis eine Menge invalider Kanäle befindet. Es kann theoretisch also sein, dass ein Nutzer in seiner channels.conf eine Zeile für ZDF drin hat auf einem Transponder, der seit ein paar Jahren schon nicht mehr existiert. Oder einfach Kanaldoppler. Derzeit gibt es keinen Validator für die eigene channels.conf, der einem solche Leichen aufzeigt. Leichen können auch bei Fehlfunktionen von Diseqc-Switches entstehen, wenn plötzlich der VDR auf Sat-Position A neue Kanäle findet, die aber in Wirklichkeit auf Sat-Position B liegen.


    Eine ältere w_scan-Version lieferte mir bei einem frischen Kanalscan from scratch etwa 150 Dubletten-Kanäle (also 150 Kanäle waren jeweils doppelt drin). Das ist mir nur aufgefallen, weil Channelpedia sich beim Import beschwert hat. Wer sonst schaut sich seinen Kanalscan von oben bis unten durch?


    Channelpedia liefert auch ab und zu falsche Kanaleinträge aus, wenn ich mal einen Bug einbaue.


    Es fehlt also ein "unabhängiger" Plausibilitätscheck, um die eigene channels.conf zu entrümpeln. Ich muss nochmal testen, unter welchen Bedingungen eigentlich der VDR selbst mit der Faust auf den Tisch haut und sagt: Mit dieser channels.conf weigere ich mich zu arbeiten.


    Gruß
    hepi

  • worin sich in der Praxis eine Menge invalider Kanäle befindet.


    Ich habe mir die "frontend <nr> timed out while tuning to channel" Meldungen in ne extra Logdatei gelegt und Miste gelegentlich aus. Weil in der Tat behält der VDR die ewig drin.
    Aber ich denke es gibt da keine wirklich gute Möglichkeit die automatisch loszuwerden. Das beste was mir einfällt ist das die "Tunen daruf geht nicht" Versuche zu speichern und sie automatisch zu löschen wenn sie 30 Tage nicht erreichbar waren.


    Leichen können auch bei Fehlfunktionen von Diseqc-Switches entstehen, wenn plötzlich der VDR auf Sat-Position A neue Kanäle findet, die aber in Wirklichkeit auf Sat-Position B liegen.


    Witzig, das Problem habe ich auch. Aber ich denke bei mir ist es der SOURCECAPS Patch des 1.6er VDR.



    Ich muss nochmal testen, unter welchen Bedingungen eigentlich der VDR selbst mit der Faust auf den Tisch haut und sagt: Mit dieser channels.conf weigere ich mich zu arbeiten.


    Zumindest die doppelten fliegen automatisch raus.


    cu

  • Derzeit gibt es keinen Validator für die eigene channels.conf, der einem solche Leichen aufzeigt


    ja, das Thema beschäftigt mich auch schon seit Ewigkeiten.
    Leider gibt es keine richtige Lösung dafür. Öfter habe ich meine channels.conf schon mal ausgemistet, indem ich dann per externen Channeleditor alle kanalnamen mit bsw. vorangestelltem "alt" geimpft hatte. Nach einem Scan blieben dann die Leichen übrig (die hatten immer noch alt) , die habe ich dann nach Sichtung im VDR auf Ableben händisch gelöscht .


    Gruß Fr@nk

  • Es fehlt also ein "unabhängiger" Plausibilitätscheck, um die eigene channels.conf zu entrümpeln. Ich muss nochmal testen, unter welchen Bedingungen eigentlich der VDR selbst mit der Faust auf den Tisch haut und sagt: Mit dieser channels.conf weigere ich mich zu arbeiten.


    Du redest mir, und sicherlich auch noch vielen anderen Useren aus der Seele.... :)


    Schön wäre es, wenn es eine Channelscan GUI (oder von mir aus auch auf der Console) geben würde, die ungültige Einträge einfach löscht.


    BTW: Auch das kann Neutrino. :)

  • Hallo,


    Erstens Danke für die interessante Diskussion.

    Quote

    Einfacher wäre es als drittes Feld des Sendernamens (z.B.) den verbindlichen Sendernamen http://www.vdr-wiki.de/wiki/index.php/Xm…iche_Kanalliste anzugeben. Z.B zdf.de

    Quote

    In der Praxis geht es ja um die Zuordnung von EPG-Daten zu Channel-IDs.

    Nicht nur: es geht auch darum das EPG mit Suchtimers zu durchforsten und Aufnahmen zu programmieren. Natürlich sollte die Aufnahme dann bei der Quelle stattfinden, die die beste Qualität liefert. Muss dann nicht auch der Programmierer des Plugins, das die Suchtimers implementiert mitziehen, und die Suchen nach den Einheitlichen Namen (ard.de) durchführen anstatt nach den Sendern aus der channels.conf?


    Quote

    Mit Channelpedia ist nun eine Basis geschaffen worden, die im Wiki zu
    findenden provider-übergreifenden xmltv2vdr-Plugin-Kanal-IDs mehr oder
    minder automatisch zu den provider-spezifischen Kanal-IDs zu mappen.

    Ich sehe die verbindlichen Sendernamen jedoch noch nicht auf den Channelpediaseiten. Wären Sie dort vielleicht nicht besser aufgehoben als beim Wiki vom xmltv2vdr plugin? Außerdem, es wäre vielleicht gut, wenn die Leute nicht nur ihre channels.conf für die Channelpedia zur Verfügung stellen würden, sondern auch die Mappings zwischen den Sendern aus der channels.conf und den Sendernamen die sie im xmltv2vdr benutzen. Ich sage jetzt bewusst nicht 'verbindliche Sendernamen', da es wahrscheinlich auch Leute gibt, die eigene Grabber benutzen und ihr eigenen einheitlichen Sendernamen definiert haben. Auf diese Weise würden auch Informationen in die Channelpedia gelangen, welche einheitlichen Namen die Leute den Sendern aus der channels.conf geben. Das könnte dann mit der Zeit das festlegen von weiteren verbindlichen Namen von noch nicht behandelten Sendern unterstützen.


    Quote

    Beim Beispiel ZDF haben wir oben drei Varianten in drei Qualitätsstufen.
    (1) HD - (2) SD vom Sat - (3) SD von DVB-T. Wie sollen die daraus
    resultierenden Probleme intelligent gelöst werden können, womöglich noch
    bei aktivem LNB-Sharing? Für welche Suctimer soll mindestens HD
    aufgezeichnet werden, für welche Suchtimer reicht DVB-T-Qualität?

    Wie wäre es mit folgender Lösung: Der Benutzer stellt beim Suchtimer ein, von welcher Quelle die Aufnahme zu machen ist. Außerdem sollte er auch eine Einstellung haben, um Festzulegen, was geschehen soll, falls die Quelle schon durch eine andere Aufnahme besetzt ist. Als Optionen könnte ich mir folgendes vorstellen: 1. Konflikt melden und der Benutzer legt dann fest, welche Quelle was aufnehmen soll (das wäre wahrscheinlich was ich benutzen wurde) 2. Der VDR sucht sich automatisch ein freie Quelle aus.


    Quote

    Was ist, wenn es Sender mit regionalen Ausprägungen gibt, die zu 90% das
    gleiche EPG haben, aber die restlichen 10% verschiedene Sendungen sind?

    Ich sehe dies nicht speziell als ein Problem des Mischbetriebs an. Aber wie wäre es mit folgendem Lösungs ansatz: Kann man nicht in diesem Fall sagen, dass wir es mit zwei Sendern zu tun haben: Einen Basissender der 90% der Zeit läuft und einen Regionalsender der 10 % der Zeit läuft. Für das EPG würde ich ähnlich verfahren: Der Basissender liefert das Basisepg; der Regionalsender liefert das spezielle EPG; dieses hat Vorrang zum Basisepg und überschreibt die entsprechenden Einträge des Basisepg.


    Quote

    Welches EIT-EPG gewinnt, wenn sich ZDF und ZDF HD unterscheiden? Die EPG
    Einträge würden nur noch für "zdf.de" abgelegt werden, aber nicht mehr
    getrennt für "ZDF HD" und "ZDF".

    Wenn sich ZDF und ZDF HD unterscheiden, sind es nicht mehr die gleichen Sender und sollten dann wahrscheinlich nicht mehr beide zu zdf.de gemappt werden.


    Quote

    Wie löst man es, wenn ein Kanal 12 Stunden am Tag Sender A ausstrahlt und 12 Stunden am Tag Sender B?

    Dies ist wiederum ein Problem, das nicht direkt mit dem Mischbetrieb zu tun hat. Die erste Lösung die mir einfällt, ist eine weitere Übergeordnete Schicht einzuführen: Sender 5 der Favoritenliste entspricht xy.de von 8h00 bis 14h00 und yz.de den Rest der Zeit. Dies würde auch ein weitere Lösung für das Regionalsenderproblem darstellen. Aber irgendwie gefällt mir diese Lösung nicht; vielleicht weil ich 3 Ebenen (channels.conf, ard.de, favoriten) als zuviel betrachte.


    Quote

    Kanal XY gibt es in SD und HD, aber die HD-Variante ist verschlüsselt und nur eine Stunde am Tag frei empfangbar.

    Ist das nicht das gleiche Problem wie ein Kanal das zwei verschiedene Sender zeitabhängig ausstrahlt?


    Quote

    Bei Sat-Kanälen kann man Kanäle mit HD-Qualität erahnen am Parameter
    "S1" für DVB-S2. Trotzdem mutmaßt man nur, dass hier nun ein Signal in
    1080i/720p kommt. Bei DVB-C erkenne ich am Kanal-String nicht, ob ein
    Kanal ein HD-Kanal ist oder nicht. Einzig die Suche nach "HD" im
    Kanalnamen hilft mir da.

    Die Auflösung und Format des Videos des Senders gibt Auskunft ob der Sender SD oder HD ist; ich glaube schlimmstenfalls, braucht der VDR nur einmal jeden Sender zu tunen, um diese Information zu erhalten und irgendwo zu speichern.


    Quote

    Die Frage, in welcher Datei <die Metadaten> gespeichert wird, ist IMHO das kleinste
    Problem von allen. Alle anderen Probleme sind hier spannender und die
    Frage ist, ob sie überhaupt lösbar sind.

    Dem stimme ich zu.

    Hoffentlich liest er hier mit. 8-)


    Quote

    DVB-T wird man wahrscheinlich zu DVB-C dazunehmen.
    Das ist eher eine "Notlösung", wegen der schlechteren Bildqualität über DVB-T.
    Wenn HD über DVB-T(2) mal in Deutschland an der Tagesordnung ist, wird die Sache wieder anders aussehen.

    In Frankreich stehen seit längerem 4 HD Sender über DVB-T zur Verfügung. TF1 HD, France2 HD, M6 HD und ARTE HD; in 1080i soviel ich weiß.



    Wäre die Channelpedia nicht der erste Baustein zur Herstellung einer solchen Lösung? Als nächster Schritt, wäre vielleicht das Einbringen der Mappings von xmltv2vdr angebracht, um Daten zu erhalten um weitere verbindlichen Sendernamen zu definieren. Ob jetzt am Ende eine einfache Favoritenliste stehen sollte oder ein Bouquet Management ähnlich wie bei Enigma, sei dahingestellt.


    Quote

    Ein anderes Praxis-Problem ist, dass meine Erfahrungen mit Channelpedia
    zeigen, dass es viele Nutzer gibt, die eine über Jahre verwucherte
    Channels-conf besitzen, die bei mehreren Sat-Positionen 3000-5000 Kanäle
    enthält, worin sich in der Praxis eine Menge invalider Kanäle befindet.

    Das mag vielleicht ein Problem für die Channelpedia sein, aber allein die Tatsache, dass "viele" Benutzer von veralteten Einträge nicht gestört werden zeigt dass es für sie nicht richtig ein Problem darstellt. Ich nehmen an, hauptsache die Kanäle die ihn interessieren funktionieren. Persönlich befinden sie sich bei mir oben in der channels.conf in Gruppen eingeteilt. Die letzte Gruppe enthält die Liste mit den Tausenden Sender (2Satpositionen) die mich nicht interessieren. Ob da auch Einträge darunter sind, die nicht mehr funktionieren stört mich nicht wirklich; und seit es die Channelpedia online gibt, stört es mich noch weniger. Wenn ich einen Sender suche, versuche ich ihn dort zu finden und kopiere ihn oben in meinen channels.conf dazu (nachdem ich die Satellitenbezeichnung anpasse; die Channelpedia benutzt zb 13E, ich dagegen 13.0E).


    Für die Sender über Satellit: Könnte ein Plausibilitätscheck nicht über einen Vergleich mit KingOfSat oder Lyngsat durchgeführt werden, falls diese es erlauben?


    Schließlich, durch diese Diskussion scheint sich herausgestellt zu haben, dass eine Verbesserung des Mischbetriebs beim VDR nicht notwendigerweise eine Erweiterung des Formats der channels.conf fordert. Es könnte auch durch einen Überbau auf die channels.conf realisiert werden. Die frage in diesem Fall wird jedoch sein: wie bekommen wir die Entwickler von Plugins (ich denke hier insbesondere an die Entwickler der Suchtimers) bei einem distributionsspezifischen Aufbau zum Mitmachen?


    MfG


    Ludi

  • Eine einfacher zu realisierende Kombination wäre DVB-S(2) + DVB-C, weil hier die "Sendequalität" praktisch gleich gut ist. Warum würde jemand das tun? Jemand würde das in der Praxis nur tun, wenn er a) einen guten Kabel-Provider hat ohne Grundverschlüsselung, der b) interessante Sender bietet, welche nicht erhältlich sind auf den angepeilten Sat-Positionen, und wenn er c) nicht mehr DVB-S2-Tuner hinzufügen kann, weil es Kabelknappheit oder Slot-Knappheit gibt.


    oder d, weil die Schüssel hinter Glas ist (Wohnungsvertraglich bedingt), welche den kompletten vertikalen Bereich rausfiltert und er ein paar der fehlenden sender im Kabel zu Verfügung hat


    Quote

    DVB-T wird man wahrscheinlich zu DVB-C dazunehmen (in Deutschland), wenn man keine Schüssel will und eine Grundverschlüsselung hat über DVB-C und dort keine Privatsender empfangen kann. Das ist eher eine "Notlösung", wegen der schlechteren Bildqualität über DVB-T (derzeit in Deutschland). Dieser Qualitätsunterschied macht schon etwas aus.


    Dazu müßte die Privaten auch über DVB-T empfangbar sein! Dies ist bei weitem nicht überall so, sondern fast nur in/um größeren Städten!

    Dirk

  • Da der VDR so flexibel konfigurierbar ist, zieht er User magisch an, die kein gradliniges Setup haben. Ein gradliniges Setup wäre: Eine Sat-Schüssel unter idealen Empfangsbedingungen mit Dutzenden von Coax-Kabeln, die in alle Räume des Hauses führen. Bei so einem Setup braucht man nur DVB-S2-Tuner und man ist glücklich.


    Ich meine das nicht böse, aber: Im VDR-Portal tummeln sich dann die Spezis, die eine verdellte Sat-Schüssel haben oder eine Schüssel hinter Glas oder eine mit halb kaputtem LNB oder eine mit Wackelkontakt im Kabel oder zu wenig Kabel im Haus oder eine halb kaputte DVB-Karte, welche bestimmte Frequenzen nicht tunen kann. Die wollen dann irgendwelche Probleme oder Einschränkungen kompensieren durch Mischlösungen. Diese individuellen Sonderfälle sind sicherlich sehr schwer unter einen Hut zu kriegen.


    Das Kanal-Matching mit Unique-IDs ist ja auch ohne DVB-Mischlösung ein Thema. In einem ersten Schritt müsste es ermöglicht werden, ZDF HD und ZDF zu matchen bei Nutzung von DVB-S oder DVB-C.


    Alle weiteren Gedanken zu den Vor-Postern poste ich später.


    Gruß
    hepi

  • Muss dann nicht auch der Programmierer des Plugins, das die Suchtimers implementiert mitziehen, und die Suchen nach den Einheitlichen Namen (ard.de) durchführen anstatt nach den Sendern aus der channels.conf?


    Nein, "ard.de" wäre nix was der Nutzer zu Gesicht bekommt. Der Nutzer würde dann aus einer Senderliste wählen die alle Sender die intern mit "ard.de" getaggt sind in einer Gruppe anzeigt/anwählbar macht. Gute GUI verbirgt solche internas vor dem User.


    Wobei man da noch eine kleine Gruppendiskusion bräuchte um das mal auszubauen. Der einheitliche Sendername bestimmt einen TV Sender, Regionalvarianten, HD/SD und Logos (bei jedem Logopack fängt jeder User nämlich auch erstmal mit dem fummeln an) müsste da noch zusätzlich geflaggt werden.


    Ich sehe die verbindlichen Sendernamen jedoch noch nicht auf den Channelpediaseiten. Wären Sie dort vielleicht nicht besser aufgehoben als beim Wiki vom xmltv2vdr plugin?


    Naja, diese einheitlichen Sendernamen sind ja eine Insellösung (und erstmal nur eine Idee eine Lösung für das Problem zu finden) und ausserhalb von xmltv2vdr nicht wirklich akzeptiert.


    da es wahrscheinlich auch Leute gibt, die eigene Grabber benutzen und ihr eigenen einheitlichen Sendernamen definiert haben.


    Ich hätte es ja gerne gesehen wenn das xmltv2vdr Plugin keine Quellen mit (von dieser Liste) abweichenden Namen akzeptiert. Weil die Idee des Plugins ist es ja so einen Wildwuchs (der am Ende immer dazu führt das jeder User bei jeder Kleinigkeit rumfummeln muss) einzudämmen.


    Aktuell haben Grabber per Definition NUR die Namen aus der VDR WIKI Seite *) zu verwenden, werden andere Namen genutzt sind sie kaputt.


    cu


    *) Auch wenns den Freiheitsgedanken wiederspricht, ohne verbindliche zentrale Registry sind solche Sachen nicht zu lösen.

  • Ich meine das nicht böse, aber: Im VDR-Portal tummeln sich dann die Spezis, die eine verdellte Sat-Schüssel haben oder eine Schüssel hinter Glas oder eine mit halb kaputtem LNB oder eine mit Wackelkontakt im Kabel oder zu wenig Kabel im Haus oder eine halb kaputte DVB-Karte, welche bestimmte Frequenzen nicht tunen kann. Die wollen dann irgendwelche Probleme oder Einschränkungen kompensieren durch Mischlösungen. Diese individuellen Sonderfälle sind sicherlich sehr schwer unter einen Hut zu kriegen.


    Ich denke, das man hier Sachen wie "verdellte Sat-Schüssel", "kaputtes LNB" oder "halb kaputte DVB-Karte" nicht auf eine Stufe stellen darf, wie eine vom Vermieter angebrachte "Glasbehinderung" bei gleichzeitigem Verbot einer sichtbaren Schüssel(die außerhalb der Scheibe unsichtbar anzubringen, ist unmöglich).


    Quote

    Alle weiteren Gedanken zu den Vor-Postern poste ich später.


    Die Gedanken über die Poster kannst auch behalten :D

    Dirk