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

"Unter vdr-1.6 muss weder die diseqc von mcli genutzt, noch ein patch angewandt werden."

Das geht dann aber nur über Mini-Diseqc-Kommandos, d.h. zwei Satelliten. Wenn man mehr will oder aus Versehen das volle Diseqc anschaltet, geht *NUR* die etwas seltsame Diseqc-Message, die der mcli für jede Sat-Position ablegt.

Zum Testen sollte man "netcvdiag -a" ausprobieren. Das zeigt an, ob überhaupt ein Tuner benutzt werden will, ob der vdr die richtige Frequenz und Satpos übermittelt hat, ob der Tuner ein Lock hat und ob der LNB/Multiswitch-Port wenigstens etwas Strom zieht. Damit lassen sich dann der Reihe nach mögliche Probleme einkreisen.

Und um mich mal anzuschließen: Wann kommt das Netzteil und um was geht es genau dabei? Steckernetzteil oder eingebaut im Gehäuse?

Ich habe schon alles abgesucht, finde aber kein Restposten-Netzteil, welches die nötige Spitzenleistung verträgt. Zumal die 3,3V in den meisten Fällen durch einen extra Wandler aus den 5V oder 12V generiert werden müssen. Alternativ: Beide Spannungen mit DC/DC-Schaltwandlern aus 12V generieren, aber dann wird das Netzteil schon ein kleines 12V-Standgerät

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

Das NT ist eigentlich zweigeteilt. Es ist ein "normales" externes Brick-NT (ala Notebook) mit 65W/19V und ein speziell für den NetCeiver entwickelter interner DC/DC-Wandler, der die 12V/5V/3.3V mit den nötigen Strömen (bei 12V ca. 5-6A) bei hoher Effizienz erzeugt. Da geht dann einfach der Stecker zum NetCeiver weg, wie er auch am ATX-NT dran ist.

Das externe NT ist wohl für 99.999% aller Fälle ausreichend. Nur wenn an allen 6 Tunern ein einzelner LNB/Rotor mit >350mA hängt, wird es knapp, ist aber schon recht extrem. Zum Vergleich: 6 S2-Tuner mit 5 MS-Ports (a 50mA/Port) und einem LNB+aktiver Rotor brauchen ca. 33W.

@Mreimer: Kannst Du nochmal genau sagen welche Probleme Du mit dem (welchem genau) Patch hattest?
Ich habe gerade den hier http://www.vdrportal.de/board/…nt.php?attachmentid=20875 gegen einen aktuellen CVS snapshot laufen und außer einem trivialen Reject im Makefile lief alles durch.
Das ganze läuft bei mir jetzt unter kernel 2.6.29-gentoo-r1 mit vdr 1.7.5 (und übrigens als xen domU)

Wird wohl ungefähr alles zur ANGA (Ende Mai) auftauchen.

Zitat

Originally posted by Razorblade
@Mreimer: Kannst Du nochmal genau sagen welche Probleme Du mit dem (welchem genau) Patch hattest?

Sorry, dass ich deinen Beitrag erst so spät bemerke. Ich habe, wie schonmal geschrieben, selber keinen Netceiver und den beim Bekannten habe ich vor ca. einer Woche nach langem Kampf doch noch zum Laufen gebracht.

Was den Patch angeht: Das Problem ist, dass der neue Patch einfach davon ausgeht, dass mit Kernel 2.6.28 die Neuerungen im API gekommen sind. Der bei Slackware 12.2 verwendete Kernel 2.6.27.7 hat aber z.B. definitiv schon das neue API (dein Patch hat wunderbar funktioniert, der angepasste Patch versucht gegen das alte API zu kompilieren, welches nicht da ist). Zumindest das semaphore.h-Thema (anderer Ort der Header-Datei) ist auch schon für Kernel 2.6.26 dokumentiert. Kurz und knapp: Die bedingte Kompilierung arbeitet nicht feingranuliert genug. Wenn man es richtig machen will, müsste man die Kernel-Versionen vergleichen, um die bedingte Kompilierung so umzurüsten, dass auch wirklich da "umgeschaltet" wird, wo die entsprechenden Änderungen im Kernel auch gekommen sind.

Der Sinn nach einem Patch für ältere Kernel erschließt sich mir ohnehin nur bedingt, denn für alte Kernel sollte doch der offizielle Source tun?

Alles in allem freue ich mich auf das VDR-Plugin für den Netceiver, denn das dvbloop-Modul ist schon ein Problem für sich. Es ist nicht trivial zu kompilieren und wenn man es doch schafft, dann läuft es zumindest instabil (bei meinen Versuchen und nach zigfachem neuladen des Moduls bekam ich erst ein "Ooops" und dann kurz darauf einen Kernel Panic!).

Mein Patch hatte auch keine Abwärtskompatibilität, dafür hatte nano noch eine v2 released (evtl sollten wir mal den Link im Wiki auf seine Version angleichen).

Ich muß aber zugeben, daß ich es mit 2.6.27.7 nicht probiert habe, aber bei allen Kernelupdates seitdem funktioniert der Patch ohne Änderungen gegen die aktuellen v4l-dvb sourcen...

Die Instabilität des dvbloop Moduls kann ich definitiv nicht bestätigen, überprüf doch mal Du ein glibc Problem hast oder evtl unterschiedliche Kompiler für Kernel und Modul verwendest.
Achso... x86 oder x86_64? Wenn letzteres dann gibt es wohl noch ein paar Probleme...

Wir reden aneinander vorbei

Dein Patch geht eben weil er die Abwärtskompatibilität nicht drin hat!

Kernel 2.6.27.7 hat bereits das neue API, aber der Patch mit Abwärtskompatibilität schaltet erst bei 2.6.28 auf das neue API um...

Eben deshalb rate ich dringend davon ab im Wiki den Link zu ändern. Alte Kernel sollten mit dem offiziellen Source tun.

Hallo zusammen!

Das Konzept Netceiver/Client(s) ist ja wirklich genial!

Ich habe bisher im gesamten Thread aber leider noch nichts über "Umschaltzeiten" gefunden - gibt es da irgendwelche Informationen zu?
Sind diese Umschaltzeiten ähnlich kurz wie bei einem "Standard-VDR mit S(2) Karte"?

Hi,

die Umschaltzeiten sind minimal länger als mit einer DVBS-FF Karte.

Schätze so ca. 1 Sekunde.

Hätte nie gedacht das die Umschaltzeiten übers Netzwerk so kurz sind.

Im Vergleich zu einem Kathrein 910 ist der Netceiver klar schneller.

Ich nutze die Reelvdr Software und das Kontron Miniitxboard mit einem Core Duo T2400.
Der Netceiver (Dachboden) ist über einen Linksys SLM2008 angeschlossen.

MfG B-Tronic

"(bei meinen Versuchen und nach zigfachem neuladen des Moduls bekam ich erst ein "Ooops" und dann kurz darauf einen Kernel Panic!)"

Liegt nicht am dvbloop, sondern am DVB-Subsystem. Das ist nicht auf Hotplug ausgelegt. Es gibt da einige Race-Conditions beim Entfernen der Tunertreiber, die beim Entladen des Moduls zuschlagen können. Meistens trifft es nur den Frontend-Thread (der kdvb-fe-Prozess), manchmal aber noch etwas mehr... Man sollte generell Tunertreiber nur entladen, wenn das Device >5s nicht offen war. Dann beendet sich der Kernelthread von selbst.

Trotz aller Kompatibiliät von dvbloops mit DVBAPI-Apps ist das Hotplugproblem auch einer Gründe für ein vdr-PI. Damit können Tuner problemlos auch erst nach dem vdr-Start auftauchen und auch ebenso wieder verschwinden.

Zitat

Original von B-Tronic
Hi,

die Umschaltzeiten sind minimal länger als mit einer DVBS-FF Karte.

Schätze so ca. 1 Sekunde.

Hätte nie gedacht das die Umschaltzeiten übers Netzwerk so kurz sind.

Alles anzeigen

Wow - das klingt wirklich genial! Dann werde ich demnächst also wohl nur noch ein Netzwerkkabel zum Fernseher legen und spare mir die Sat-Kabel...

Hallo,

ich habe den NEtceiver jetzt in einer VM unter KVM installiert, die Netzwerkkarten sind virtio devices, trotzdem ist die Netzwerkperformance nicht unbedingt sehr gut.
In der VM benutze ich eine i386 System mit Ubuntu 9.04.
Die Verbindung funktioniert, aber es gibt halt viele Aussetzer.

Jetzt wollte ich das ganze mal auf dem Host, welcher ein Ubuntu 9.04 als amd64 System ist.
dort bekomme ich beim Versuch den MCLI zu starten folgende Meldung:

bash: ./mcli: No such file or directory

liegt das hier am 64bit System? oder fehlt mir noch irgendetwas?

Ich brauche auf dem Host aber amd64, da ich später mehr als 4GB Ram einbauen will, wg KVM Server

der 32bit mcli wird in einem "echten" 64-bit System nicht laufen. Mit Gefummel und doppelten Libraries könnte das aber wohl gehen.

Ich habe es zwar selbst nie probiert, aber angeblich ist >4GB RAM unter Linux 32-bit kein Thema.

Zitat

Original von der-brumm-baer
Hallo,

ich habe den NEtceiver jetzt in einer VM unter KVM installiert, die Netzwerkkarten sind virtio devices, trotzdem ist die Netzwerkperformance nicht unbedingt sehr gut.

Mit KVM habe ich es noch nicht probiert, aber mit Xen (PV) funktioniert das wunderbar, sowohl über die xenbridge als auch mit einer dedizierter NIC und PCI-Passthrough...

Hallo

Also bei mir gibt es lauter "TS Continuity Errors" über die KVM Bridges.
Der Netceiver hat eine eigene Intel Netzwerkkarte, die über eine Bridge an die Virtuelle MAschine Weitergegeben wird. Der Ausgang für VDR-Sxfe geht dann über eine weitere Brigde ins HausNetz.
Bei der Wiedergabe mittels vdr-sxfe an einem Clienten kommt es dann zum stocken und Bildaussetzern.

Wie kann ich denn so ein Mischsystem aufsetzen?
Oder kriegt man die Sourcen für mcli, um es dann auf dem amd64 System aufzuspielen, sofern das möglich ist.

Kann mir wer da ein paar Tritte in die richtige Richtung geben?

HI,

Zitat

TS Continuity Errors

Hört sich nach Treibern an... Ich hatte mit den Standardtreibern auch die Fehler, erst nachdem ich die neusten vom Hersteller kompiliert habe, ging es.

Ansonsten den EPG-Scan abschalten... unter VMWare Fusion (Mac) habe ich keine "TS Continuity Errors", daher glaub ich nicht dran, das die VM schuld sein soll

MFG
Kris

Die statisch gelinkte Variante aus http://www.baycom.de/download/…tools_static_20081113.tgz tut nicht?