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

notaclue · 23. Februar 2013

Mit yaVDR 0.4 ging DVB Loop noch - auf dem 3er Kernel (yaVDR 0.5) gibt es noch keine Lösung - und da Reel aller Voraussicht nach nix mehr liefern wird, ist der Netceiver leider auf dem absteigenden Ast.

Die Ersatzlösung wird bei mir wohl Sundtek USB DVBS2 mit Pogoplug (da warte ich aber noch auf Erfahrungsberichte) oder mein Backend wandert unters Dach, direkt mit Sundtek Sticks bestückt...

Ich kenne zwei ehemalige Netceiver Nutzer (mit DVBLOOP), die bereits auf die Sundtek Lösung umgestiegen sind - und dort geht's dann auch wieder problemlos mit dem Plugin.

Moorviper · 23. Februar 2013

naja ich bin zb nicht wegen des bösen plugins zu den sundtek sticks gewechselt ( das andere böse plugin geht ja auch so mit dem vdr)
und es gibt ja patche für yavdr 0.5
das böse was er benutzen will ist halt schneller
(gut dvbloop ist auch um längen schneller als das mcli plugin (vom zappen her))

M-Reimer · 24. Februar 2013

Problem ist, dass mit dem mcli-Plugin, selbst wenn gepatcht, auf einem aktuellen VDR das CAM im Netceiver nicht funktioniert.

Via Cardreader geht auch nicht. Zumindest nicht mit aktuellem VDR, bzw. aktuellem Kernel.

Wer PayTV nutzen will kann demnach mit den Netceiver, sofern er nicht bei alter Software bleiben will, nichts mehr anfangen.

Auf Fixes oder Anpassungen von Reel oder von Baycom braucht man wohl nicht mehr hoffen.

Ist halt etwas ärgerlich, weil ein Bekannter von mir viel vom Konzept des Netceivers gehalten hat. Andererseits versuche ich jetzt aber schon seit Jahren den Netceiver bei ihm zum Laufen zu kriegen. Zufriedenstellend hat die Kiste nie funktioniert. Das Ding ist schon die ganze Zeit der Bremsklotz, der verhindert, dass mein Bekannter einen zuverlässigen VDR zur Verfügung hat.

Die Lösung wird in meinem Fall aber sein, dass ich meinem Bekannten nahelege eine CineS2 anzuschaffen. Die wird dann direkt auf 4 Tuner aufgerüstet. Vom Streamen über Netz habe ich persönlich nie viel gehalten und wenn jetzt der Netceiver abgeschrieben wird, dann kommt etwas her das 100%ig zuverlässig ist!

Halt schade um das Geld, das der Netceiver inklusive 3 DVB-S2 Doppeltuner gekostet hat.

Fawkes512 · 9. April 2013

Zitat von Moorviper

hm ist schon komisch

Code

./netcvdiag -a
Count: 1
NetCeiver 0:
  UUID , ALIVE, tuners 2
  OS <2.4.32-uc0>, App <0.99.33>, FW , HW <0055>
  Serial <33c6000001fe42b1>, Vendor , state 0
  SystemUptime 2943, ProcessUptime 2930
  TunerTimeout 0
  CI-Slot 0: State , Mode , CAPMT-Flag: 0, SIDs 0/4, CAM <>
  CI-Slot 1: State , Mode , CAPMT-Flag: 0, SIDs 0/4, CAM <>
  Tuner 0: ,  SatList: , Preference 0
  Tuner 1: ,  SatList: , Preference 0


NetCeiver 0: SatList , entries 3
  Satname: , Position <19.2E>, entries 4
    Entry 0: Polarisation V, Min 10700, Max 11700, LOF  9750 MINI_A   TONE_OFF VOLTAGE_13 DiSEqC 
    Entry 1: Polarisation V, Min 11701, Max 13000, LOF 10600 MINI_A   TONE_ON  VOLTAGE_13 DiSEqC 
    Entry 2: Polarisation H, Min 10700, Max 11700, LOF  9750 MINI_A   TONE_OFF VOLTAGE_18 DiSEqC 
    Entry 3: Polarisation H, Min 11701, Max 13000, LOF 10600 MINI_A   TONE_ON  VOLTAGE_18 DiSEqC 
  Satname: , Position <13.0E>, entries 4
    Entry 0: Polarisation V, Min 10700, Max 11700, LOF  9750 MINI_B   TONE_OFF VOLTAGE_13 DiSEqC 
    Entry 1: Polarisation V, Min 11701, Max 13000, LOF 10600 MINI_B   TONE_ON  VOLTAGE_13 DiSEqC 
    Entry 2: Polarisation H, Min 10700, Max 11700, LOF  9750 MINI_B   TONE_OFF VOLTAGE_18 DiSEqC 
    Entry 3: Polarisation H, Min 11701, Max 13000, LOF 10600 MINI_B   TONE_ON  VOLTAGE_18 DiSEqC 
  Satname: , Position <28.2E>, entries 4
    Entry 0: Polarisation V, Min 10700, Max 11700, LOF  9750 MINI_A   TONE_OFF VOLTAGE_13 DiSEqC 
    Entry 1: Polarisation V, Min 11701, Max 13000, LOF 10600 MINI_A   TONE_ON  VOLTAGE_13 DiSEqC 
    Entry 2: Polarisation H, Min 10700, Max 11700, LOF  9750 MINI_A   TONE_OFF VOLTAGE_18 DiSEqC 
    Entry 3: Polarisation H, Min 11701, Max 13000, LOF 10600 MINI_A   TONE_ON  VOLTAGE_18 DiSEqC 


UUID :
      slot 1.0, type DVB-S2, used:  10
      LOCK   , frequency 12544000kHz (1946.6MHz), position <19.2E>
      strength eb80, snr bb74, ber 0000, unc 0000
      NIMCurrent 87
      RotorStatus 0, RotorDiff 0.0
UUID :
      slot 2.0, type DVB-S2, used:   5
      LOCK   , frequency 11797000kHz (1199.5MHz), position <19.2E>
      strength e180, snr acec, ber 0000, unc 0000
      NIMCurrent 112
      RotorStatus 0, RotorDiff 0.0

Alles anzeigen

Code

./netcvupdate -l
fe80::208:54ff:fe54:db26    AVR0037/FPGAB66

trotzdem erkennt er die Tuner nur als dvb-s Tuner

Code

Dec 16 23:46:22 va-api vdr: [4123] VDR version 1.7.22 started
Dec 16 23:46:22 va-api vdr: [4123] codeset is 'UTF-8' - known
Dec 16 23:46:22 va-api vdr: [4123] found 28 locales in ./locale
Dec 16 23:46:22 va-api vdr: [4123] loading plugin: ./PLUGINS/lib/libvdr-streamdev-server.so.1.7.22
Dec 16 23:46:22 va-api vdr: [4123] loading /video/setup.conf
Dec 16 23:46:22 va-api vdr: [4123] loading /video/sources.conf
Dec 16 23:46:22 va-api vdr: [4123] loading /video/channels.conf
Dec 16 23:46:22 va-api vdr: [4123] loading /video/timers.conf
Dec 16 23:46:22 va-api vdr: [4123] loading /video/svdrphosts.conf
Dec 16 23:46:22 va-api vdr: [4123] reading EPG data from /video/epg.data
Dec 16 23:46:22 va-api vdr: [4124] video directory scanner thread started (pid=4123, tid=4124)
Dec 16 23:46:22 va-api vdr: [4124] video directory scanner thread ended (pid=4123, tid=4124)
Dec 16 23:46:22 va-api vdr: [4125] video directory scanner thread started (pid=4123, tid=4125)
Dec 16 23:46:22 va-api vdr: [4125] video directory scanner thread ended (pid=4123, tid=4125)
Dec 16 23:46:22 va-api vdr: [4123] registered source parameters for 'A - ATSC'
Dec 16 23:46:22 va-api vdr: [4123] registered source parameters for 'C - DVB-C'
Dec 16 23:46:22 va-api vdr: [4123] registered source parameters for 'S - DVB-S'
Dec 16 23:46:22 va-api vdr: [4123] registered source parameters for 'T - DVB-T'
Dec 16 23:46:22 va-api vdr: [4123] probing /dev/dvb/adapter0/frontend0
Dec 16 23:46:22 va-api vdr: [4123] creating cDvbDevice
Dec 16 23:46:22 va-api vdr: [4123] new device number 1
Dec 16 23:46:22 va-api vdr: [4123] cTimeMs: using monotonic clock (resolution is 1 ns)
Dec 16 23:46:22 va-api vdr: [4123] frontend 0/0 provides DVB-S with QPSK ("Conexant CX24116 DVB-S2")
Dec 16 23:46:22 va-api vdr: [4123] probing /dev/dvb/adapter1/frontend0
Dec 16 23:46:22 va-api vdr: [4123] creating cDvbDevice
Dec 16 23:46:22 va-api vdr: [4123] new device number 2
Dec 16 23:46:22 va-api vdr: [4123] frontend 1/0 provides DVB-S with QPSK ("Conexant CX24116 DVB-S2")
Dec 16 23:46:22 va-api vdr: [4131] CI adapter on device 1 thread started (pid=4123, tid=4131)
Dec 16 23:46:22 va-api vdr: [4132] tuner on frontend 1/0 thread started (pid=4123, tid=4132)
Dec 16 23:46:22 va-api vdr: [4123] found 2 DVB devices
Dec 16 23:46:22 va-api vdr: [4129] section handler thread started (pid=4123, tid=4129)
Dec 16 23:46:22 va-api vdr: [4133] section handler thread started (pid=4123, tid=4133)
Dec 16 23:46:22 va-api vdr: [4128] tuner on frontend 0/0 thread started (pid=4123, tid=4128)
Dec 16 23:46:22 va-api vdr: [4127] CI adapter on device 0 thread started (pid=4123, tid=4127)
Dec 16 23:46:22 va-api vdr: [4123] initializing plugin: streamdev-server (0.5.1-git): VDR Streaming Server
Dec 16 23:46:22 va-api vdr: [4123] setting primary device to 1
Dec 16 23:46:22 va-api vdr: [4123] device 1 has no MPEG decoder
Dec 16 23:46:22 va-api vdr: [4123] assuming manual start of VDR
Dec 16 23:46:22 va-api vdr: [4123] SVDRP listening on port 6419
Dec 16 23:46:22 va-api vdr: [4123] setting current skin to "sttng"
Dec 16 23:46:22 va-api vdr: [4123] loading /video/themes/sttng-default.theme
Dec 16 23:46:22 va-api vdr: [4123] starting plugin: streamdev-server
Dec 16 23:46:22 va-api vdr: [4123] loading /video/plugins/streamdev-server/streamdevhosts.conf
Dec 16 23:46:22 va-api vdr: [4123] remote control KBD - learning keys
Dec 16 23:46:22 va-api vdr: [4135] KBD remote control thread started (pid=4123, tid=4135)
Dec 16 23:46:22 va-api vdr: [4134] streamdev server thread started (pid=4123, tid=4134)
Dec 16 23:46:22 va-api vdr: [4134] Streamdev: Listening (VTP) on port 2004
Dec 16 23:46:22 va-api vdr: [4134] Streamdev: Listening (HTTP) on port 3000
Dec 16 23:46:22 va-api vdr: [4123] ERROR: no OSD provider available - using dummy OSD!
Dec 16 23:46:24 va-api vdr: [4131] CAM 2: no module present
Dec 16 23:46:24 va-api vdr: [4127] CAM 1: no module present
Dec 16 23:46:29 va-api vdr: [4134] Streamdev: Accepted new client (HTTP) 192.168.1.10:53774
Dec 16 23:46:29 va-api vdr: [4141] receiver on device 2 thread started (pid=4123, tid=4141)
Dec 16 23:46:29 va-api vdr: [4140] streamdev-livestreaming thread started (pid=4123, tid=4140)
Dec 16 23:46:29 va-api vdr: [4138] streamdev-writer thread started (pid=4123, tid=4138)
Dec 16 23:46:29 va-api vdr: [4142] TS buffer on device 2 thread started (pid=4123, tid=4142)
Dec 16 23:46:32 va-api vdr: [4123] switching to channel 1
Dec 16 23:46:32 va-api vdr: [4123] OSD size changed to 720x480 @ 1
Dec 16 23:46:32 va-api vdr: [4123] ERROR: no OSD provider available - using dummy OSD!

Alles anzeigen

Genau das Problem hab ich nun mit einem Debian Wheezy (Kernel 3.2.0-4-amd64)
Wie hast du das Problem gelöst? Ich würde nun nämlich gerne auf vdr-2.0.0 umsteigen

dvbloop konnte sogar recht einfach kompiliert werden
siehe https://pastee.org/j6sep

hidalgo · 9. April 2013

Zitat von Fawkes512

dvbloop konnte sogar recht einfach kompiliert werden
siehe https://pastee.org/j6sep

Bin genau gemäss Anleitung vorgegangen. Leider erhalte ich bei Schritt 13 eine Fehlermeldung:

Code

root@myVDR:/usr/src/dvbloop# modprobe dvbloop
FATAL: Module dvbloop not found.

gda · 9. April 2013

Zitat von hidalgo

Bin genau gemäss Anleitung vorgegangen. Leider erhalte ich bei Schritt 13 eine Fehlermeldung:
FATAL: Module dvbloop not found.

Na ja, die Zeile 10 der Anleitung ist fragwürdig. Der Wildcard kann in die Hose gehen wenn mehr als ein Kernel existiert. Nimm lieber den exakten Pfad.
Generell wäre aber ein DKMS-Paket hilfreicher.

Gerald

hidalgo · 9. April 2013

Vielen Dank für den Hinweis. Hatte ich natürlich gemacht. Hätte ich wohl erwähnen sollen.

Es hätte mich aber sowieso erstaunt, wenn es geklappt hätte. An anderer Stelle wurde ja immer wieder darauf hingewiesen, dass sich dvbloop nicht kompilieren lässt. Ich hatte zwar keine Fehlermeldung bei Schritt 10 (auch mit exaktem Pfad) erhalten. Aber hat wohl trotzdem nicht geklappt.

Fawkes512 · 9. April 2013

Zitat von hidalgo

Vielen Dank für den Hinweis. Hatte ich natürlich gemacht. Hätte ich wohl erwähnen sollen.

Es hätte mich aber sowieso erstaunt, wenn es geklappt hätte. An anderer Stelle wurde ja immer wieder darauf hingewiesen, dass sich dvbloop nicht kompilieren lässt. Ich hatte zwar keine Fehlermeldung bei Schritt 10 (auch mit exaktem Pfad) erhalten. Aber hat wohl trotzdem nicht geklappt.

joa hab auch noch n fehler drinnen sorry
das ist natürlich nur passend für ne frisch installierte kiste
https://pastee.org/6fx27
~~so tuts dann auch, zumindest für SD TV (böses Plugin tut auch!)~~
Es tut solange bist man die box bootet, dann raucht sie mit nem kernel crash weg.
ich werde mal den vor 2 seiten genannten patch probieren morgen

hidalgo · 10. April 2013

Zitat von Fawkes512

Es tut solange bist man die box bootet, dann raucht sie mit nem kernel crash weg.
ich werde mal den vor 2 seiten genannten patch probieren morgen

Dann bin ich ja froh, dass ich keine Lust hatte, das schon auszuprobieren.

Moorviper · 10. April 2013

Zitat

Genau das Problem hab ich nun mit einem Debian Wheezy (Kernel 3.2.0-4-amd64)
Wie hast du das Problem gelöst? Ich würde nun nämlich gerne auf vdr-2.0.0 umsteigen

Ich hab den Netceiver verkauft
da ich auch probleme mit meiner gbit verkabelung hatte

mittlerweile geht die aber jetzt isses eh rum

guigra · 6. Mai 2013

Hallo Leute,

möchte mich heute mal wieder zu Wort melden.

ich konnte unter Ubuntu mit dem Kernel 3.2.0 dvbloop nach der Anleitung auf pastee.org/6fx72 kompilieren.Allerdings ging das unter 3.5.0.y nicht mehr.Da wurden plötzlich Fehler angezeigt die unter vorherigne gcc Versionen überhaupt kein Problem waren.Es gab plötzlich Meldungen wie 'parameter has incomplete type' in der dvblo_adap.h oder in der dvblo_ adap_fe.c Fehler wie 'compilation error: request for member in something not a structure or union' und noch etliche andere.Haben die Entwickler des gcc's die Regeln so stark verändert das das nicht mehr geht?
Sieht so aus als müsste das dvbloop neu programmiert werden weil mcli und z .B netcv2dvbip ohne probleme auch unter 3.5.0.y bauen.Ausserdem besitze ich ein Miniboard das Raspberry Pi.Dies ist zwar eine ARM11 Plattform und als BS Raspbian aber auch da ist mit der Kernelversion 3.6.y Schluß mit dvbloop aber mcli und netcv2dvbip kompilieren und laufen auch hier tadellos und ich kann ohne Probleme TV sehen( Netcv2dvbip + omxplayer da der die Hardwarebeschleunigung des Boards nutzt).Es gehen sowohl HD Kanäle als auch SD.SD aber nur mit gekaufter MPEG2 Lizenz.

Moorviper :schade zu lesen das du deinen Netcveiver verkauft hast .

mfg guigra

adidaszh · 26. August 2013

Ich bin nach wie vor ein Fan der Netceiver Lösung. Es gibt aus meiner Sicht kein Sinnvolleres Konzept um das DVB Signal von 6 Tunern im Haus zu verteilen. Dass das Konzept eigentlich gut ist, zeigt die kommerzielle Lösung von Astra: SAT>IP. Leider ist das nicht wirklich eine alternative zum Netceiver, da die Lösung von Astra nicht Opensource ist, mit DRM vollgestopft und keine Lösung für das zentrale Entschlüsseln von Programmen geboten wird. Hier muss man wieder bei jedem Endgerät eine Abokarte haben.

Ich habe zu dem Thema Kernel 3.5.0 mal Baycom angeschrieben, ob da eine Anpassung zu erwarten ist. Ich hoffe, dass hier bald ein Update erfolgt. Es wäre schön, wenn der Netceiver eine Zukunft hat und dieser vielleicht nach dem teilweise Untergang von Reel Multimedia weiter geöffnet wird, so dass das Interesse wieder grösser wird.

Ich selbst würde es gerne sehen, wenn der Netceiver für die aktuellen Kernel Versionen ready ist und dass man dieses auch an das Projekt TVHeadend ran kriegt. So könnte man diesen problemlos in eine XBMC bzw OpenElec Umgebung einbinden - mit oder ohne PLEX Server.

HoppaZ · 20. September 2013

adidaszh

Aktuell läuft es... einen fork des plugins findest du nun unter:

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

Gruß,

Lars

Moorviper · 20. September 2013

ich glaube adidaszh beint die dvbloop + mcli binary combo

wegen der lösung rmm mit dem vdr plugin/ und ein paar anderen habe ich meinen netceiver verkauft

über dvbloop ging das böse plugin / würden jetzt beide bösen plugins gehen
und auch andere softwares häten was davon -> tvheadend mythtv und co

M-Reimer · 20. September 2013

Irgendwas war mit dem Netceiver eigentlich immer und die Umschaltzeiten sind auch nie an eingebaute Tuner rangekommen. Eine zusätzliche Zwischenschicht über "dvbloop" macht das nicht besser.

hsteinhaus · 20. September 2013

Das das böse Plugin mit mcli nicht geht, m.E. liegt weder am Netceiver noch am mcli-Plugn. Der VDR bietet eine saubere Schnittstelle, um alles mögliche mit dem DVB-Gerät zu machen. Das böse Plugin (und einige andere auch) umgeht diese Schnittstelle und macht stattdessen wilde ioctls auf irgendwelche /dev/dvb/-Dateien. Portables und sauberes Programmieren funktioniert jedenfalls anders. Wie dem auch sei, Abhilfe ist hier sicher mit wenig Aufwand machbar. Es muss sich halt mal jemand hinsetzen und die ganzen ioctls auf die cDevice-Methoden umbiegen. Hier sind aber die Nutzer des bösen Plugins gefragt..

Zum Netceiver selbst: einer meiner Netceiver hat gerade eine Uptime von 407 Tagen, und vor gut einem Jahr hat es hier heftig gewittert mit folgendem Stromausfall. Ich möchte den Streamdev-Server-VDR mit eingebauten Karten sehen, der nur 1% davon ohne Ausfall, Neustart, Segfault oder ählichem schafft.

Bei den Umschaltzeiten bin ich als Nutzer in einem großen System mit vielen Clients wahrscheinlich etwas verwöhnt, da die Standard-Transponder ohne Retuning quasi immer laufen. So sehe ich üblicherweise eine Umschaltzeit von deutlich unter 1s, zumindest seit ich softhddevice einsetze. Beim echten Retuning dauert es auch mal 2 Sekunden, länger habe ich soweit ich mich erinnere noch nie gehabt (mcli-Plugin, yavdr 0.5). Richtig langsames Tuning ist nach meiner Erfahrung ein direkter Hinweis auf eine falsch konfigurierte maximale Tunerzahl in den Optionen des Plugins.

Grüße
Holger

gda · 21. September 2013

Zitat von hsteinhaus

Zum Netceiver selbst: einer meiner Netceiver hat gerade eine Uptime von 407 Tagen, und vor gut einem Jahr hat es hier heftig gewittert mit folgendem Stromausfall. Ich möchte den Streamdev-Server-VDR mit eingebauten Karten sehen, der nur 1% davon ohne Ausfall, Neustart, Segfault oder ählichem schafft.

Ich wusste gar nicht, dass auf dem Netciever ein VDR läuft? Ich denke er ist eher mit meiner Dockstar und den Sundteks vergleichbar, die ich remote mounte. Bevor ich die Dockstar nun gerade heute wegen updates neu gebootet habe, hätte sie mit der Uptime locker mithalten können.

Gerald

kris · 21. September 2013

Hi,

seh ich ähnlich mit der Uptime, mein Dachboden-PC hält ewig durch, mit 4xDVB-S Sticks.

Es kommt halt auf dem "Fummel-Faktor" an, wenn Du nichts damit machst, was soll schon groß passieren? Auf meinem Dachboden-PC werkelt übrigens seit einiger Zeit Yavdr-0.5, der kann "ein bisschen" mehr als der Netceiver und man hat nicht so ein hantier damit.

MfG
Kris

cinfo · 22. September 2013

Hi,

Zitat

Das das böse Plugin mit mcli nicht geht,

Hmm, geht doch die Quellen sind doch offen gelegt.

Grüße
cinfo

Razorblade · 12. Oktober 2013

Mich hat es jetzt auch erwischt, auf meinem NAS läuft Kernel 3.4.6 und dvbloop kompiliert nicht mehr, das mcli-plugin läuft auch nicht wirklich auf Anhieb (eigentlich würde ich auch lieber bei dvbloop bleiben)

Habe mir die Probleme mal angeguckt, lau Doku https://git.kernel.org/cgit/li….xml?id=refs/tags/v3.4.65 wurde im Kernel von den alten ioctls "dvb_frontend_parameters" auf "FE_GET_PROPERTY/FE_SET_PROPERTY" umgestellt. Das müßte man nun an den Stellen nachziehen, an denen dvbloop die alten ioctl's benutzt. Hört sich erstmal leicht an, schließlich mußten das ja alle DVB Frontend Treiber auch ändern, wenn man sich die Diffs ansieht sind das auch nur triviale Änderungen, allerdings benutzt dvbloop diese ioctl etwas exzessiv, insbesondere für die Interfaces zwischen Kernel- und Userspace. Dafür finde ich naturgemäß keine Beispiele in den anderen DVB Treibern, weil die sowas natürlich nicht machen...

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

Jetzt mitmachen!

Teilen