Beiträge von Nano

Zitat

Original von real_schorsch
Den Stand muss ich mal erfragen. Ich seh/entwickle immer nur die Prototypen, was dann bzgl. Fertigung läuft, bekomme ich (solange keine Probleme auftreten) nicht mit. Erst, wenn die ersten "richtigen" Geräte aus der Fertigung fallen, habe ich wieder was zum Spielen

Hast Du den Stand schon erfragt?

Tach,

Schorsch, kannst Du schon etwas zum Netceiver-Gehäuse von RMM sagen? Kommt das noch im April oder doch erst im Mai?

Grüße
Nano

Zitat

Original von Mreimer
Open Source wäre auf jedem Fall ein guter Schritt. Ist immer besser als einem Linux-Freak ein paar Binaries vorzuwerfen.

Da bei mir ausreichend Sat-Kabel liegt ist es für mich im Moment ohnehin irrelevant, aber ein Bekannter will an zentraler Stelle den NetCeiver haben und so das gesamte Haus-Lan zum Verteilen nutzen.

Was hat es denn mit dem diseqc.conf-Problem auf sich? Hat das sonst noch jemand?

Falls das relevant ist: Ausgabedevice ist eine FF-Karte. Diese wird als erster Tuner erkannt. Die zwei Tuner auf dem Netceiver hat der VDR als Tuner 2 und 3 gelistet. Das Bild war aber auf den zwei Netceiver-Tunern jeweils schwarz. Das liegt laut einem anderen Thread eben an dem diseqc.conf-Problem. Ohne die diseqc.conf, die der mcli generiert, ist wohl das Bild generell schwarz. Mein VDR frisst die Datei aber nicht.

Alles anzeigen

Kam heute auf der Mailing-Liste von Schorsch zum Thema Funktionsweise:

Zitat

Zitat von Schorsch aus der ML
It is a proprietory protocol in the sense as it is no standard. When there
are so many IPTV standards to choose from, why make not a new one? At
the time we started, DVB-IPTV was not even named and still I think it is so
bloated that it cannot be efficiently used to use cheap hardware as a
server.

However, our protocol uses standard protocols like MLDv2 just with a
different interpretation to make it light-weight and use hardware supported
streaming. In the end, one NetCeiver can stream up to 6 full S2-transponders
(~40MByte/s), only the zapping time increases a bit... Do that with a PC :p

The protocol translates (almost) all DVB specifics to ethernet, so it was no
problem to wrap it back to DVB-API. The multicast address is not static but
contains all relevant reception parameters. The basic communication only
exchanges a few MLDv2-messages (no XML), so it can be processed very fast
and also gains from MLDv2-aware switches. Only tuner capabilities and tuning
states (SNR, lock, ...) are transmitted regularly in a side band via XML on
a specific multicast address. That also allows zero configuration for the
client. We will write a "white paper" about the protocol, currently we just
don't have enough time...

For the client side, the sources will be published as GPL. Currently we use a closed source daemon with a dvb loopback driver in the kernel, but that makes it hard to fully use the tuner virtualization and costs some overhead for small CPUs. Since we already have a native vdr plugin for that, the network code will be then forced to be GPL anyway

Alles anzeigen

Bei dem diseqc.conf Problem kann ich Dir leider gerade nicht helfen, da ich in speziell dieser Thematik nicht so tief drin stecke, sorry!

Zitat

Original von Mreimer
Mal ganz allgemein, da ich die Netceiver-Geschichte nicht für mich, sondern für einen Bekannten zum Laufen bekommen will: Wie genau muss man sich das Ding denn vorstellen? Wie einen "Tuner-Server" bei dem sich jeder VDR seine Anzahl von Tunern abholen kann? Wäre man da mit einem VDR-Server nicht besser bedient? Zumal man dann keinen Closed-Source-Brocken bräuchte. Alleine das wäre für mich Ausschlusskriterium. Was macht denn der mcli so "geheimes"? Wohl irgendein IP-Protokoll sprechen, aber bisher habe ich noch keine Zeit/Lust gehabt, da mal mit einem Sniffer zu lauschen.

So wie ich den Schorsch verstanden habe, soll da demnächst mal etwas in Richtung Open-Source VDR-Plugin statt des mcli kommen. Bitte korrigiert mich, wenn ich da was falsches schreibe.

Der mcli ist der IPv6 Multicast (Empfangs-)Client. Dieser sagt dem Netceiver eigentlich nur, welche Programme mit welchen PIDs denn gerade so erwünscht sind per Multicast. Der Netceiver wertet alle Anfragen aller mcli aus und baut dann die entsprechenden Mutlicasts zusammen. Es soll also möglichst unabhängig von Tunern sein, also eben _nicht_ ein Tuner pro Client.

Tach...

Mir hat sich nach der letzten c't (Thema CI Plus) die Frage gestellt, wie "zukunftssicher" der Netceiver eigentlich ist.

Ich befürchte, dass es in Zukunft immer mehr Grundverschlüsselung bzw. PayTV geben wird. Man hat ja heutzutage schon arge Schwierigkeiten überhaupt Premiere gucken zu können, selbst mit Abo. Von Legalität mal ganz abgesehen.

Wenn ich dann noch etwas von CI-Plus und erneuter Verschlüsselung bis zum Decoder-Chip lese, dann wird mir ganz übel.
Wie will man sowas mit dem Netceiver realisieren? Verschlüsselte Multicasts?

Schorsch? Habt Ihr da schon etwas in Planung? Würde eine breite Akzeptanz von CI Plus (oder Ähnlichem) seitens der Provider (wie Premiere) die AVG oder den Netceiver ins Aus befördern?

Danke und Gruß
Nano

Zitat

Original von real_schorsch
So grob Ende April müsste auch der NetCeiver im Metallgehäuse mit externem Netzteil zu haben sein, d.h. ohne weiteres Basteln. Es ist zwar aus verschiedenen Gründen noch nicht die kompakte Bauform mit anderer Platine geworden, die wir eigentlich vorhatten, d.h. das Ding wird halt seine 28cm lang (Codename Baguette...) . Aber am Dach bzw. im Keller ist das ja ohnehin egal.

Hi,
weißt Du zufällig, ob das Gehäuse+Netzteil auch separat zu bestellen sein wird? Ist mit Sicherheit für die Leute mit der nackte langen Platine sehr interessant, die es mit der Gehäusebearbeitung nicht so haben.

Hi kris,

vielen Dank für das Wiki.
Wenn keine Einwände bestehen, passe ich den ersten Beitrag dieses Threads an und verlinke auf das Wiki. Würde dann alle Infos aus dem ersten Beitrag löschen.

Ok?

Gruß
Nano

Zitat

Original von kris
HI,

ich hab mal angefangen das Wiki zu pflegen. Nach und nach ergänze ich die FAQs.

Vielen Dank an Real_Schorsch der das ganze "quergelesen" hat und an allen "beteiligten"...

MFG
Kris

Alles anzeigen

Tach!

Kurze Info, falls nicht alle Thread-Leser die News von RMM bekommen.

Der Netclient soll wohl ab dem 29.5.2009 ausgeliefert werden und kann nun bestellt werden.

300 Tacken.

Gruß
Nano

Zitat

Original von pbriesch
Wie teuer war die Reparatur?

Zwei Monate vor Ende der Gewährleistung. Glück gehabt.

Tach!

Für das Archiv: Beamer funktioniert inzwischen wieder. Er war zur Reparatur im Panasonic Servce Center.

Es war tatsächlich dieses allgemein bekannte Problem bei diesem Beamer: kaputte Mechanik an der Optik. Entweder verklebt (durch festgebackenes Schmiermittel) oder verklemmt. Jedenfalls klappterte etwas lose im Gehäuse.

Zitat

Original von vdr-box
hallo, habe mal eine zwischenfrage, die dvb-s twinkarte welche im netceiver
steckt, läuft diese nur in dem netceiver oder kann ich die auch in einen
hp server mit pci-x reinstecken.

über eine antwort würde ich mich sehr freuen.

gruss und dank vdr-box

Hallo vdr-box,
die läuft definitiv nur im Netceiver!!!
Die Karte mag zwar so aussehen wie eine "normale" PCI, PCIe oder PCI-X Steckkarte, hat aber ein völlig anderes (eigenes) Interface, das nichts mit den bekannten gerade genannten PC-Schnittstellen zu tun hat.

Du würdest Dir vermutlich alles zerschießen!

Zitat

Original von Razorblade
Gehe ich recht in der Annahme, daß man dank S2API-Integration jetzt auch keinen patch mehr für vdr braucht?
Ist das channels.conf noch irgendwie unterschiedlich oder kann ich meine bishere channels.conf aus 1.7.x weiterbenutzen?

Irgendwie mag der Netceiver im Moment noch nicht so ganz, bekomme
nirgendwo einen Lock...

Also ich habe hier den vdr-1.7.3 ohne Patch mit gepatchtem streamdev-Plugin (disable-pes-patch) laufen. Läuft jetzt seit Stunden.

Hier meine channels.conf:

:->HDTV Deutsch
ANIXE HD;BetaDigital:11914:hC910M2O35S1:S19.2E:27500:1535=27:0;1539=deu:0:0:132:133:6:0
arte HD;ZDFvision:11362:hC23M5O35S1:S19.2E:22000:6210=27:6221=deu,6222=fra:6230:0:11120:1:1011:0
ASTRA HD+;BetaDigital:11914:hC910M2O35S1:S19.2E:27500:1279=27:0;1283=deu:0:0:131:133:6:0
:->HDTV teilweise ausser betrieb bis 2010
EinsFestival HD;ARD:12422:hC34M2O0S0:S19.2E:27500:1601=27:1602=deu;1606=deu:0:0:28396:1:1201:0
:Free
RTL Television,RTL;RTL World:12187:hC34M2O0S0:S19.2E:27500:163=2:104=deu;106=deu:105:0:12003:1:1089:0
SAT.1;ProSiebenSat.1:12544:hC56M5O0S0:S19.2E:22000:255=2:256=deu;259=deu:32:0:17500:1:1107:0
ProSieben;ProSiebenSat.1:12544:hC56M5O0S0:S19.2E:22000:511=2:512=deu;515=deu:33:0:17501:1:1107:0
RTL2;RTL World:12187:hC34M2O0S0:S19.2E:27500:166=2:128=deu:68:0:12020:1:1089:0
Das Erste;ARD:11836:hC34M5O0S0:S19.2E:27500:101=2:102=deu,103=2ch;106=dd:104:0:28106:1:1101:0
Bayerisches FS Süd;ARD:11836:hC34M5O0S0:S19.2E:27500:201=2:202=deu,203=2ch;206=dd:204:0:28107:1:1101:0
hr-fernsehen;ARD:11836:hC34M5O0S0:S19.2E:27500:301=2:302=deu,303=2ch:304:0:28108:1:1101:0
NDR FS MV;ARD:12109:hC34M5O0S0:S19.2E:27500:2601=2:2602=deu,2603=2ch:2604:0:28224:1:1073:0

Zitat

Original von cyberjunk
Hallo Leute,

wollte nur DANKE@Nano sagen !!!!

der dvbloop-s2api-0.2 patch funktioniert hier mit dem s2-liplianin & 2.6.28

saubere Arbeit

grüße

Alles anzeigen

Danke auch an die Rasierklinge!

Zitat

Original von Razorblade
Supi, das mit dem Versionscheck wollte ich auch einbauen wenn ich weiß ob es läuft. Ich hatte mit vi global die "class_" keywords rausgeworfen, d.h. auch im compatibility code für < 2.6.13, da muß es natürlich auch wieder rein...

Dann noch eine kurze Frage zum Netzteil, ich will mir jetzt einen Adapter von ATX auf auf den Netceiver-Stecker basteln, wie geht man am besten mit dem ATX-Power-On um? Kann ich das grüne Kabel (PIN16) einfach an einen normalen Schalter klemmen und auf der anderen Seite Masse? Wenn ja einen Kippschalter oder einen Impulsschalter (wie zB Reset)?

Den Versionscheck habe ich vorhin eingebaut.

Kippschalter ist angesagt. Ich habe die Leitung hier auf Masse geklemmt.

So. Hier der Patch. Ich war mal so frei und habe eine Version 0.2 hinten angehängt.

Es wurden nur Anpassungen gemacht, so dass es sich auch auf einem Kernel <2.6.28 kompilieren lässt:
1) include für semaphore.h angepasst
2) alle Einträge mit device bzw. class_device angepasst.

Zitat

Original von Razorblade
Und funktioniert es? Kann es selber mangels laufendem Netceiver (noch) nicht testen...

Ja, es klappt. Ich habe die aktuellen v4l-dvb Quellen genommen. Patch klappte ohne Probleme.

Ich habe den Patch allerdings noch erweitert und ein paar "#if LINUX_VERSION ... " eingebaut, damit es auch noch auf einem Kernel <2.6.28 läuft.

Ich stelle den gleich mal zur Verfügung.

Zitat

Original von Razorblade
Gerne mal testen und zurückmelden, ich bastel morgen (äh nachher) erstmal mein Netzteil (danke Nano, die Stecker sind angekommen!)...

Prima.
Danke für den Patch. So kann man es natürlich auch machen.

Schöne Grüße
Nano

UPDATE:
Ich habe meinen Download-Link entfernt. Leider kann ich den Beitrag nicht mehr editieren. Ich werde nun auch den Patch verwenden.

Könnte man sie V4L-Entwickler nicht fragen, ob die das dvbloop-Modul mit aufnehmen? Nur so eine Idee ...

Leute, es hindert Euch doch keiner daran, so eine Lösung zu bauen.

Also was habe ich gemacht?
Ich habe einfach einen aktuellen snapshot aus dem hg-repos genommen, alles rausgeschmissen bis auf dvb-core und meine angepassten dvbloop-Quellen hinzugefügt. Fertig.

Ich hatte arge Schwierigkeiten den "normalen" aktuellen Snapshot, meine angepassten dvbloop-Quellen und dann die auch vorhandenen (DVB)Kernel-Header unter einen Hut zu bringen. Ich konnte die Module hinterher nicht laden, weil nix zueinander passte.

Das Problem ist also:
a) Ich habe einen Kernel mit Kernel-Header installiert, der eine alte DVB-API mitbringt
b) Ich habe einen aktuellen S2API Snapshot, den ich separat mit den a) kompilieren kann, weil das Makefile dies irgendwie bewerkstelligt, obwohl im Kernel ja auch schon DVB-Includes sind
c) Ich habe das angepasste dvbloop-Modul, dass sich auf b) beziehen soll und von a) nichts sehen soll.
d) Ich bin kein Makefiles-Experte und weiß nicht, wie ich das bewerkstelligen soll, um c) zu erreichen. Darum habe ich es so gemacht, wie es jetzt gerade ist. Nicht schön, ich weiß.

Eine "Experte" müsste sich mal anschauen, wie ich die originalen dvbloop-Quellen gegen einen zusätzlichen Snapshot kompilieren kann und _NICHT_ gegen die im Kernel enthaltene DVB-API. Ist vermutlich nicht schwer. Ich kann es nicht.

Alles klar?

Zitat

Original von Razorblade
Bringt auch nichts.
Ich hatte schonmal in der dvblo_char.c den include auf semaphore von asm auf linux geändert, damit verschwindet der erste error, aber es bleibt:

Code

# make
make -C /usr/local/src/dvbloop-s2api/v4l
make[1]: Entering directory `/usr/local/src/dvbloop-s2api/v4l'
creating symbolic links...
Kernel build directory is /lib/modules/2.6.28-gentoo/build
make -C /lib/modules/2.6.28-gentoo/build SUBDIRS=/usr/local/src/dvbloop-s2api/v4l  modules
make[2]: Entering directory `/usr/src/linux-2.6.28-gentoo'
  CC [M]  /usr/local/src/dvbloop-s2api/v4l/dvblo_char.o
/usr/local/src/dvbloop-s2api/v4l/dvblo_char.c:116: error: array type has incomplete element type
/usr/local/src/dvbloop-s2api/v4l/dvblo_char.c: In function 'clsdev_op_store':
/usr/local/src/dvbloop-s2api/v4l/dvblo_char.c:136: error: dereferencing pointer to incomplete type
/usr/local/src/dvbloop-s2api/v4l/dvblo_char.c: In function 'clsdev_op_show':
/usr/local/src/dvbloop-s2api/v4l/dvblo_char.c:195: error: dereferencing pointer to incomplete type
/usr/local/src/dvbloop-s2api/v4l/dvblo_char.c: In function 'dvblo_chardev_release':
/usr/local/src/dvbloop-s2api/v4l/dvblo_char.c:723: error: implicit declaration of function 'class_device_remove_file'
/usr/local/src/dvbloop-s2api/v4l/dvblo_char.c:729: error: implicit declaration of function 'class_device_destroy'
/usr/local/src/dvbloop-s2api/v4l/dvblo_char.c: In function 'dvblo_chardev_init':
/usr/local/src/dvbloop-s2api/v4l/dvblo_char.c:793: error: implicit declaration of function 'class_device_create'
/usr/local/src/dvbloop-s2api/v4l/dvblo_char.c:793: warning: assignment makes pointer from integer without a cast
/usr/local/src/dvbloop-s2api/v4l/dvblo_char.c:813: error: implicit declaration of function 'class_device_create_file'
make[3]: *** [/usr/local/src/dvbloop-s2api/v4l/dvblo_char.o] Error 1
make[2]: *** [_module_/usr/local/src/dvbloop-s2api/v4l] Error 2
make[2]: Leaving directory `/usr/src/linux-2.6.28-gentoo'
make[1]: *** [default] Fehler 2
make[1]: Leaving directory `/usr/local/src/dvbloop-s2api/v4l'
make: *** [all] Fehler 2

Alles anzeigen

Könntest Du nicht wirklich einfach mal einen diff nur auf Deine Änderungen fahren (gegenüber dem Tree mit dem Du angefangen hast)? Oder reich einfach das changeset rüber von dem Du gestartet bist...

Kann ich machen. Die Änderungen an dvbloop selbst waren nur sehr wenige für S2API. Die Fehler oben deuten aber darauf hin, dass wohl wieder etwas Grundlegendes im Kernel verändert wurde. Alle diese Fehler aus Deinem Log-Auszug müssen geändert werden im dvbloop-Modul.
Da bringt auch das Auschecken der aktuellen S2API-Quellen nix. Es hat sich so gut wie nichts am dvbcore geändert in den letzten Wochen. Die Änderungen waren eher kosmetischer Natur.