[HOWTO] Netceiver im externen Gehäuse, Infos zum Netceiver

Heisst das jetzt, dass du dich um dieses Problem kümmern willst und es bald eine Lösung für den Einsatz mit den Netceiver gibt?

D.h. dass ich es zumindestens mal versuche, kann nichtmal versprechen *ob* es klappt, geschweige denn *wann*...

Ich scheitere im Moment an der Declaration der structs im dvblo_adap.h

struct
	{
		struct dvb_frontend_parameters params;
		struct
		{
			struct dvb_frontend_parameters params;
			u32 status;
		} tuner;
		dvblo_sec_t sec;
		dvblo_festatus_t status;
	} fe;

Hat einer Idee wie das Aussehen müßte (anstatt der beiden "struct dvb_frontend_parameters params;")?

In der dvblo_adap_fe.c sind die nötigen Änderungen wohl trivial, in einigen Funktionsaufrufen muß der übergebene Paramater p bzw params gelöscht werden und dafür ein
struct dtv_frontend_properties *p = &fe->dtv_property_cache;
hinzugefügt werden.

Ich wollte mal einen Zwischenschritt mit Kernel 3.2.0 machen da dies ja wir hier beschrieben funktionieren soll, allerdings habe ich massive Probleme mit DVB-S2
Ich bekomme alle DVB-S Transpondern getuned aber *keinen* DVB-S2, habe mit vdr, scan-s2 und szap-s2 probiert...

Auch auf die Gefahr hin, dass das hier zu einem Selbstgespräch ausartet:

Anscheinend fehlt für Kernel 3.2.0 (DVB API 5.0.5) noch ein bißchen mehr als bisher hier gepostet, dass äußert sich spätestens bei der Benutzung eines aktuellen VDR (oder S2APIWrapper light patch), die zur Laufzeit die DVB API Version prüfen. da wird dann nämlich davon ausgegangen, dass das Frontend auch alle Funktionen der laufenden API unterstützt, das wären u.a. frontend.info.delsys (Delivery System). Das tut dvbloop aber nicht sonder beschränkt sich auf die alten frontend.info.type und frontend.info.caps.
Dadurch auch mein Problem mit DVB-S2, vdr geht einfach davon aus, dass das DVB interface kein DVB-S2 kann, weil es Treiber nicht meldet. Ebenso w_scan.

Fazit: Hier ist deutlich mehr Arbeit nötig als nur ein paar Deklarationen anzupassen wenn das Ergebnis auch mit mehreren Kernel-Versionen laufen soll. Sollte sich nicht noch ein Mitstreiter finden oder Baycom wider erwarten doch selbst was macht war es das wohl...

Für mich selbst habe ich es jetzt erstmal unter 3.2.0 zum Laufen gebracht in dem ich im VDR Source den "Legacy_Mode" erzwungen habe, das teste ich jetzt erstmal ein paar Tage und dann überlege ich mir ob ich noch weitermache oder nicht.

Hi Razorblade,

ich hing genau an der selben Stelle fest und habe in meiner Unwissenheit einfach params mit *p ersetzt und er ging weiter.
Doch nun mault er hier rum :

guido@vdr:/usr/src/dvbloop$ sudo make KDIR=/usr/src/linux-source-* install
make -C /usr/src/linux-source-* M=`pwd` modules
make[1]: Betrete Verzeichnis '/usr/src/linux-source-3.11.0'
make[1]: Für das Ziel »/usr/src/linux-source-3.11.0.tar.bz2« ist nichts zu tun.
CC [M] /usr/src/dvbloop/dvblo_adap.o
/usr/src/dvbloop/dvblo_adap.c: In function ‘dvblo_adap_create’:
/usr/src/dvbloop/dvblo_adap.c:348:18: error: ‘struct <anonymous>’ has no member named ‘status’
dvblo->fe.tuner.status = TUNER_STATUS_LOCKED;
^
make[2]: *** [/usr/src/dvbloop/dvblo_adap.o] Fehler 1
make[1]: *** [_module_/usr/src/dvbloop] Fehler 2
make[1]: Verlasse Verzeichnis '/usr/src/linux-source-3.11.0'
make: *** [build] Fehler 2
guido@vdr:/usr/src/dvbloop$

Das könnte ein Problem meiner vorherigen Änderung sein.Oder ?

mfg guigra

Hallo,

ich habe den ext. NetCeiver ohne Probleme im yaVDR 0.5 ans laufen gebracht.
Nun habe ich aber das Problem, das ich nur FreeTV bekomme (Card Server auf Freetz, weil Karte an 3 Stellen benoetigt wird)
Meine Suche nach dem Problem ergaben, das es z.Z. nicht geht (nie wieder?), weil das boese Plugin und das MCLI Plugin miteinander reden muessen.
Kann mir das jemand so bestaetigen, oder geht es ggf. doch (dann bitte ein paar Hinweise).
Hab eine alten Patch gefunden, der aber so nicht auf das Plugin anwendbar ist. Fuer die AVG II gab es ja was, was aber nur in der Box
laufen will und ich wollte ungern die alte AVG Soft installieren - lieber eine akt. VDR und dann auch neuere Updates erleben.

Noch eine Frage:
Als meine AVG II im sterben lag, hab ich versuchsweise Tuner deaktiviert und weiss akt. nicht, wie ich die jetzt ohen Reelbox wieder aktiviere.
Ich vermute, das es mit den mcli Tools geht, hab aber nichts gefunden? Ideen?

Danke

Du wirst auf deine erste Frage hier wahrscheinlich keine Antwort bekommen. Wüsste aber nicht, was das Mcli-Plugin dort behindern sollte...

das MCLI Plugin wird auch nicht behindert - das boese Plugin kann wohl nur mit einem DVB Device reden und muesste gepatched werden, damit es direkt mit dem MCLI reden kann - der Patch ist aber von 2010 und laesst sich vmtl. nicht mehr auf akt. Quellen anwenden - ggf. gibt es noch weitere Stolpersteine in dieser Kette - die Infos dazu sind sehr duenn.
Das ist akt. mein Stand nach 3 Wochen suchen/basteln/nicht weiter kommen...
Fuer mich ist das auch kein "boeses" Plugin, sondern nur ein sinnvoller Weg etwas zu nutzen - wir werden genug gegaenglet - solang jemand zahlt, soll er/sie doch machen was er/sie will...

Die meisten NetCeiver Nutzer werden was von Reel (Roxx) haben und dafuer gibt es ja alles schon passend.
NetCeiver finde ich eigentlich gut und wuerde den gerne weiter nutzen - aber so langsam waechst der Druck Zuhause, das man wieder richtig Fernseh schauen/aufnehmen kann.

Das Problem ist eher das das mcli Plugin gepatched werden müsste, mit VDR 2.1 geht es gar nicht mehr. Das Böse für Reel ist ein Fork der nicht komplett bzw. nur in Teilen veröffentlicht wurde, dieses Plugin benötigt aber einen gepatchten VDR und den findest Du nur in der ReelVdr Distribution.

Dein Problem mit den deaktivierten Tunern müsstest Du mit netcvupdate gefixed bekommen. Mit

netcvupdate -A -D

sollte die netceiver.conf ausgelesen werden. Mit netcvupdate lässt sich auch eine geänderte Konfiguration wieder einspielen. Fragen solltest Du aber besser im Reelbox Forum stellen, dort kennt man sich damit besser aus.

Ihr redet dann wahrscheinlich von der dvbapi, oder wie?

Ich meine das CS sollte doch auch so funktionieren....

mcli läuft mW nur bis vdr 2.0.5 oder 2.0.6

mit den developer versionen geht es nicht
wobei ich es für den pi mal gegen den 2.1.6 meine ich gebaut hatte -> bekam aber keine rückmeldung -> was mir prinzipiell egal ist da ich keinen netceiver mehr nutze

2.0.6 ist die letzte out-of-the-box Version die läuft IMHO

Zitat von Moorviper

wobei ich es für den pi mal gegen den 2.1.6 meine ich gebaut hatte -> bekam aber keine rückmeldung -> was mir prinzipiell egal ist da ich keinen netceiver mehr nutze

Bauen lässt es sich auch, nur bekommt man bei der Benutzung keinen Lock...

Zitat von Frodo

Das Problem ist eher das das mcli Plugin gepatched werden müsste, mit VDR 2.1 geht es gar nicht mehr. Das Böse für Reel ist ein Fork der nicht komplett bzw. nur in Teilen veröffentlicht wurde, dieses Plugin benötigt aber einen gepatchten VDR und den findest Du nur in der ReelVdr Distribution.

Dein Problem mit den deaktivierten Tunern müsstest Du mit netcvupdate gefixed bekommen. Mit

Code

netcvupdate -A -D

sollte die netceiver.conf ausgelesen werden. Mit netcvupdate lässt sich auch eine geänderte Konfiguration wieder einspielen. Fragen solltest Du aber besser im Reelbox Forum stellen, dort kennt man sich damit besser aus.

Die NetCeiver Tuner wieder zu aktivieren hat fast problemlos funktioniert - man benoetigt zum wieder einspielen 'xmllint' - hab ich durch ein leeres Shellscript simuliert

Nach allem was ich jetzt gelesen und gefunden habe scheint es mir, das NetCeiver fuer akt. VDRs nicht mehr benutzt werden sollte - mit aelteren kann man vmtl. noch lange damit gluecklich sein.
Ich finde das Konzept gut - IP-TV waere eine Alternative - also mit "einfacher" Hardware vom Multischalter ueber ein Netzwerkkabel die ganzen Tuner dahin zu bekommen wo man die braucht und nur 1 Kabel legen zu muessen und nicht n Kabel in m Zimmer...

Meiner Meinung steht der Netceiver technisch SAT>IP in nicht nach, die Funktion ist bis sogar sehr sehr ähnlich (nur halt IPv6 Multicast anstatt IPv4 Unicast), leider hapert es nur an der Unterstützung auf Treiber/Kernel-Seite.
Was die vdr Unterstützung angeht, kommt es auf die Definition von "aktuell" an. Der aktuelle Release vdr (2.0.6) wird sehr wohl unterstützt, nur die neueren Entwicklerversionen (2.1.x) nicht. Leider ist genau in den Entwickler-Versionen die von vielen präferierte neue CAM-Implementation, weswegen man da als Netceiver Nutzer derzeit in die Röhre guckt.

Der vdr-developer-User mhorwath hat einen patch für vdr 2.1.x geschrieben:
http://projects.vdr-developer.…r-plugin-mcli-2.1.x.patch

Ich habe es vorgestern zum repo hinzugefügt...

http://projects.vdr-developer.org/projects/plg-mcli

Gruß,

Lars

Funktioniert wunderbar, danke!

Was ich allerdings noch nicht geschafft habe, ist das ganze auch mit meinem Lieblingsplugin zum Laufen zu bringen. Mit dem SATIP Plugin scheint das ja zu gehen, müßte dann doch eigentlich auch mit dem Netceiver Plugin?!?
Habe schon auf Netzwerk-Modus / listen_port umgestellt, sehe aber keine Anfragen vom vdr bzw dem Plugin auf dem entsprechenden Port ankommen... sehr merkwürdig. Oder verhindert evtl das CAM-Handling im MCLI-Plugin, dass das externe Plugin jemals getriggered wird?

Richtig mhorwath hat das Plugin nur dahingehend angepasst das es unter vdr 2.1.x baut und mit Free-TV sendern funktioniert

das ganze cam handling fehlt daher kein ....api oder voldemort es geht meines wissens nach auch kein Hardware cam

Ja, habe auch gesehen, dass die CAM-Spezifischen Teile auskommentiert wurden und damit das native CAM-Handling nicht mehr geht. Aber ich dachte Sinn und Zweck der Änderungen in vdr 2.1.4 war es gerade das CAM Handling vom Eingabeplugin abzukoppeln, so dass das Eingabeplugin sich nicht mehr darum kümmern muss wo/wie das gemacht wird?!? Wieso muss denn noch was im mcli Plugin angepasst werden?