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

Zitat

Originally posted by kris
Hi,

erstmal brauchst Du für ein VLAN zwei dinge

1. einen VLAn fähigen Switch
2. eine Änderung der Netzwerk-Konfig in Linux

Zu 1. Im VLAN-Fähigen Switch muss man einstellen, das der PORT wo der Netceiver hängt in z.b. VLAN 2 liegt.

Zu 2. Der VDR Software bringt man bei, im VLAN 2 zu "funken" ich habe im Reelboxforum ein howto dazu geschrieben.

Fertig....

MFG
KRis

Alles anzeigen

danke. an 2) hakt es wohl noch. das werde ich angehen. 1) war klar

Ich habe Probleme mit dem Kompilieren des dvbloop-Adapters:

Wenn ich auf den frischen DVB-Treibern make menuconfig ausführe, finde ich keinen Punkt um dvbloop auszuwählen. Und wenn ich stattdessen den dvbloop-s2api_v3.patch anwende, bekomm ich eine Fehlermeldung.

Kann mir jemand sagen was ich tun muß? Brauche ich eine neuere Version des Patches, oder brauch ich den mittlerweile gar nicht mehr?

- Aktuelle DVB-Treiber geholt (hg clone http://linuxtv.org/hg/v4l-dvb)
- Den Patch dvbloop-s2api_v3.patch.gz geholt (http://www.vdr-portal.de/board…nt.php?attachmentid=24024)
- zcat dvbloop-s2api_v3.patch.gz | patch -p1

Ergebnis:

patching file linux/drivers/media/dvb/dvbloop/dvblo_adap.c
patch: **** Can't rename file /tmp/po6c8VUc to linux/drivers/media/dvb/dvbloop/dvblo_adap.c : No such file or directory

/tmp gibt es. linux/drivers/media/dvb/dvbloop/ gibt es nicht.

Das weiß ich ehrlich gesagt nicht mehr, ist schon eine Weile her, aber direkt auf den Streamdev-Stream ging alles mit dem virtuellen DVB-Adapter nicht, Codec sollte also dabei keine Rolle gespielt haben...

HI,

nano,
gab es probleme mit dem Plugin unter 1.7.14? Hier geht es darum, den Netceiver unter yavdr verfügbar zu machen.

Wenn das nicht kompilierbar ist unter 17.14 bzw nur mit Patch, würde ich gerade eine dpatch erstellen...

MFG
Kris

Hi,

nano
danke Dir, ich habe gerade die Änderungen bei mir gemacht und eine dpatch gebaut, kompiliert und läuft.

MfG
Kris

Zitat

Originally posted by Nano
Razorblade:

Ok, danke für die Antwort.

Anbei ein Patch für das vdr-mcli-Plugin, damit es sich mit VDR-1.7.14 übersetzen lässt.

danke! kompiliert wieder sauber durch.

Hi ,

ich hatte ja in meinem letzten Post geschrieben das ich berichten wollte wenn ich mein Aopen Board mit dem VDR und Netceiver zum laufen gebracht habe. Und was soll ich sagen, es funktioniert super auch HDTV.Jetzt, ich klimper gerade diesen Beitrag, schaue ich arteHD. ZDFHD, ARDHD und einsfestival HD laufen laufen ebenfalls super. AnixHD geht leider nicht,warum auch immer.Also ist das Aopen Board mit der Intelgrafik locker dazu in der lage.Eigentlich kann die Installation für HDTV_VDR mit NVIDIA VDPAU übernommen werden und statt VDPAU NVIDIA geschichte einfach den passenden Intelgrafiktreiber installieren.Was mich noch überrascht hat ist die Tatsache das auch HDTV schauen und gleichzeites aufnehmen läuft.Der Datenstrom vom Netceiver kommt sauber an und es sind keine Bildstörungen sichtbar.Den Netceiver lasse ich dauerhaft am Netz ausser ich verlasse für längere Zeit das Haus oder es steht keine Aufnahme an und ich will kein TV sehen.Weis jemand von euch wie die Pakete aufgebaut sind die vom Netceiver ins Netzwerk gestreamt werden? Wo könnte ich diese Infos bekommen? Bitte nicht auf google verweisen, das habe ich schon selbst versucht. Ich muss wissen ob der Netceiver die Daten nur in normaleTCP-IP Pakete verpackt und verschickt oder ob sie vorverarbeitet werden.Ich möchte die Dekodierung in Silizium gießen.
Auf meinem FPGA Developmentboard bestehen genügent Resourcen dafür zur Verfügung. Das ganze läuft dann ohne OS. Das ganze steht und fällt mit dem Paketaufbau da dieser bestimmt wie gross der Aufwand zur Vorverarbeitung wird.Ich weis das diese ein Riesenprojekt ist aber ich will halt mein teures Board für einen sinnvollen Einsatz nutzten.

bis denn

Guido

das sind die rohen transport streams, aber pid-gefilter das tuning läuft aber proprietär mit (ipv6) multicast gruppen-mitgliedschaft

schau Dir mal das netcv2dvbip Paket hier im Thread an, das wandelt das ganze in reines DVB-IP um
das was bei netcv2dvbip hinten rauskommt sollte also jeder standard decoder beherrschen, das was netcv2dvbip macht müßtest Du also implementieren plus normales mpeg decoding

Hi Razorblade,

danke für deine schnelle Antwort.Ich habe mir mal das netcv2dvbip angeschaut und siehe da genau das was ich brauche.Wenn ich das richtig verstehe nimmt dieses Programm den ankommenden Datenstrom und macht daraus IPv4 Pakete die dann im Netz je nach Senderliste z.B ARD eine feste IPadresse erhalten.Nutzer die dann alle ARD schauen wollen müssen diese IPadresse angeben und VLC oder andere Player geben dann diesen Stream wieder.Ok das lässt sich in Silizium gießen.Das wird zwar nicht einfach, ist aber aufgrund von freien IP-Cores möglich.Da ich aber nicht nur ein Design zusammenklicken will, wird eine Menge Tiparbeit und Simulationen auf mich zukommen.Aber erstmal klein anfangen und PDF Dokumente welsen um die Protokolle und den Mechanismus zu verstehen.

Schönes Wochenende

bis denn guigra

Der NetCeiver schickt jede PID in einer eigenen IPv6-Multicast-Gruppe. Der Inhalt der UDP-Pakete sind dann aber nur die rohen TS-Pakete, wie sie auch von DVB kommen. d.h. kein RTP-Header, etc. Damit ist DVB so transparent wie möglich umgesetzt...

Das Protokoll für den ganzen Kram ist mit der mcli-Lib in SW verfügbar. Im wesentlich besteht es aus einem Mapping der Tunereigenschaften auf eine Multicast-Gruppe. Diese wird dann per MLDv2 angefordert, d.h. die MCG mit dem Datenstream wird erst on-demand sichtbar. Eine echte bidrektionale Kommunikation gibt es nicht, es hängt alles relativ locker zusammen und wenn man sich auf bestimmt Setups beschränkt (zB. schon vordefinierte MCGs für die Auswahl der Transponder/PIDs) sollte das auch ohne CPU in reiner HW zu machen sein. Der NetCeiver macht das ganze UDP-Streaming auch ohne CPU-Hilfe, nur die Verwaltung braucht die CPU.

BTW: Falls noch nicht bekannt, etwas mehr Details gibts hier: http://www.baycom.de/~acher/ne…netceiver_white_paper.pdf

Hi real_schorsch,

danke für deine Antwort und den Hinweis auf das Whitepaper.Diese Doku zeigt sehr gut die Funktionsweise des Netceivers und erklärt auch wie die Pakete aufbebaut sind.Da hier mit UDP gearbeitet wird und die Pakete nicht verändert werden bedarf es auch keiner hohen Vorverarbeitung.Was die MCGs betrifft so werde ich eventuell im Blockram eine Tabelle hinterlegen die Anhand der PID den passenden Sender erkennt.Das ganze Design soll dann den TS dekodieren (A/V) und dann sowohl auf VGA und TV (auch alte Geräte) ausgegeben werden. Für die alten Geräte wird aus dem YUV oder RGB Signal (steht noch nicht fest) ein sauberes FBAS generiert werden.Was das speichern von Sendungen betriff, das wird es erstmal nicht geben da mein Kenntnisstand dafür nicht ausreicht.

Einen schönen Sonntag noch,

bis bald

Guido

Du musst aber noch unbedingt so alle 5s die MLDv2-Pakete mit den MCGs abschicken, die du haben willst, sonst passiert nichts. Der Timeout, ab wann eine MCG als nicht mehr abonniert betrachtet wird, wenn sie nicht explizit abbestellt wird, liegt AFAIR bei 10-15s oder so, d.h. nur einmal schicken hilft nicht...

Hi real_schorsch,

alles klar ich werde die 5 Sekundenpost berücksichtigen :-). Danke für den Hinweis.

Bis denn

guigra

hello, I try to explain my problem.
I bought the box for netceiver, to move outside of the avantgarde.
I built one with Ubuntu and vdr mediacenter. if I link netceiver in both reel in my mediacenter, behind a swich gigalan
the mediacenter not take the Tunner free, but takes the Tunner already occupied by the avant-garde.
I start MCLI in a certain way?

the netceiver has 3Tunner , 2 DVB-S2 and 1 DVB-T

I hope I was clear.
regards
topogigio
mod vdr italia

It is not possible to share tuner between multiple systems.
At runtime of mcli you have to state the number of tuners that should be available (on the system where you start mcli). Only the remaining tuners will be visible to other systems.
See "mcli --help" on how to specify the number of tuners (per DVB-system)

Hi,

Nano

Zitat

Original von Nano
also ich habe hier den VDR mit den Diff's von kls von 1.7.12 auf 1.7.14 aktualisiert. Das mcli-PI habe ich frisch ausgecheckt. Das Problem liegt in device.c. Die Klasse cChannel enthält die Member System(), Modulation(), Inversion(), etc. nicht mehr. Stattdessen muss man sich einen String holen und den Parsen, damit man wieder an die Parameter kommt. Das Parsen macht die neue Klasse cDvbTransponderParameters.

Läuft bei Dir den das mcli-Pi zufriedenstellend unter 1.7.14? Ich habe es unter yavdr mit 1.7.14 ums verrecken nicht hinbekommen, das überhaupt ein Bild angezeigt wird.

Der Witz ist, das netcvdiag funktioniert, netcvlogview zeigt auch was an, einen Lock gibt es auch (könnte aber auch vom Server sein), nur der VDR weigert sich, was anzuzeigen.

Hat sich was an der channels.conf geändert? Muss man was anderes in irgendeneiner conf geändert werden (gemeint ist sowas wie sources.conf bzw diseqc.conf)?

dvbloop und mcli-dämon laufen übrigens einwandfrei (und ich trauere den beiden gerade hinterher ).

MFG
KRis

Zitat

Originally posted by kris

dvbloop und mcli-dämon laufen übrigens einwandfrei (und ich trauere den beiden gerade hinterher ).

MFG
KRis

also ich installiere das gespann gerade wieder. ich probier jetzt seit 2 monaten mit mlci plugin rum, und schaffe es einfach nicht. hab mir sogar extra ein 9.10er installiert, nur um sicher zu gehen, dass es nicht an irgendwelchen start scripts o.ae. von yavdr liegt.

es geht einfach nicht. vdr findet den netceiver, aber behauptet weiter steif und fest, dass es den kanal nicht tunen kann.