Linux DVBServer - (alle Jahre wieder?)

[Sarwane]

Hallo!

 

Ist zwar kein Plugin, stellt aber zumindest eine Art Erweiterung dar - ist hoffentlich also nicht völlig Off-Topic.

 

Nachdem ich dazu im Forum zwar einige Ansätze gefunden habe, aber keine aktuellen Posts oder Entwicklungen, möchte ich das Thema noch einmal aufgreifen:

 

DVBServer-Funktionalität für Linux. Folgende Punkte haben mich (u.A.) dazu veranlasst:

• Ich sehe das Konstrukt DVBServer/Unicast hier hauptsächlich als universelle, sehr gut skalierbare Schnittstelle für DVB-Hardware.
  Nicht unterstütze Geräte, wie z.B. meine (seit DVBViewer) brachliegende Pinnacle PCTV Sat und eine alte Nexus, könnten so wieder als zusätzliche Empfänger eingesetzt werden.
  
• Neuere Boards geizen auch sehr häufig mit PCI-Steckplätzen. Abgesehen von irgendwelchen IRQ-Problemen und thermischen, platz- hitze- und stromversorgungstechnischen Schwierigkeiten innerhalb eines möglichst wohnzimmertauglichen HTPCs eröffnet sich so die Möglichkeit zu praktischen und verhältnismäßig einfachen Erweiterungen.
  
• Nicht nur wegen der gesparten Windows-Lizenz, sondern auch wegen der Stabilität und konstanten Performance bei solchen "Datenschaufelaufgaben" finde ich einen Ansatz auf Linux-Ebene dafür optimal.
  

Folgende mögliche Varianten hätte ich mir da vorgestellt:

- "Bastellösung" (eine Instanz pro Karte, als einfache Erweiterung bzw. um Erfahrungswerte über die Praxistauglichkeit zu sammeln)

- "echter" DVBServer mit intelligenter Hardwareverwaltung (ähnlich dem "Original") oder

- Einbindung in VDR mit allen Vor- und Nachteilen (muss sich erst zeigen was einfacher/sinnvoller/zuverlässiger funktioniert)

 

Da das nur eine erste Idee ist, würde ich jetzt gerne wissen, ob etwas völlig dagegen spricht oder ob Interesse daran besteht dass ich mich näher mit dem Thema auseinandersetze bzw. ob mich die Entwickler dabei unterstüzen würden? Schließlich müsste ich dazu einige Hintergründe über die Kommunikation und den Ablauf zwischen DVBServer und Network Device wissen - wenn's geht ohne Reverse-Engineering mit dem Sniffer!

 

Beste Grüße,

Gerald

[Derrick]

..zumindest die nexus kannste knicken. Die liefert keinen TS. Aber auch was den rest betrifft, bist du hier glaub ich nicht ganz an der richtigen adresse.. ..das client/server-konzept funktioniert doch bereits ausgezeichnet .. unter windows

[Lars_MQ]

Grundlegend steht gegen eine portierung: Der Server basiert komplett auf dem Windows treiber model (BDA und Co). Eine portierung ist damit unmöglich, nur ein neuschreiben auf basis der linux api wäre möglich.

 

Gegen VDR: PES <-> TS. Der DVBServer leitet einfach die empfangen Daten so weiter, der VDR nutzt PES (? bezeichnung bin ich nicht sicher) historisch bedingt, da die ff karten den TS stream hardware mässig kastrieren (sprich die wichtigsten infos wegschneiden), deswegen unterstützt der viewer auch keine FF karten (Nexus und co).

 

 

Das Protokoll des servers: simpelst. Textbasiert, zeilenbasiert und vollkommen unzureichend für spätere entwicklung

 

 

Grösstes Problem: beide entwickler haben mit der Zeit eine echte allergie gegen fummel linux entwickelt.

 

Sei es Christian, weil er sich mit dem webserver DVBViewer.com rumärgern muss, oder sei es meine wenigkeit, der beim (neu)aufsetzen seines vdr systems regelmässig die krätze kriegte, weil kompilierfehler durch versionkonflikte, eine absolut konfuse systemstruktur und crashs schneller und spektakulärer als bei jedem windows an der tagesordnung waren. (Was meinst Du, warum ich zum DVBViewer gewechselt bin ).

 

Wenn jemand mit etwas ahnung von computern damit schon probleme hat, was hat dann der unbedarfte DVBViewer nutzer für probleme? Ich sehe da einen supportbedarf auf uns zurollen, der uns definitiv erschlägt und absolut überfordert...

 

 

Zusammengefasst: Wir (entwickler) unterstützen jeden, der sowas entwickeln will, mit rat, aber nicht mit tat (linuxseitig) und wir (das ganze team) können dazu auch keinen direkten user support leisten. a. weil keine ahnung und b. weil alles freiwillige und denen kann man nichts aufzwingen

[Sarwane]

Danke einmal für die Rückmeldungen. Genau das war der Sinn der Sache - einmal abschätzen zu können was dabei auf mich zukommt. Hatte mich noch nicht ernsthaft damit beschäftigt, daher hatte ich beispielsweise auch keine Ahnung davon dass die FF-Karten das anders handhaben. Ich wäre von einem kleinsten gemeinsamen Nenner=TS ausgegangen.

 

Eine reine Portierung kam für mich sowieso nicht in Frage. Nicht nur dass ich es nicht besonders leiden kann fremde Konzepte und Gedanken zu 100% nachvollziehen zu müssen (=Sources), auch die unterschiedlichen Umgebungsbedingungen (wie Lars auch aufgezeigt hat) sprechen für mich dagegen.

 

Werde mich mal damit praktisch auseinandersetzen - dann sehe ich wohl eher ob ich das Ganze unter dem Motto "Danke, hat mich sehr gefreut" doch lieber sein lasse oder ob dabei Aussicht auf Erfolg besteht.

 

Auch das mit dem Support ist wirklich ein Thema für sich. Mehr als die Bereitstellung als "added value" Erweiterung "as is" für DVB-Geeks macht natürlich für euch überhaupt keinen Sinn...

 

Hab zwar genug anderes zu tun, aber die Idee beschäftigt mich momentan einfach zu sehr. Mal sehen was ich zusammenbringe und ob ich vielleicht noch mit ein oder zwei Fragen auf euch zurückkomme!

[Sarwane]

Damit es gleich spannend wird, habe ich heute mal begonnen mit meiner Nexus (eigentlich eine Uralt-TT-1.3) zu experimentieren...

 

Mal vorweg: Bitte schlagt mich nicht gleich, wenn ich vielleicht in euren Augen dämliche Fragen stelle, ich habe gerade erst begonnen mich (gezwungenermaßen) mit DVB-Grundlagen zu beschäftigen..

 

Eigentlich ging das einfacher als ich erwartet hätte. Aber die Erfahrung lehrt - der Teufel steckt immer im Detail!

 

Gegen VDR: PES <-> TS. Der DVBServer leitet einfach die empfangen Daten so weiter, der VDR nutzt PES (? bezeichnung bin ich nicht sicher) historisch bedingt, da die ff karten den TS stream hardware mässig kastrieren (sprich die wichtigsten infos wegschneiden), deswegen unterstützt der viewer auch keine FF karten (Nexus und co).

Welche (wichtigen?) Informationen fehlen denn im Stream solch einer FF-Karte?

Naiv gesagt: Auch mit diesen Karten hat man doch mit der dazugehörigen Software eigentlich alle Möglichkeiten. Ich bin bisher nur auf eine Limitierung (max. 8 PIDs - scheinbar durch Hardware gefiltert) gestoßen. Also kann ich damit nicht einen kompletten Transponder "dumpen" oder die PIDs per Software filtern - aber das sollte ja zumindest noch für die Aufnahme von 1-2 Kanälen (nur AV) innerhalb eines Transponders reichen, wenn man Teletext und solche Sachen weglässt, oder? Andere Variante: 1 Kanal mit allem Drum&Dran sollte sich doch ausgehen.

 

Was ich bisher gemacht habe (Beispiel):

 

- Tune auf 12544, 18V (H), Symbolrate 22000

- erzeuge TS mit folgendem Inhalt:

PID 0 =PAT?

PID 0x61 =PMT? für Programm 17501 (=ProSieben)

PID 0x1ff Video

PID 0x200 (MPEG2) Audio

- Das Ganze in eine Datei geschrieben und mit dem DVB File Device in den DVBViewer gefüttert - Netzwerkstream hab ich noch nicht hinbekommen, ich vermute, dass das Network Device nichts macht, wenn es nicht mit dem DVBServer kommunizieren (Steuerung) kann?

 

Ergebnis: ...und schon kann man Pro7 sehen. Sogar Scannen kann man, die gefundene Provider- und Kanalbezeichnung stimmt aber nicht, offenbar fehlt da noch ein PID mit den Infos oder so?

 

Ohne der Limitierung (also wenn Budget-Karte) kann man jedenfalls den kompletten TS nutzen. Sollte dann so wie "Öffne ganzen Transponder" funktionieren - der DVBViewer kann demnach auch selber filtern?

Ob man hier mit der vorhandenen DVB-API in Software dann mehr als 8 PIDs gezielt filtern kann, muss ich noch herausfinden.

 

Mein Fazit: Sieht gar nicht so schlecht aus für ein paar Stunden Neugier.

Das war so interessant, dass ich ganz aufs Essen vergessen habe. Jetzt muss ich mich in nächster Zeit aber wieder um "wichtige" Dinge kümmern, mal sehen wann ich (diesmal mit der PCTV Sat) weitere Versuche unternehmen kann...