Virtuelle Kanäle

  • Hallo


    ich habe 3 Karten in meinem PC: DVB-S, DVB-C und DVB-T. So gibt es z.b. die ARD auf 3 unterschiedlichen Programmplätzen in der channels.conf. Meine Überlegung ist es nun ob es möglich ist die 3 Programme zu einem virtuellen Programm zusammenzufassen.
    Also z.B. in der channels.conf einen Eintrag zu machen der so aussehen könnte:
    : ARD; 1;17;23
    Wobei die Nummern 1, 17 und 23 die Programmnummern der realen Transponterbeschreibungen sind. Wenn man nun auf so ein Programm schaltet versucht der vdr die realen Kanäle bis er einen freien findet und nimmt dann den (oder sagt halt channel nicht verfügbar wie bisher auch wenn er bereits belegt ist).


    Ich frage mich nun ob so etwas per plugin zu machen ist oder ob hier der core angefasst werden muss.
    Was meinen die Experten hierzu ?


    mfg
    Jojo

  • Ja die Idee ist gut. Ich seh aber auch schon das mein Ansatz etwas zu kurz geschossen ist und auch die virtuellen Kanäle wohl so etwas wie eine Channel-id brauchen, damit sie in der timers.conf angesprochen werden können.
    Also vielleicht so:
    : ARD; V-1; channel-id;channel-id;channel-id;....
    Wobei dann das V für virtuell steht und die 1 durchnummeriert ist. Aber das sind erstmal nur Details und ich frage mich immer noch ob es überhaupt ein Bedarf ausser bei mir gibt.


    Jojo

  • Melde mal Interesse an


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • Ich melde auch Interesse an!

  • Möglicherweile könntest du das als virtuelles device Plugin anlegen,
    - welches diese virtuellen Kanäle als auf diesem virtuellen device verfügbar an den VDR meldet
    - falls vdr darauf tunen will, selbst auf die (echten) devices Receiver anhängt und deren Daten zurück sendet.



    VDR fragt alle devices nach einem Sender -> virtuelles device meldet diesen Kanal verfügbar, falls es alternative Kanäle hat und deren device frei ist -> VDR sendet tune request an virtuelles device -> virtuelles device tuned auf echten device und hängt dort Receiver an -> virtuelles device sendet TS Daten von echtem device an VDR zurück



    Vorteil:
    a) kein Patch notwendig in VDR core, alles komplett in einem Plugin zu lösen.
    b) keine Änderung an channels.conf nötig (wichtig), das Plugin kann selbst eigene Listen alternativer Kanäle verwalten und abspeichern, bevorzugt als channel-IDs

  • Source V steht schon für analoges Video, siehe sources.conf. Nehmen wir für die Diskussion erst mal X (meinetwegen für "Experiment" oder auch "Crossover").


    Wenn ich mal ein wenig brainstorming betreibe:
    Der vdr fragt die devices reihum, ob sie einen bestimmten Kanal empfangen können, und baut dann anhand der Fähigkeiten und der momentanen Nutzung des devices eine Priorität zusammen und wählt dann eins aus. Es ist sicherlich möglich, ein Plugin zu schreiben, dass entsprechende devices anlegt, die auf so einen virtuellen Kanal reagieren. Aber dann müsste so eins ein anderes device aquirieren, so dass dieses dann die passenden Daten liefert. Da der vdr aber auch dieses andere device direkt fragt, ist das sicherlich eine gute Möglichkeit für einen Konflikt.


    D.h. dann also, dass man das irgendwie direkt in den vdr integrieren sollte. Die Stelle mit der device-Auswahl ist schon ein wenig tricky, also schaut man mal eine Ebene höher, z.B. in das dvbdevice. Da müsste man also die diversen Provides-Funktionen erweitern. Nur anhand der neuen Source X kann das DVB-Device schon mal nicht entscheiden, ob es den Kanal empfangen kann oder nicht, also muss es da erst mal einfach zustimmen (ProvidesSource).


    Bei den anderen Provides-Funktionen hat man Zugriff auf die ganzen Kanaldaten. Nehmen wir nun mal an, das cChannel-Objekt wurde entsprechend um eine Funktion erweitert, mit der man die dahinterliegenden "wahren" Channel-IDs bekommt (nennen wir sie mal GetCrossoverChannelIDs). Die müsste man dann der Reihe nach durchprobieren, bis man einen Treffer landet. Da muss man dann ein wenig aufpassen, dass man nicht in einer Rekursionsschleife landet (hängt ja von der Umsetzung ab).


    Wenn man das erst mal eingebaut hat, dann muss man mal gucken, wo es überall noch klemmt. Da gibt es sicherlich noch diverse Feinheiten, die man so auf die Schnelle nicht überblickt. Da fällt mir z.B. Entschlüsselung ein.


    Ach ja, und man muss natürlich irgendwie dafür sorgen, dass dieser Kanal auch EPG bekommt. Da in Theorie ja das EPG auf allen Kanälen "gleich" sein sollte (mit leichten Unterschieden, weil die verschiedenen Provider ja durchaus unterschiedliche Daten senden können), schlage ich vor, einfach das EPG des ersten (Unter-)Kanals zu kopieren. Da der neue Kanal ja auch seine eigene ID hat, lässt sich das erstmal sicherlich durch ein Plugin wie epgsync o.ä. realisieren. Und die epgd-User müssten dann mal sehen, ob man per epg2vdr das EPG in einen Kanal importiert bekommt, der selbst keine Daten liefert. Aber das geht bestimmt.


    So viel erst mal von mir mit meinen Montagmorgengedanken... :)


    Lars.

  • b) keine Änderung an channels.conf nötig (wichtig), das Plugin kann selbst eigene Listen alternativer Kanäle verwalten und abspeichern, bevorzugt als channel-IDs


    Ich sehe nicht, dass man das Format der channels.conf anpassen muss. Jede neue Source kann ja selbst definieren, was in seinen Parametern drin steht. Und bei den restlichen Feldern trägt man irgend welche Zahlen ein, ähnlich wie bei iptv, pvrinput usw.


    Lars.

  • Nur anhand der neuen Source X


    Wozu eine neue Source? Nicht nötig..

  • Wie willst du beim Raussuchen des passenden Devices verhindern, dass du immer dein eigenes Device bekommst?
    cDevice::GetDevice kannst du ohne Patch nicht dazu bringen, ein bestimmtes zu ignorieren, oder?


    Deshalb dachte ich an eine neue Source, damit man dann nach einem Device für die echte Source suchen kann und damit das eigene Device auszuschließen.


    Lars.

  • Nächste Überlegung:
    Zu jedem echten Device müsste es dann ja jeweils ein virtuelles Device geben, denn ein Device kann ja eigentlich nur einen Transponder zur Zeit liefern (es sei denn, man macht einen ziemlichen Aufwand, verschiedene TS zusammen zu mixen inkl. ggf. nötiges PID-Mapping, falls die mehrfach benutzt werden).


    Bei der Patch-Lösung würden einfach alle echten Devices mit "ja" auf den Kanal mit der neuen Source antworten, und je nachdem, welche Karte dann vom vdr ausgewählt wird (evtl. sollte es noch eine Gewichtung geben, je nach Platz in der Liste der alternativen Kanäle), sind die anderen weiterhin frei.


    Eine reine Plugin-Lösung würde mir auch gut gefallen, aber evtl. müsste man den vdr an ein paar kleinen Stellen passend erweitern, damit man das wirklich umsetzen kann.


    Weitere Idee:
    Der vdr bekommt nur die virtuellen devices des Plugins und das Plugin kümmert sich um die Steuerung der echten Devices, so dass diese gar nicht im direkten Zugriff des vdr liegen. Damit man aber die vorhandenen Klassen wie cDvbDevice nutzen kann, müsste man diese noch etwas erweitern, so dass sie sich nicht automatisch ins globale device-Array eintragen.
    Sowas in der Art hab ich mit dem dynamite-Patch ja auch gemacht. Der vdr sieht nur die dynamite-Devices, die abhängig davon, ob sie gerade empfangen können oder nicht, passend auf die Provides-Funktionen reagieren. dynamite ist da also eine Art Proxy zwischen dem vdr und der Hardware.


    Lars.

  • Für die Plugin-Lösung habe ich eine Frage bzw. einen Denkansatz:
    Wenn das Plugin auf die Devices zugreift und der VDR auf das Plugin über den virtuellen Kanal, wie soll dann das Device wissen, wie es den Kanal nun genau zu empfangen hat? Dann müsste man ja für den virtuellen Kanal alle Empfangsparameter aller Empfangswege angeben.


    Oder man müsste eine separate Senderliste mit allen Empfangswegen für die virtuellen Kanäle pflegen.


    Für die Patch-Lösung habe ich auch noch eine Idee:
    Statt virtueller Kanäle könnte man ja einen Zusätzlichen Parameter in der Kanalliste anlegen, welcher eine Art Redundanz-ID angibt.
    Dann würde man die für die Kanäle einfach durchnummerieren und wenn ein zusätzlicher Kanal in der Kanalliste nur ein zusätzlicher Empfangsweg ist, bekommt er die selbe Redundanz-ID wie der erste Kanal. VDR kann dann nach Reihenfolge der redundanten Kanäle in der channels.conf die Priorisierung vornehmen.


    Ich stelle mir das so vor:


    Das Erste DVB-S: ...:1
    ZDF DVB-S: ...:2
    Das Erste DVB-T: ...:1

  • Die originalen Kanäle bleiben weiterhin in der channels.conf und werden durch den vdr auch aktualisisert. Die virtuellen Kanäle sind quasi nur eine Liste mit den Channel-IDs der Original-Kanäle. Die entsprechenden Parameter können dann aus dem Original-Kanal gelesen werden, die müssen nicht im virtuellen Kanal gepflegt werden.


    Ein weiteres Feld in der channels.conf einzubauen, ist natürlich eine Lösungsmöglichkeit, allerdings ist sie dann nicht abwärtskompatibel. Das würde dann all die schönen Scripte betreffen, die im Umlauf sind und die diversen channels.conf automatisiert überarbeiten (alte Kanäle entfernen, sortieren usw.).


    Lars.

  • Also irgendwie so:


    Code
    1. Das Erste;X:S19.2E-1-1101-28106,I-1-28106-28106,T-8468-12290-32
    2. [...]
    3. Das Erste;ARD:11836:HC34M2S0:S19.2E:27500:101=2:102=deu@3,103=mis@3;106=deu@106:104;105=deu:0:28106:1:1101:0
    4. Das Erste;ARD:538000000:B8C23D12G4M16T8Y0:T:0:513=2:514=deu:516:0:32:8468:12290:0
    5. Das Erste;IPTV:140:S=1|P=0|F=UDP|U=239.35.10.4|A=10000:I:0:256=27:258=deu@3,263=mis@3;258=AC3@106:259;262=deu:1A:28106:1:28106:0
    6. [...]


    Christian

  • Fast, eher so:

    Code
    1. Das Erste:10000:S19.2E-1-1101-28106,I-1-28106-28106,T-8468-12290-32:X:(und hier noch irgendwas näher zu bestimmendes)
    2. [...]
    3. Das Erste;ARD:11836:HC34M2S0:S19.2E:27500:101=2:102=deu@3,103=mis@3;106=deu@106:104;105=deu:0:28106:1:1101:0
    4. Das Erste;ARD:538000000:B8C23D12G4M16T8Y0:T:0:513=2:514=deu:516:0:32:8468:12290:0
    5. Das Erste;IPTV:140:S=1|P=0|F=UDP|U=239.35.10.4|A=10000:I:0:256=27:258=deu@3,263=mis@3;258=AC3@106:259;262=deu:1A:28106:1:28106:0
    6. [...]


    Was da am besten nach der Source kommen muss, weiß ich noch nicht genau, muss ich erst mal probieren. Das sind ja z.B. die PIDs usw., die müssen nur eindeutig innerhalb der X-Kanäle sein. Vermutlich müssen die dann noch auf die echten PIDs gemappt werden, sonst weiß der vdr ja nicht, welche Pakete er aus dem TS ziehen soll. Ein einfaches Durchreichen der TS-Pakete wird wohl nicht reichen, es sei denn, der Kanal ändert spontan seine PIDs und kann es dem vdr mitteilen (dann wird es vermutlich einen Retune-Vorgang geben). Dazu kann ich erst was sagen, wenn ich damit mal rumgespielt habe.
    Die 10000 beim Transponder ist auch eine ziemlich beliebige Zahl.


    Lars.

  • Wie willst du beim Raussuchen des passenden Devices verhindern, dass du immer dein eigenes Device bekommst?
    cDevice::GetDevice kannst du ohne Patch nicht dazu bringen, ein bestimmtes zu ignorieren, oder?


    Deshalb dachte ich an eine neue Source, damit man dann nach einem Device für die echte Source suchen kann und damit das eigene Device auszuschließen.


    Lars.


    Neue source finde ich keine gute Idee.
    Besser ist es, ein Plugin zu bauen, welches per se für VDR als schlechteste Alternative erscheint (in device.c den größten Impact hat), so dass dieses Device auch wirklich als allerletzte Alternative benutzt wird.
    Dazu muss man dann nat. studieren welche Bedingungen gesetzt sind, devices mit CI/CAM werden z.B. bevorzugt frei gehalten.


    Dann würde VDR normal funktionieren und erst wenn alle andren devices für den 'originalen Kanal'/Masterkanal blockiert sind, würde VDR zum alternativen Kanal über das Plugin greifen.

  • Ich habe dieses Thema ja auch schon seit längerem im Hinterkopf, bin aber noch nicht dazu gekommen, mich näher damit zu beschäftigen.


    Meine Überlegungen gehen dahin, in einer separaten Datei (z.B. "alternates.conf") Zeilen der Form


    <channel-id>:<channel-id>:<channel-id>:...


    zu definieren. Jede Zeile gibt für einen bestimmten Kanal die alternativen Empfangswege an, wobei diese von links nach rechts verwendet werden, z.B. mit sinkender Qualität. Also etwa


    "Das Erste HD", "Das Erste" auf DVB-S, "Das Erste" auf DVB-T


    (natürlich die channel-ids, ich hab jetzt hier auf die Schnelle nur die Namen reingeschrieben).


    Wenn auf einen Kanal geschaltet werden soll und dieser nicht verfügbar ist, dann wird in dieser Datei geschaut, ob es eine Zeile mit dieser channel-id gibt, und ggf. einer der anderen probiert. Dabei könnte (nach noch zu definierenden Kriterien) ein "besserer" (weiter links) oder "schlechterer" (weiter rechts) Kanal bevorzugt werden. Ist keiner der alternativen Kanäle verfügbar, dann ist der Kanal endgültig nicht verfügbar.


    Wie man das Ganze zum Benutzer hin präsentiert und im laufenden Betrieb konfigurierbar macht, ist dann ein nachrangiges Problem. erstmal müsste die Kernfunktionalität da sein.


    Soweit nur mal kurz meine Vorstellungen...


    Klaus

  • Bei Timer mache ich mir da keine Sorgen. Wenn eine Aufnahme gestartet werden soll, sucht der vdr halt einen passenden Kanal raus und ggf. wird der Timer von einen Kanal auf einen andere verschoben und kann dann ganz normal weiterarbeiten.


    Spannend wird das beim Zappen. Wenn man z.B. "Das Erste HD" nicht empfangen kann und man dann auf "Das Erste SD" landet, ist man in seiner Kanalliste ja an einen anderen Punkt gesprungen. Evtl. muss man doch langsam darüber nachdenken, zum einen die channels.conf zu haben, wo alle Kanäle mit ihren Tuning-Daten drin sind, und zum anderen eine Liste mit Kanälen, die für das Live-TV benutzt wird. Da könnte man dann gleich von vornherein eine Liste von Channel-IDs hinterlegen.


    Nur mal so meine spontanen Gedanken dazu.


    Lars.

  • Moin,


    spannendes Thema ;)


    Evtl. muss man doch langsam darüber nachdenken, zum einen die channels.conf zu haben, wo alle Kanäle mit ihren Tuning-Daten drin sind, und zum anderen eine Liste mit Kanälen, die für das Live-TV benutzt wird. Da könnte man dann gleich von vornherein eine Liste von Channel-IDs hinterlegen.


    In der Liste der Kanäle zum Zappen wäre es doch dann aber sinnvoll, nur die "virtuellen Kanäle" drinn zu haben...normalerweise will ich doch nicht auf z.B. ARD HD schalten, sondern nur auf ARD. Ob dann ARD HD in 720p per SAT, ARD HD in 1080p per DVB-T2 oder ARD SD von sonstwo angezeigt wird, sollte dann automatisch passieren, in der Reihenfolge wie es der Nutzer konfiguriert hat. Die Kanalliste zum zappen würde dann also nur die Sender an sich in der gewünschten Reihenfolge beinhalten.


    Den Mechanismus könnte man z.B. dann auch anwenden, wenn aus irgendwelchen Gründen z.B. Pro7HD nicht verfügbar ist, wohl aber Pro7 SD...


    Ciao Louis

  • In der Liste der Kanäle zum Zappen wäre es doch dann aber sinnvoll, nur die "virtuellen Kanäle" drinn zu haben...normalerweise will ich doch nicht auf z.B. ARD HD schalten, sondern nur auf ARD.


    Ja, so dachte ich das. Auch wenn der "virtuelle" Kanal nur eine Alternative hat.
    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...).


    Lars.