[ANNOUNCE] VDR developer version 1.5.14

Zitat

... reinpatchen und sonstige User laufen Gefahr, dass sie ein 3mon altes MultiProto mit evtl. Problemen/Bugs, die in dieser Zeit gelöst wurden, verwenden (Kabel-User triffts zB doppelt - ok nix wirklich neues Augenzwinkern )....

Auf meinen Testrechner läuft der Treiber aus dem Link von Klaus ( http://www.linuxtv.org/piperma…/2008-January/015327.html ) mit dvb-c von unitymedia

Hallo,

wenn ich gewusst hätte was hier der Multiproto Treiber auslöst, hätte ich Manu schon er ein Signal gegeben um den aktuellen Stand anzupassen.

Wer es noch nicht mitbekommen hat, der Treiber hat jetzt den Stand von gestern aus dem V4L-DVB HG. Manu hat sich letzte Nacht noch hingesetzt und die Anpassungen übernommen.

bis dann LordZodiac

Hallo Klaus,

Zitat

Original von kls
Da ich nunmal kein Kabel habe, brauche ich halt zum Einbau und Testen von H.264 eine DVB-S2 Empfangsmöglichkeit.

... à propos: Aus anderen Threads weiß ich, dass du sehr wohl verschlüsselte Sender nutzt. Aber nutzt du eigentlich auch eine Client-Server-Struktur? Ich habe vor ein paar Versionen mal einen Blick in den Devel-Zweig gewagt. Ergebnis: Das neue CAM-Handling ist für meine Zwecke leider nicht brauchbar (so es sich nicht in der Zwischenzeit geändert hat). Ich gehe mit dem Posten dieses Problems jetzt schon ein Weilchen schwanger, weil es leider sehr schnell in die "Grauzone" abdriften kann, jetzt poste ich es aber dennoch:

Folgendes Szenario:
Ich bin Kabelnutzer und Inhaber eines KD-Home und Premiere-Abos. Der Empfang und die Entschlüsselung der verschlüsselten Sender findet am Server statt. Dieser gibt diese Sender mittels Streamdev-Server an einen Client weiter. Auf dem Client ist dank der neuerdings funktionierenden Option "Streaming Filter" das Aktualiseren von Kanalnamen und PIDs aktiv. Die "channels.conf" ist auf Server und Client identisch. Unter VDR 1.4.x sind die betr. Sender für den Client FTA (da der Server sie ja entschlüsselt). Unter 1.5.x sind sie nun aber verschlüsselt. Man kann dies zwar am Client zu FTA ändern, schaltet man aber weg von diesem Kanal und wieder hin, so wird er aktualisiert und ist somit wieder verschlüsselt. Wie gesagt: In dieser Form für mich ein echter Showstopper für die Version 1.5/1.6.

Ist dieses Verhalten bekannt/gewollt? Liegt's am VDR oder am Streamdev-Plugin?

Gruß,
Holger

... jetzt fehlen nur noch die Verbesserungen für die FFs aus dem refactoring Treiber und wir wären wohl fast alle glücklich?!!

Gruß, ollo

Zitat

Original von LordZodiac
Hallo,

wenn ich gewusst hätte was hier der Multiproto Treiber auslöst, hätte ich Manu schon er ein Signal gegeben um den aktuellen Stand anzupassen.

Wer es noch nicht mitbekommen hat, der Treiber hat jetzt den Stand von gestern aus dem V4L-DVB HG. Manu hat sich letzte Nacht noch hingesetzt und die Anpassungen übernommen.

bis dann LordZodiac

Alles anzeigen

Hi,

super vielen Dank! Ich habe das Wiki aktualisiert falls jemdand Probleme mit der Treiberinstallation haben sollte wie immer hier:

http://www.vdr-wiki.de/wiki/in…B-S2_-_Teil2:_DVB_Treiber
http://www.vdr-wiki.de/wiki/in…eitung_%28Achtung_Beta%29

Zitat

... jetzt fehlen nur noch die Verbesserungen für die FFs aus dem refactoring Treiber und wir wären wohl fast alle glücklich?!!

Schon mal mit einfachem Reinkopieren der .c- und .h-Files versucht? Zumindest im alten multiproto-Stand ging das bislang problemlos, da sich aus Sicht eines DVB-S-only-Treibers kaum etwas geändert hat.

Grüße,
Holger

Was bedeutet denn "multiproto" für DVB-T Nutzer?
Irgendwie findet Google mir keine schöne Erläuterung, was genau multiproto und die Motivation dahinter ist.

Danke für die neue Version, Klaus!

Die multiproto Treiber sind dafür ausgelegt eine größere "Menge" an Modulationen verarbeiten zu können.

d.h. auch zukünftige Standards unterstüzen zu können, wie DVB-T2, DVB-H, DMB, ...

In der ML gabs eine schöne Erklärung, warum neue Treiber notwendig sind: http://www.linuxtv.org/piperma…/2008-January/015353.html

Zitat

Originally posted by HolgerR
Hallo Klaus,

... à propos: Aus anderen Threads weiß ich, dass du sehr wohl verschlüsselte Sender nutzt.

Aber nur mit CAM und offiziellem Abo.

Zitat

Aber nutzt du eigentlich auch eine Client-Server-Struktur?

Nein.

Zitat

Ich habe vor ein paar Versionen mal einen Blick in den Devel-Zweig gewagt. Ergebnis: Das neue CAM-Handling ist für meine Zwecke leider nicht brauchbar (so es sich nicht in der Zwischenzeit geändert hat). Ich gehe mit dem Posten dieses Problems jetzt schon ein Weilchen schwanger, weil es leider sehr schnell in die "Grauzone" abdriften kann, jetzt poste ich es aber dennoch:

Folgendes Szenario:
Ich bin Kabelnutzer und Inhaber eines KD-Home und Premiere-Abos. Der Empfang und die Entschlüsselung der verschlüsselten Sender findet am Server statt. Dieser gibt diese Sender mittels Streamdev-Server an einen Client weiter. Auf dem Client ist dank der neuerdings funktionierenden Option "Streaming Filter" das Aktualiseren von Kanalnamen und PIDs aktiv. Die "channels.conf" ist auf Server und Client identisch. Unter VDR 1.4.x sind die betr. Sender für den Client FTA (da der Server sie ja entschlüsselt). Unter 1.5.x sind sie nun aber verschlüsselt. Man kann dies zwar am Client zu FTA ändern, schaltet man aber weg von diesem Kanal und wieder hin, so wird er aktualisiert und ist somit wieder verschlüsselt. Wie gesagt: In dieser Form für mich ein echter Showstopper für die Version 1.5/1.6.

Ist dieses Verhalten bekannt/gewollt? Liegt's am VDR oder am Streamdev-Plugin?

Wenn ein verschlüsselter Sender für den Client als FTA gelten soll, dann würde ich mal sagen, daß es Sache des Streamdev-Plugins wäre, das entsprechend handzuhaben.

Klaus

Zitat

Originally posted by zulu
Urig,
hat dein Patch irgendwelche negativen Nebenwirkungen, wenn der VDR dann doch mit den Multiproto Treibern läuft?

Beim derzeitigen Patch entscheidet es sich zur Compile-Time: Sind die Header für Multiproto verfügbar, wird auf Multiproto übersetzt, und der VDR läuft nur mit Multiproto-Treibern. Sind keine vorhanden, wird für die alten Treiber übersetzt, und der VDR kann nur das - und damit kein DVB-S2. Da die Multiproto-Treiber aber rückwärtskompatibel sind, funktioniert immerhin DVB-S/C/T.

Ich werde den Patch nochmal überarbeiten, und einen richtigen wrapper bauen. Damit könnte man theoretisch später sogar eine Runtime-Abfrage oder Kommandozeilenoption machen, mit dem von Multiproto auf alte Treiber umgeschaltet wird. Nur ganz ohne Multiproto-Header gibt es natürlich nur die alten Treiber.

Insgesamt spricht daher eigentlich nichts dagegen, das neue Treiber-API - mit ein paar Hooks für die Wrapper - als neues DVB-API einzusetzen.

Gruß,

Udo

hsteinhaus

Zitat

Schon mal mit einfachem Reinkopieren der .c- und .h-Files versucht? Zumindest im alten multiproto-Stand ging das bislang problemlos, da sich aus Sicht eines DVB-S-only-Treibers kaum etwas geändert hat.

... schon klar, aber um welche files handelt es sich genau?

Danke & Gruß, ollo

Hallo Udo,

danke für die Erklärung.

Zitat

Ich werde den Patch nochmal überarbeiten, und einen richtigen wrapper bauen. Damit könnte man theoretisch später sogar eine Runtime-Abfrage oder Kommandozeilenoption machen, mit dem von Multiproto auf alte Treiber umgeschaltet wird. Nur ganz ohne Multiproto-Header gibt es natürlich nur die alten Treiber.

Klasse!

Gruß
Marc

Hallo

Da ich auf dem System die 1.4.7 Parallel habe . Bekomme ich bei der vorstellung der DVB-S Kernel module zu machen für die 1.5.14 kalte Fusse..

Das linken und starten der 1.5.14 geht soweit mit den Infos aus dem Wiki. Nur ich habe keine Fernsehbild mehr, Kanal nicht gefunden. Ansonst Aufnahmen kann ich mir ansehen.

Ich möschte die Entwicklung mit verfolgen. Aber die Kiste sollte weiter laufen können??

Ein Paar tips ..

Gruss Patrice

Hallo Klaus,

bei einigen Plugins ist der MAINMENUENTRY in $PLUGIN.h definiert. Da wird er aber von i18n-to-gettext.pl nicht gefunden.

So klappt's dann bei mir:

--- i18n-to-gettext.pl~	2008-01-08 22:54:01.000000000 +0100
+++ i18n-to-gettext.pl	2008-01-29 11:35:14.000000000 +0100
@@ -248,7 +248,7 @@ close(F);
 
 (mkdir($PODIR) || die "$PODIR: $!\n") unless -d $PODIR;
 
-system("$XGETTEXT -o $POTFILE *.c");
+system("$XGETTEXT -o $POTFILE `ls *.c *.h`");
 
 # Generate .po files for all languages:

Gruß
Marc

EDIT:
Zu meiner Schande musste ich jetzt bei meinem eigenen Plugin feststellen, das das mit

system("$XGETTEXT -o $POTFILE *.c $PLUGIN.h");

voll in die Hose geht falls keine $PLUGIN.h existiert.
Damit:

system("$XGETTEXT -o $POTFILE `ls *.c *.h`");

gibt es zwar einen Fehler von ls wenn kein *.h existiert, aber gettext bricht nicht mehr ab.

ollo

hg hat nach einem schnellen Merge folgendes ausgespuckt (ohne Gewähr):

linux/drivers/media/dvb/ttpci/av7110.c
linux/drivers/media/dvb/ttpci/av7110.h
linux/drivers/media/dvb/ttpci/av7110_av.c
linux/drivers/media/dvb/ttpci/av7110_hw.c
inux/drivers/media/dvb/ttpci/av7110_hw.h

@Patrice: mit welcher Karte?

Grüße,
Holger

Hi ,

Nexus-S und Twinhan

Zitat

Original von kls

Wenn ein verschlüsselter Sender für den Client als FTA gelten soll, dann würde ich mal sagen, daß es Sache des Streamdev-Plugins wäre, das entsprechend handzuhaben.

Um dem Client FTA vorzugaukeln, müsste der Server vermutlich aus der PMT die CA-Deskriptoren herausfiltern, richtig? Oder gäbe es geschicktere Lösungen?

Als momentaner Workaround sollte es genügen, wenn im CA-Feld der channels.conf bei den verschlüsselten Kanälen der CardIndex vom streamdev-client eingetragen wird. Bei VDR 1.5.x sollte das die 9 sein, sofern streamdev als erstes Plugin geladen wird.

Zitat

Originally posted by schmirl
Um dem Client FTA vorzugaukeln, müsste der Server vermutlich aus der PMT die CA-Deskriptoren herausfiltern, richtig? Oder gäbe es geschicktere Lösungen?

Was sollte denn der Client mit den CA-Deskriptoren anfangen?

Zitat

Als momentaner Workaround sollte es genügen, wenn im CA-Feld der channels.conf bei den verschlüsselten Kanälen der CardIndex vom streamdev-client eingetragen wird. Bei VDR 1.5.x sollte das die 9 sein, sofern streamdev als erstes Plugin geladen wird.

Würde ich auch sagen.

Klaus

Zitat

Als momentaner Workaround sollte es genügen, wenn im CA-Feld der channels.conf bei den verschlüsselten Kanälen der CardIndex vom streamdev-client eingetragen wird. Bei VDR 1.5.x sollte das die 9 sein, sofern streamdev als erstes Plugin geladen wird.

und da gibt es den passenden Befehl dazu: sed Frage channels.conf Mich verblüfft ja...