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

    Hallo,


    hab gestern den NetCeiver im Internet gefunden und nun den passenden Thread hier.


    Ich hätte nur 2 kleine Fragen und möchte nicht extra die 17 Seiten durchlesen den Spaß hebe ich mir auf für den Fall falls ich mich für ein Kauf entscheide :D


    1. Läuft es alles schon stabil mit dem VDR und mach es einen Unterschied m Handling des VDR?


    2. Wenn ich ein CA-Interface mit Prem. Karte im NetCeiver benutzte könnte ich dann theoretisch bei 2 Dualtunern, 4 verschlüsselte Kanäle gleichzeitig gucken oder immer nur einen?


    Gruß


    Kay

    Hallo,


    ich habe mir jetzt auch einen Netceiver gekauft, der im Prinzip auch läuft. Jetzt habe ich nur das Problem, dass auf meinem VDR-Rechner keine adapter angelegt werden und somit auch der Netceiver nicht ansprechbar ist. Mcli sieht ihn und netcvdiag meldet auch nichts ungewöhnliches.
    Wenn ich das ganze auf meinem Laptop durchexerziere, dann funktionert alles wie es soll, d.h. ich lade dvbloop, starte mcli --ifname eth0, die beiden Adapter werden angelegt und ich kann mit szap tunen und mit xine bekomme ich auch was zu sehen. Bei beiden Rechnern ist Opensuse 11 installiert (dort blockt übrigens standardmäßig die Firewall den Verkehr, so dass mcli nichts findet, wenn die Firewall läuft). Der Hauptunterschied ist, dass der VDR-Rechner als 64bit-Version installiert ist. Beim kompilieren bekomme ich dort auch mehr Warnings als unter der 32bit-Version:



    Kann das sein, dass die warnings bzgl des "format ‘%d’ expects type ‘int’, but argument 3 has type ‘size_t’" das Problem sind ?


    Wenn ich das erste Mal nach einem Boot dann dvbloop installiere, passiert nichts ungewöhnliches, starte ich dann mcli, bekomme ich Fehlermeldungen im Syslog:

    Code
    kernel: ioctl32(mcli:3779): Unknown cmd fd(8) cmd(40a86409){t:'d';sz:168} arg(fff6d9fc) on / dev/dvblo0



    Ich vermute mal, dass im dvbloop was gepatcht werden muss, um mit einem 64bit-system zu laufen ?


    Tschau,
    Axel.

    Hallo,


    inzwischen habe ich den VDR mal komplett 32bittig installiert und siehe da, es läuft soweit, d.h. bei einem kurzen Funktionstest konnte ich 3 Adapter nutzen (1 x FF + 1 x Netceiver Twin-s).


    Legt der mcli eigentlich soviele virtuelle Adapter an, wie Tuner im Netceiver stecken (bei mir 2), oder immer nur 2 ?


    Tschau,
    Axel.

    Hi,


    Zitat

    Legt der mcli eigentlich soviele virtuelle Adapter an, wie Tuner im Netceiver stecken (bei mir 2), oder immer nur 2 ?


    default nimmt sich mcli soviel wie da ist. Mit der Kommandozeilenoption kann man das aber ändern bspw.


    mcli --dvb-s 1


    sagt dem Mcli, er soll nur einen Tuner nutzen (sinnvoll bei reinen Streamingclients)


    MfG
    KRis

    Intel DN2800MT 4GB RAM; 32GB mSata, Ubuntu 15.04, TVHeadend 4.1, Digibit R1 SatIP


    Nachdem ich jetzt wieder da bin, habe ich einige Stund3en verbrannt,
    aber ich bekomme es einfach nichtmehr hin:-(. Ich begreife es nicht.
    Mir ist nicht klar, was diesmal anders ist. Tuner sind da, aber "tunen"
    geht nicht.


    Inzwischen habe ich MCLI in einem batch gestartet, was sich selber wieder
    aufruft. Wenn MCLI sich mal verabschiedet, startet es dadurch gleich wieder neu. ifconfig eth1 down/up habe ich auch davor gehängt.
    Der Verbindungsaufbau klappt jetzt automatisch immer.


    Was irgendwie noch falsch ist, ist dass VDR laufen muss, damit mcli/dvbloop
    sich aktivieren lassen. VDR sucht ja offenbar nur beim Start
    nach Tunern (was normalerweise durchaus Sinn macht), daher muss ich es neu starten. Wenn ich das tue, gibt dvbloop samt mcli aber auf. Durch das batch, sind sie gleich wieder da, aber vielleicht nicht richtig!?
    Kann ich DVB core irgendwie laufen lassen, und nur VDR zur Tunersuche
    veranlassen?!


    Achso, ich sehe in der VDR-Config nach dem zweiten Start die Netceiver-Tuner. Die Änderungen an den Tunern wirken nur beim Start von VDR, oder?


    Nochwas, ich sehe auch keine Meldungen mehr, das Netceiver einige PIDs nicht erreichen konnte, was sonst der Fall war.

    Es läuft folgende Kette ab:


    dvbloop stirbt, weil dvbcore nicht da ist und mcli stirbt, weil dvbloop nicht da ist.
    Anderes herum kann ich dvbloop gar nicht erst starten, wenn dvbcore nicht da ist
    und mcli nicht, weil dvbloop fehlt.


    Eigentliche Ursache ist nach meinem minimalen Überblick über das System, dass
    VDR mit stop/start "dvbcore" ebenso stoppt(und wieder startet) und damit den loop
    auch umhaut.
    Bei Ct-CDR gibt es ein Restart, ggf. macht der das anderes (oder er ist nur eine Vereinfachung von stop/start....).


    Ich weiss nicht, ob das mein Problem verursacht, ich finde das Verhalten aber zumindest
    irgendwie falsch.


    ---


    Logfiles lesen hift! Die Tuner funktionieren zumindest in diesem Moment halbwegs.
    Das Problem ist, dass EasyVDR das primäre Interface der FF-Karte nicht richtig
    verläßt. Ich bekomme es zwar hin, dass der Kanal nicht verfügbar ist, aber die
    Netceiver-Tuner werden aberwohl nicht wirklich verwendet.
    Wenn ich zu diesem Rechner streame (VDRAdmin->Mozilla->VLC) kann ich für kurze Zeit gucken, dann zerfällt das Bild. Vermutlich benötigen die Netceiver-Tuner ein besseres Signal als die PCI-Karten, aber das sollte ich hinbekommen.
    RTL läuft seit 20 Minuten ohne Artefakt und "TS continuity error"...

    Nachdem meine letzte Jahresabrechnung vom Energierversorger gekommen ist, habe ich doch mal beschlossen meine "dauerlaufenden" Server etwas zu konsolidieren und überlege wieder in Richtung Netceiver.


    Dazu ein paar generelle aber auch aktuelle Fragen:
    1. Können mehrere vdr's gleichzeitig auf den Netceiver zugreifen, wenn ja wie läuft die Tunerverteilung statisch oder dynamisch (ggf. überbucht)? Kann bei gleichem Transponder evtl sogar. der gleiche Tuner von mehreren Clients benutzt werden?
    2. Wie schaut es mit dem Energiebedarf aus, soll ja recht niedrig sein, aber wieso dann ein 300W Netzteil bei Reel?
    3. In einigen Posts ist von einem Dual-DVB-S2 Tuner die Rede, finde aber nur einen Dual-DVB-S oder Single-DVB-S2 auf der Reel-Seite...
    4. Irgendwo wurden mal Windows-BDA Treiber angesprochen, kommt in die Richtung noch etwas?
    5. Wie sieht es Anpassungen an die S2API (DVBAPIv5) aus. So wie es aussieht, wurde ja bisher quasi mit einem Trick gearbeitet, aber jetzt wandert ja vieles dafür (z.B. DVB-S2 Erkennung) nativ in den vdr, wird es dafür angepaßte dvbloop-module geben um mit einem sonst ungepatchten vdr-1.7.1(+) zu arbeiten?
    6. In einem Thread wurden Probleme (entweder mit mcli oder dvbloop) auf 64bit Systemen gemeldet, gibt es da inzwischen einen Fix?
    7. Wie sieht es generell mit einem Geäuse aus, muß man etwas selber basteln oder paßt es auch irgendwo genau rein?
    8. Da verschiedentlich von CAM Problemen die Rede drängt sich die Überlegung auf, ob das "böse" Plugin evtl Abhilfe schafft oder geht das in der Kombination gar nicht?


    Gruß,
    Razor

    "1. Können mehrere vdr's gleichzeitig auf den Netceiver zugreifen, wenn ja wie läuft die Tunerverteilung statisch oder dynamisch (ggf. überbucht)? Kann bei gleichem Transponder evtl sogar. der gleiche Tuner von mehreren Clients benutzt werden?"


    Für den NetCeiver selbst ist das alles dynamisch, es können (nahezu) beliebig viele Clients sein, solange die Tuner/Transponder das hergeben. Für den vdr muss man das aber (noch) auf DVB-Karten runterbrechen, und da fängt dann die Logistik an. Man kann überbuchen, also zB. 2 vdrs je zwei DVB-Devices zuweisen obwohl insgesamt nur zwei echte Tuner da sind. Da der vdr aber meistens gleich beide belegt und dummerweise nicht mehr freigibt, bekommt der als zweites gestartete vdr nichts mehr (sieht aus wie kein Empfang). Falls der zweite aber was von einem Transponder will, den der erste vdr schon belegt, geht das natürlich. Damit blockiert man dem ersten vdr natürlich wieder sein Weg-Zappen.


    Das Overcommitment ist also nur in seltenen Fällen tauglich, wie es halt immer so ist... Ansonsten sollte man die Tunerbelegung so verteilen, dass es mit der tatsächlich vorhandenen Tuneranzahl übereinstimmt.


    Eine Priorisierung (Recording vs. Live) ist zwar vorgesehen, aber a) noch nicht implementiert und b) braucht es dann ein Input-Plugin für den vdr. Über die DVB-API ist das nicht mehr übertragbar.


    "2. Wie schaut es mit dem Energiebedarf aus, soll ja recht niedrig sein, aber wieso dann ein 300W Netzteil bei Reel?"


    Das Netzteil lag schon rum und hatte den passenden Stecker ;) Mit einem Multiswitch sollte man so von ca. 6W pro Tuner ausgehen, der NetCeiver liegt bei 5-10W.


    "3. In einigen Posts ist von einem Dual-DVB-S2 Tuner die Rede, finde aber nur einen Dual-DVB-S oder Single-DVB-S2 auf der Reel-Seite..."


    Den Dual-DVB-S2 gibts schon, aber erstmal nur bei mir im Test ;) Da aber alles ganz gut läuft, denke ich mal, dass man grob Ende Januar damit rechnen kann. BTW: Preis weiss ich (noch) nicht, nicht meine Baustelle...


    "4. Irgendwo wurden mal Windows-BDA Treiber angesprochen, kommt in die Richtung noch etwas?"


    Ja, der geht schon. Allerdings nicht mit CAMs. Dazu muss der CAM-Support im NetCeiver Multi-Client-fähig werden (was er jetzt nicht ist), und das dauert noch etwas. Das ist eine Business-Entscheidung und keine technische... Wäre für dich der CAM-Support unter Windows wichtig?


    "5. Wie sieht es Anpassungen an die S2API (DVBAPIv5) aus."


    Wenn das wirklich mal stabil ist, kommt es rein. Zur Zeit scheint mir die "Confidence" in jegliche S2-API eher mau zu sein. Nach der Hauruck-Aktion sind die Leute entweder angepisst oder machen nichts mehr an der Weiterentwicklung...


    "6. In einem Thread wurden Probleme (entweder mit mcli oder dvbloop) auf 64bit Systemen gemeldet, gibt es da inzwischen einen Fix?"


    Muss ich nochmal nachschauen, nachdem die AVG 32Bit nutzt, ist der Bereich etwas vernachlässigt.


    "7. Wie sieht es generell mit einem Geäuse aus, muß man etwas selber basteln oder paßt es auch irgendwo genau rein?


    Es wird (gerade auch wegen dem Client) einen "neuen" NetCeiver im Gehäuse geben. Technisch ändert sich nichts, nur der Formfaktor wird etwas handlicher. Wann der erhältlich sein wird, kann ich nicht sagen, der Gehäusebauer sitzt da aber schon dran.


    "8. Da verschiedentlich von CAM Problemen die Rede drängt sich die Überlegung auf, ob das "böse" Plugin evtl Abhilfe schafft oder geht das in der Kombination gar nicht?"


    Die CAM-Probleme haben folgenden Grund:


    An sich gibt es keine direkte Kommunikation vom Client zum NetCeiver und andersrum (klingt komisch, ist aber so). Das liegt einfach in dem ganzen Konzept begründet, was damit sehr einfach skaliert. Wenn man CAMs nutzen wollte, müsste also alles im NetCeiver behandelt werden, d.h. der vdr würde gar nichts mehr vom CAM mitbekommen. Die Lösung ist aber etwas umfangreicher. Weil darauf aber keiner warten wollte, haben wir mit (im Nachhinein) fast genausoviel Aufwand den CAM-Stack aufgeteilt zwischen vdr und NetCeiver. Damit gibt es jetzt eine direkte TCP-Verbindung und wir haben uns eine ganze Menge Probleme damit eingehandelt. Das fängt damit an, dass nur ein Client die CAMs nutzen kann, geht über Timingprobleme und Races bis zu diversen Merwürdigkeiten im vdr, die immer wieder reinhauen. Viele sind zwar inzwischen behoben (und damit ist der CAM-Teil im vdr schon nicht mehr Original), aber das ganze ist immer noch arg fragil. Und es gefällt uns einfach nicht :computertod


    Der "richtige" (ursprünglich geplante) CAM-Support wird jetzt implementiert und wird das alles hoffentlich erschlagen.


    Dem Vernehmen nach läuft das böse Plugin ;) Es gibt ja auch keinen Grund, warum nicht...

    Prima und vielen Dank für die ausführlichen Antworten! Habe vorhin gleich mal zugeschlagen und einen Netceiver und zwei DVB-S2 Module erstanden, ein Dual-DVB-S2 werde ich dann wohl später nachrüsten.


    1. Das ist doch prima, genau so hätte ich es mir gewünscht, nur schade, daß der VDR die Tuner nicht mehr rausrückt, aber vielleicht kann man noch etwas drehen. Im Zielausbau hätte ich gerne einen VDR als Aufnahme-Server und dann 2-3 Clients (evtl 2x vdr direkt auf einer Popcorn Hour und 1x Windows-Client) die "bei Bedarf" etwas schauen. Im Moment ist es aber "nur" der Aufnahme-vdr da ist das noch nicht so wichtig.


    2. Das hört sich gut an, habe einen Multiswitch, also sollte ich selbst im Endausbau (2x Single-DVB-S2, 1x Dual-DVB-S2) noch unter 50 Watt liegen, mal gucken was es da so an vernünftigen Netzteilen mit wenig Verlustleistung gibt.


    3. siehe oben ;)


    4. Nein, der CAM-Support hat da keine Priorität für mich, später vielleicht schon, aber zum schnell-mal-irgendwo-reinzappen sollte es passen.


    5. Das wäre für mich fast am wichtigsten, da ich sobald verfügbar auf den neuen vdr mit TS-Recording umsteigen möchte (wegen Weiterverarbeitung der Aufnahmen). Wie sich zur Zeit in der ML anbahnt wird vdr 1.7.2 schon auf S2API basieren.


    6. Ich plane den VDR in einer Xen domU laufen zu lassen, die kann ich notfals auch 32bittig erstellen, kann dann aber nichtmehr die Binaries mit den anderen domU teilen (zB in Form von vorkompilierten Gentoo Packages)


    7. Da ich jetzt schin bestellt habe, bin ich für das neue Design zu früh, also wird es wohl etwas gebasteltes... schade.


    8. Dann tendiere ich ja fast zum bösen Plugin, dann hat der Netceiver gar nichts mit CAMs am Hut und man ist eindeutig flexibler (ggf sogar in Zusammenhang mit einem Windows-Client), aber solche Diskussionen sind ja hier nicht unbedingt erwünscht deswegen sparen wir uns mal die Details, nur eins noch: Der vdr würde ja dann kein CAM des Netceivers sehen müssen, kann man sich dann die Patcherei am vdr (in Richtung CAM handling) sparen?



    Gruß,
    Razor

    "aber vielleicht kann man noch etwas drehen"


    Ist nicht ganz so einfach. Jedes PI kann sich ja PIDs bestellen, und im Hintergrund verwursten (zB. Teletext). Die wenigsten PIDs werden fürs eigentlich Schauen gebraucht...


    "noch unter 50 Watt liegen,"


    Ja, deutlich. Die ganze AVG liegt in der Standardausstattung (2*S2) unter 75W. Wir gehen zur Zeit davon aus, dass der Standalone-NetCeiver mit einem 65W-Netzteil auskommt. Und wer tatsächlich an JEDEM seiner 6 Tuner einen Rotor mit Einzel-LNB hat (kann in Spitze schon allein 60W für Rotor+LNB sein...), muss dann halt ein dickeres nachkaufen. Oder er kann sich gleich einweisen lassen...


    "5. Das wäre für mich fast am wichtigsten, da ich sobald verfügbar auf den neuen vdr mit TS-Recording..."


    Nur so am Rande: Der reel-vdr macht TS für HDTV schon seit 18 Monaten. Ich weiss gar nicht, wo die Leute ein Problem haben ;)


    "kann man sich dann die Patcherei am vdr"


    Ja.

    Zitat


    "aber vielleicht kann man noch etwas drehen"


    Ist nicht ganz so einfach. Jedes PI kann sich ja PIDs bestellen, und im Hintergrund verwursten (zB. Teletext). Die wenigsten PIDs werden fürs eigentlich Schauen gebraucht...


    Damit meinte ich auch eher am vdr etwas basteln, zB ganz simpel VDR beenden wenn nicht in Benutzung ;)
    Bei Aufnahmen wieder aufwecken sollte ja kein Problem sein, aber bei Zugriff auf den vdradmin schon. Aber das ist auch nur Perl, sollte sich irgendwie bewerkstelligen lassen...

    Hallo,


    nachdem der NetCeiver ein paar Tage stabil lief treten inzwischen Probleme auf. Scheinbar funktioniert der eine Tuner von der Twinkarte nicht mehr korrekt.
    Netcvdiag gibt z.B. folgendes aus:



    und MCLI meckert auch:

    Code
    Discontinuity on receiver 0x806d570 for pid 18: 0->5 at pos 0/7


    Das passiert aber scheinbar nur, wenn der erste (obere ?) Tuner benutzt wird, der untere scheint zu gehen. (Der obere wird auch viel wärmer).


    Die komische Frequenzangabe in den Klammern wundert mich auch ein bischen, sollte da nicht auf jeden Fall was sinnvolles stehen ?.


    Kabel sowie Port am Multiswitch habe ich schon ohne Erfolg getauscht.


    Ist der Tuner hinüber, oder was kann ich noch testen ?


    Axel.

    "6. In einem Thread wurden Probleme (entweder mit mcli oder dvbloop) auf 64bit Systemen gemeldet, gibt es da inzwischen einen Fix?"


    Wenn ich das richtig verstehe, resultiert das Problem daraus, dass mcli 32bittig ist, während dvbloop ja dann ein 64bittiges Modul ist und dann vermutlich die Parameter bei den ioctls nicht mehr passen und man dann eine extra Funktion bauen kann/muss um die Parameter von 32bit-Anwendungen richtig auf 64bit Strukturen umzusetzen. Jedenfalls gibt es für das v4l-Zeugs eine linux/drivers/media/video/compat_ioctl32.c mit dem Kommentar
    * These routines maintain argument size conversion between 32bit and 64bit
    * ioctls.



    Axel.

    Firmware ist die 88B.


    Powercycle hilft nichts, das habe ich schon mehrfach versucht (um mir den Inhalt von der SD-Card anzusehen).


    Netcvdiag -a sagt folgendes:



    Axel.

    Hallo!


    Zwei Fragen:


    1)
    Hat jemand von Euch den Netceiver evtl. schon in ein wetterfestes Gehäuse (IP65) eingebaut und betreibt ihn draußen?


    Meint Ihr, dass das klappt?


    2)
    Weiß jemand, wie KLS Einstellung zu Input-Plugins ist?
    Ich finde, dass es höchste Zeit wird, den VDR so weit wie möglich von der alten DVB-Hardware bzw. irgendwelchen APIs zu entkoppeln. Ebenso bei der Ausgabe.
    Ich weiß, dass das Thema schon einmal auf der Mailing-Liste behandelt wurde. Ich halte den aktuellen Zustand für traurig aus Sicht eines VDR-Begeisterten. Vor allem, weil es jedes Mal Modifikationen am VDR selbst gibt. Auch, wenn es vielleicht nur dvbdevice.c ist.


    Der Netceiver zeigt deutlich, dass auch hier Bedarf bestünde. Es bräuchte dann nicht mehr diesen Weg von hinten durch das Auge mit dem dvbloop-Modul.


    Weg mit dem API-Zwang für VDR! :)
    Dann lieber ein Input-Plugin für jede API.
    Ich finde, dass man mal eine Umfrage starten sollte.


    Gruß
    Nano

    fände ich auch gut

    Vor einiger Zeit gab es doch auf der vdr-ML die Frage, ob/wie man/kls den vdr in ein Repository bringt. Das hat viele Mails verursacht, die meisten nach dem Motto "ich kann zwar nicht programmieren, aber ich habe Webspace"...


    Ich habe dann mal den Thread gehijackt und diverse "Problempunkte" im vdr angesprochen, die meiner Meinung nach wichtiger als die Art des Quellcodezugangs und tatsächlich zukunftsrelevant sind (IPTV, auch Input-PI). Ausser einem (in etwa) "ja, da sollte man was tun" war es auf einmal totenstill und die Diskussion war zu Ende ;)


    Was soll man davon halten? Jeder will, aber keiner kann?


    Ich sehe halt auch, dass RMM langsam aber sicher auf einen fork im vdr zusteuert. Die Userbasis des reelvdrs und damit des gesamten HDTV-Codes ist IMO wohl deutlich grösser (wohl schon 5stellig) als die des offiziellen Patchsets, der aber wegen dem TS-Umstieg eh rausfliegt. Ich glaube nicht, dass RMM sich darauf einlässt, den eigenen, halbwegs enduser-sicheren Code so schnell rauszuwerfen. "Wir" haben die ganzen Probleme schon hinter uns, das braucht es nicht nochmal...

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden