Es ist dann auch nicht ein "Kanal", sondern was neues, evtl. ein "Programm" oder ein anderes, passendes Wort (passende Worte finden ist immer die größte Herausforderung beim Entwickeln...).
Oder "Sender"...und den Begriff "Bouquet" sollte man auch noch ins Spiel bringen, wenn man schon diese Baustelle im VDR Core aufmacht 
Ciao Louis
Es ist dann auch nicht ein "Kanal", sondern was neues, evtl. ein "Programm" oder ein anderes, passendes Wort (passende Worte finden ist immer die größte Herausforderung beim Entwickeln...).
"Favorit bzw. Favoriten Liste" wäre sicher passender. Ist ja auch schon ein längeres Thema. Damit ließe sich dann vieles Weiteres aus der Welt schaffen.
Bei "Sender" denke ich an z.B. "ARD", und die senden ja auf mehreren Kanälen (teilweise das gleiche Programm). 
"Favoriten" wäre auch eine Möglichkeit, weil die Zapping-Liste nicht zwangsläufig alle möglichen Kanäle umfassen muss.
Ist "Bouquet" nicht der Sammelbegriff für alle Kanäle eines Senders?
https://de.wikipedia.org/wiki/Bouquet_(digitales_Fernsehen)
Lars.
Moin,
Ist "Bouquet" nicht der Sammelbegriff für alle Kanäle eines Senders?
nein, ich meine damit wohl das gleiche wie Argus. Im Prinzip das schon im VDR bestehende Konzept der Kanalgruppen, aber mit der Erweiterung, dass zwischen den Kanalgruppen (oder Favoriten, oder Bouquets, oder wie auch immer ) und den (virtuellen) Kanälen eine n:m Beziehung besteht...ein Kanal kann also in mehreren Kanalgruppen sein. Aktuell ist das ja eine 1:n Beziehung.
Hängt auch nicht zwangsläufig dem Thema dieses Threads zusammen, meine Anmerkung bezog sich nur darauf, dass falls diese Stelle im VDR Core angefasst werden würde, das gleich mit implementiert werden könnte
Ciao Louis
weil die Zapping-Liste nicht zwangsläufig alle möglichen Kanäle umfassen muss.
damit könnte den Leuten, die jetzt das "Kanäle aktualisieren" aus verständlichen Gründen deaktivieren und dadurch div. Probleme bekommen, auch geholfen werden. Man braucht ja auch nur mal schauen, wie es die "Großen" so handhaben. Bsw. bei Kathrein ist es so, das dort zwar eine "gesamte Kanalliste" existiert, die vom Receiver erstellt und aktualisiert wird, jedoch nicht vom User editiert werden soll. Dort liegt alles wie Kraut und Rüben - eben so wie es rein kommt. Aus dieser Liste kreiert man sich gleich zu Beginn dann seine aus bis zu 8 Favoriten-Listen, die dann nach eigenem Gusto völlig frei editiert und sortiert werden können. Mit diesen Listen bedient man danach den Receiver.
damit könnte den Leuten, die jetzt das "Kanäle aktualisieren" aus verständlichen Gründen deaktivieren und dadurch div. Probleme bekommen, auch geholfen werden.
Das hängt von den Problemen ab. Wenn die Provider z.B. defekte Daten senden und damit die PIDs o.ä. in den Kanälen durcheinander bringen, will man die weiterhin nicht aktualisieren.
Die Favoritenliste(n) enthalten ja bestenfalls nur Channel-IDs, d.h. das Tuning findet immer noch mit den Parametern statt, die in der channels.conf sind.
Eine eigene Zap-Liste (oder auch mehrere) für Live-TV ist ja relativ klar (und vielleicht auch gar nicht so schlimm einzubauen). Aber wie sieht es denn mit Timern aus? Sollen die auch dynamisch zwischen verschiedenen Kanälen wechseln können, je nachdem, welcher gerade frei ist? Wenn ja, dann braucht man das Mapping der "gleichen" Kanäle unabhängig von der Live-TV-Zap-Liste.
Lars.
Eine eigene Zap-Liste (oder auch mehrere) für Live-TV ist ja relativ klar (und vielleicht auch gar nicht so schlimm einzubauen). Aber wie sieht es denn mit Timern aus? Sollen die auch dynamisch zwischen verschiedenen Kanälen wechseln können, je nachdem, welcher gerade frei ist? Wenn ja, dann braucht man das Mapping der "gleichen" Kanäle unabhängig von der Live-TV-Zap-Liste.
Aus meiner Sicht wären es drei Listen:
1. channels.conf in der jetzigen Form
2. eine "Senderliste", die die "gleichen" Kanäle zusammenfasst, also sowas in der Art (jeweils mit channel-ids der "echten" Sender):
"Das Erste" --> Das Erste HD 1080p DVB-T2, Das Erste HD 720p Sat, Das Erste SD
...
3. Die "Favoritengruppen" mit der n:m Verknüpfung zwischen den Gruppen und den "Sendern" aus 2.
Timer würden sich dann auf die zweite Liste beziehen...damit sollte man dann eigentlich alles abbilden können.
Ciao Louis
Eine eigene Zap-Liste (oder auch mehrere) für Live-TV ist ja relativ
klar (und vielleicht auch gar nicht so schlimm einzubauen). Aber wie
sieht es denn mit Timern aus? Sollen die auch dynamisch zwischen
verschiedenen Kanälen wechseln können, je nachdem, welcher gerade frei
ist? Wenn ja, dann braucht man das Mapping der "gleichen" Kanäle
unabhängig von der Live-TV-Zap-Liste.
Da bin ich auf jeden fall für!
Ich habe häufig Aufnahmen, die ich zwar gern auf dem Sender mit der besten verfügbaren Qualität aufnehmen möchte, mir aber die Tatsache, dass der VDR die aufnimmt wichtiger ist als die Qualität. Dann würde ich ungern bei Timerkonflikten auf die Aufnahme verzichten, sondern sie dann lieber über einen anderen Empfangsweg aufnehmen.
Ich sehe es auch langsam so, dass man sinnvollerweise eine "rohe" Kanalliste (nennen wir sie services.conf) hat, wo die Kanäle mit ihren Empfangswegen definiert sind und eine virtuelle Kanalliste (virtualchannels.conf), in der die Kanäle mit ihren verschiedenen Empfangswegen definiert sind.
Ich sehe den Wunsch nach Favoritenlisten als gesondertes und eigenständig zu betrachtendes Problem.
Hier würde es darum gehen, falls ein Kanal gerade von keinem(!) verfügbaren device zu empfangen ist, eine Art Notfall-Kanal mit geringfügigen Einschränkungen (SD statt HD, etc.) zu generieren.
Das klingt machbar.
Alles andere wird das hier zu einem z.Z. unlösbaren Problem ausufern lassen.
Das hängt von den Problemen ab. Wenn die Provider z.B. defekte Daten senden
das aktuelle Problem meinte ich dabei gar nicht.
Einige User möchten bsw. nicht, das sich die Kinder unbemerkt die 0900er Sender anschauen (die beim automatischen Aktualisieren aber immer wieder auftauchen würden). Wenn man das konsequent lösen wollte, dann könnte man den Zugriff auf die "volle Kanalliste" per Zugriff einschränken und Papa, Mama und Kinder hätten jeweils Ihre eigene Liste (evtl. auch mit Zugriff)
OK ist OT und geht hier wohl etwas zu weit. Vielleicht sollte man das insgesamt mal anfassen.
Hi wirbel,
Alles andere wird das hier zu einem z.Z. unlösbaren Problem ausufern lassen.
kannst du diese Aussage auch begründen?
Ciao Louis
Warum sollte ich das tun?
wirbel, das was du willst, bedeutet, dass ein device Daten eines TS liefert, die es normalerweise nicht liefern würde. Da gibt es aber das Problem, dass die PIDs des Kanals, den der vdr angefordert hat, nicht mit denen der gelieferten TS-Pakete übereinstimmt. Deshalb müsste man die PIDs auf die des eigentlich gewollten Kanals mappen, was aber bedeutet, dass man die ganzen TS-Pakete kopieren müsste, da die Original-TS-Pakete des liefernden devices nicht verändert werden dürfen, weil sonst andere receiver dieses device durcheinander geraten. Auch ein Anpassen der PIDs des geforderten Kanals auf die des tatsächlichen Kanals fällt aus, da man dann falsche PIDs in der channels.conf bekommen würde.
Deshalb der Ansatz, den Kanal nicht im Hintergrund durch ein Plugin mit virtuellen devices auszutauschen, sondern den vdr entsprechend anzupassen, so dass er selbst die alternativen Kanäle durchprobiert, bis er Daten bekommt. Dadurch wird direkt das richtige device angesprochen, die PIDs passen zum geforderten Kanal und alles geht seinen gewohnten Weg.
Wenn man jetzt aber die normale channels.conf zum Zappen benutzt und man plötzlich ganz woanders in der Liste landet, weil ein device blockiert ist und auf einen Alternativ-Kanal gewechselt wird, kommt man mit den Pfeiltasten nicht mehr zum vorigen Kanal zurück (es sei denn, man merkt sich da aufwendig irgendwas, ggf. sogar über Neustart-Grenzen hinweg => aufwendig). Deshalb die Idee, für das Zappen eine eigene Liste mit Kanälen zu benutzen, die dann vielleicht neue, eigene IDs nutzt (z.B. "daserste.de" oder andere "globale" IDs für einen Kanal). Mit dieser ID könnte man dann in "alternatives.conf" nach den tatsächlichen Channel-IDs schauen und diese durchprobieren, bis man Daten bekommt.
Und diese Zap-Liste (nennen wir sie einfach mal favorites.conf) kann dann gleich etwas aufgebohrt werden, um z.B. verschiedene (kürzere) Listen zu haben, die man dann nach Bedarf auswählen kann, z.B. Doku-Sender, Musik-Sender, Sport-Sender, Mama-Sender, Papa-Sender, Kinder-Sender usw., so dass man nur die Sender bekommt, die einen gerade interessieren.
Timer können beim Starten dann auch die alternatives.conf benutzen, um zur Not auf einen andere Kanal auszuweichen.
Sollte es keine favorites.conf geben, kann ja weiterhin ganz normal die channels.conf zum Zappen benutzt werden.
EDIT: Neue, globale IDs für die favorites.conf sind natürlich nicht nötig, irgendeine Channel-ID aus alternatives.conf reicht vollkommen, vorzugsweise diejenige, die man am liebsten sehen will.
Lars.
Warum sollte ich das tun?
wirbel, das was du willst, bedeutet, dass ein device Daten eines TS liefert, die es normalerweise nicht liefern würde. Da gibt es aber das Problem, dass die PIDs des Kanals, den der vdr angefordert hat, nicht mit denen der gelieferten TS-Pakete übereinstimmt. Deshalb müsste man die PIDs auf die des eigentlich gewollten Kanals mappen, was aber bedeutet, dass man die ganzen TS-Pakete kopieren müsste, da die Original-TS-Pakete des liefernden devices nicht verändert werden dürfen, weil sonst andere receiver dieses device durcheinander geraten. Auch ein Anpassen der PIDs des geforderten Kanals auf die des tatsächlichen Kanals fällt aus, da man dann falsche PIDs in der channels.conf bekommen würde.
Das ist ein Problem, was für eine Lösung in vdr spricht, korrekt. Ansonsten müßte das Plugin auch noch den TS manipulieren.
Na hier hat sich ja schon einges getan.
Mir gefällt der Ansatz von Klaus noch am besten,weil er schön minimalistisch ist und wohl am einfachsten zu implementieren. Allerdings ist das dann wohl eine Änderung am core. Im Gegensatz zu meiner Idee muss dafür nicht mal eine neue channel-id erzeugt werden für den "virtuellen" Kanal. Alles funktioniert wie bisher nur das der VDR bei "belegtem" Kanal auf eine alternative tuned die er sich aus der Liste raussucht. D.h. die Kanalanzeige bleibt dann auf dem originalkanal und das weiterzappen funktioniert wie erwartet.
Da hoffe ich mal das Klaus da weiterhin drüber nachdenkt es zu implementieren
Ich grab das mal aus, vielleicht tut sich ja was 
Ich darf mich hier anschliessen...
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
![:]](https://www.vdr-portal.de/images/smilies/pleased.gif "Freude"){kind=small}