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

Zitat

Original von Nano
BTW: Hat mal jemand einen Namensvorschlag fuer das Teil? netcv2iptv? ncv2iptv? dvbiptv?

netcv2dvbip

Bin schon sehr gespannt und werde testen sobald Du das Tool für Linux rausgibst.

Zitat

Original von real_schorsch
GET_TS_PACKETS ist eine Optimierung im vdr-core, die es erlaubt, mehrere TS-Packete auf einmal in das vdr-System zu stopfen. Das reduziert die Last bei höheren Datenraten durchaus. Warum du das Flag im mcli anschalten musst, verstehe ich nicht ganz. Ohne das define wird jedes Paket einzeln kopiert.

Ich habe den Patch mal etwas angepasst (siehe unten). Sozusagen die "minimalinvasive" Version, die *nichts* zusätzlich anschaltet. Änderung ist lediglich, dass ich die bedingte Kompilierung so verbogen habe, dass die Funktion nicht ganz ausgeklammert, sondern nur der Inhalt nicht kompiliert wird. Die Funktion ist so *definiert* und VDR, bzw. das zugrundeliegende Linux-System ist zufrieden.

Ziel war es, das Plugin mit den Voreinstellungen von Reel bauen zu können, da ich mit dem Plugin Probleme habe. Dazu aber später mehr.

Zitat

Wenn du wirklich nur einen Tuner angeschlossen hast (Loop-Through ist böse, das weiss der NetCeiver nicht und kann damit bei Bandwechseln auf die Nase fallen), solltest du den anderen in der netceiver.conf ausschalten (preference auf -1).

Das wird nicht mein System, sondern das eines Kollegen. Wenn der PC irgendwann mal fertig wird, dann läuft der nicht bei mir und am neuen "Tätigkeitsbereich" werden alle Tuner benötigt. Ich will nicht ständig umkonfigurieren. Für Testzwecke scheint das mit dem Brücken ganz gut zu gehen.

So, jetzt aber weiter im Text. Plugin kompiliert und läuft augenscheinlich sauber.

Wenn ich jetzt aber das osdteletext-Plugin aktiviere (es reicht vollkommen, wenn das Plugin auch nur mitgestartet wird), dann hängt sich der VDR nach einer gewissen Laufzeit mit einem "Segmentation Fault" auf.

Die Ursache scheint eindeutig das mcli-Plugin zu sein, denn wenn ich selbiges abstelle und eine DVB-Karte in den Rechner stecke, dann tritt das Problem nicht auf.

Ich wäre dankbar, wenn sich real_schorsch dazu mal äußern könnte. Ich kann zwar ein bisschen C und C++, aber um diesen Fehler in einem mir fremden Sourcecode zu finden, reicht es leider nicht. Zumal ich mich in der DVB-Thematik nicht auskenne.

Gibt es schon eine neuere Version des mcli-Plugins (größer 0.1)?

So allmählich bin ich auf jedem Fall mit meinem Latein am Ende. Mit mcli-Daemon und diesem dvbloop-Modul hat das CAM nicht funktioniert. Mit dem Plugin hängt sich jetzt der VDR auf...

Zitat

Original von real_schorsch
GET_TS_PACKETS ist eine Optimierung im vdr-core, die es erlaubt, mehrere TS-Packete auf einmal in das vdr-System zu stopfen. Das reduziert die Last bei höheren Datenraten durchaus.

Macht das auch bei Benutzung von mcli-binary Sinn (also nicht mit Plugin)?
Ich habe nämlich speziell auf Sky HD massive Probleme (ich schätze wegen der hohen Datenrate):

Sep 12 18:52:56 vdrfront1 vdr: [3388] buffer usage: 70% (tid=3387)
Sep 12 18:52:56 vdrfront1 vdr: [3388] buffer usage: 80% (tid=3387)
Sep 12 18:52:56 vdrfront1 vdr: [3388] buffer usage: 90% (tid=3387)
Sep 12 18:52:57 vdrfront1 vdr: [3388] buffer usage: 100% (tid=3387)
Sep 12 18:52:58 vdrfront1 vdr: [3388] ERROR: driver buffer overflow on device 1
Sep 12 18:52:59 vdrfront1 vdr: [3387] ERROR: skipped 1038068 bytes to sync on TS packet on device 1
Sep 12 18:52:59 vdrfront1 vdr: [3388] buffer usage: 40% (tid=3387)
Sep 12 18:52:59 vdrfront1 vdr: [3387] ERROR: skipped 859615 bytes to sync on TS packet on device 1
Sep 12 18:52:59 vdrfront1 vdr: [3387] TS continuity error (13)
Sep 12 18:52:59 vdrfront1 vdr: [2939] read incomplete section - len = 637, r = 95

Wegen des osdteletext-Plugins habe ich jetzt mal selber mit gdb versucht, ein bisschen mehr herauszufinden:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb165cb90 (LWP 7418)]
0xb7db123f in memcpy () from /lib/libc.so.6
(gdb) bt
#0  0xb7db123f in memcpy () from /lib/libc.so.6
#1  0x080f28cc in cFrame (this=0xaca00fb0, Data=0xb3878f0c "G@i\021", Count=248, Type=ftUnknown, Index=-1, Pts=0)
    at ringbuffer.c:349
#2  0xb7befbdc in cTxtReceiver::Receive (this=0x85eefe8, Data=0xb3878f0c "G@i\021", Length=188) at txtrecv.c:593
#3  0x0809d5e8 in cDevice::Action (this=0x85f0350) at device.c:1478
#4  0x0810eba0 in cThread::StartThread (Thread=0x85f0350) at thread.c:257
#5  0xb806b310 in start_thread () from /lib/libpthread.so.0
#6  0xb7e1abee in clone () from /lib/libc.so.6
(gdb) frame 2
#2  0xb7befbdc in cTxtReceiver::Receive (this=0x85eefe8, Data=0xb3878f0c "G@i\021", Length=188) at txtrecv.c:593
593        cFrame *frame=new cFrame(Data, len);
Current language:  auto; currently c++
(gdb) frame 1
#1  0x080f28cc in cFrame (this=0xaca00fb0, Data=0xb3878f0c "G@i\021", Count=248, Type=ftUnknown, Index=-1, Pts=0)
    at ringbuffer.c:349
349             memcpy(data, Data, count);
(gdb)

"txtrecv.c" ist Bestandteil von osdteletext und "ringbuffer.c" ist Bestandteil von VDR selbst.

Der VDR hängt sich erst nach einer Laufzeit von knapp einer Minute auf. Ich habe mir während der gesamten Laufzeit einmal dieses "Length" ausgeben lassen: Es ist immer bei "188".

Da in der "ringbuffer.c" für die übergebene Menge "Count" an Bytes (In unserem Fall 248 ) immer eine passende Menge Speicher freimacht, dürfte es im "memcpy" wohl kaum wegen eines zu kleinen Zielbuffers crashen. Auch dann, wenn der Quellbuffer zu klein ist, dürfte nichts crashen. Es sei denn, der Quellbuffer liegt so, dass Speicher gelesen werden soll, auf die der Prozess kein Zugriff hat.

Problem tritt, wie schon gesagt, nicht mit einer Tunerkarte im VDR auf. An irgendeiner Stelle wird vom mcli-Plugin wohl ein zu kleiner Buffer generiert (kleiner als 188 Bytes) aber dann doch eine Größe von 188 dafür festgelegt. Wo das aber ist, kann ich nicht herausfinden.

Ja, der osdteletext zickt bei uns auch rum. ABER NUR DER...

Da schein auch irgendwas an der Linear-Ringbuffern vom vdr komisch zu sein (Schuld abwälz ). Mit denen als TS-Buffer im mcli gabs immer ganz abstruse Effekte, mit der paket-basierten Implementierung aus dem Reel-remux.c war auf einmal alles weg. Wirklich erklärbar ist das (noch) nicht. So magisch ist der Code im mcli, der das transferiert, auch nicht...

Hi,

ich habe mal versucht das mcli Plugin mit dem Patch zu erstellen, leider erhalte ich folgenden Fehler unter dem VDR 1.70 S2API

make[1]: Leaving directory `/opt/easyvdr/vdrvv/src/vdr-1.7.0-0/PLUGINS/src/mcli-0.1/mcast/client'
g++ -g -O2 -Wall -Woverloaded-virtual -Wno-parentheses -fPIC -c -DUSE_ANALOGTV -DUSE_ATSC -DUSE_CHANNELSCAN -DUSE_CMDRECCMDI18N -DUSE_CMDSUBMENU -DUSE_CUTTERLIMIT -DUSE_CUTTERQUEUE -DUSE_CUTTIME -DUSE_DDEPGENTRY -DUSE_DELTIMESHIFTREC -DUSE_DOLBYINREC -DUSE_DVBSETUP -DUSE_DVDARCHIVE -DUSE_DVLRECSCRIPTADDON -DUSE_DVLVIDPREFER -DUSE_DVLFRIENDLYFNAMES -DUSE_EM84XX -DUSE_GOTOX -DUSE_GRAPHTFT -DUSE_HARDLINKCUTTER -DUSE_JUMPPLAY -DUSE_LIEMIEXT -DUSE_LIRCSETTINGS -DUSE_LIVEBUFFER -DUSE_LNBSHARE -DUSE_MAINMENUHOOKS -DUSE_SETUP -DUSE_NOEPG -DUSE_OSDMAXITEMS -DUSE_PARENTALRATING -DUSE_PINPLUGIN -DUSE_PLUGINMISSING -DUSE_PLUGINPARAM -DUSE_ROTOR -DUSE_SETTIME -DUSE_SOFTOSD -DUSE_SOURCECAPS -DUSE_SORTRECORDS -DUSE_STREAMDEVEXT -DUSE_TIMERCMD -DUSE_TIMERINFO -DUSE_TTXTSUBS -DUSE_VALIDINPUT -DUSE_VOLCTRL -DUSE_WAREAGLEICON -DUSE_YAEPG -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"mcli"' -DCLIENT -I/usr/local/src/DVB/linux/include -I../../../include -I. `xml2-config --cflags` mcli.c
g++ -g -O2 -Wall -Woverloaded-virtual -Wno-parentheses -fPIC -c -DUSE_ANALOGTV -DUSE_ATSC -DUSE_CHANNELSCAN -DUSE_CMDRECCMDI18N -DUSE_CMDSUBMENU -DUSE_CUTTERLIMIT -DUSE_CUTTERQUEUE -DUSE_CUTTIME -DUSE_DDEPGENTRY -DUSE_DELTIMESHIFTREC -DUSE_DOLBYINREC -DUSE_DVBSETUP -DUSE_DVDARCHIVE -DUSE_DVLRECSCRIPTADDON -DUSE_DVLVIDPREFER -DUSE_DVLFRIENDLYFNAMES -DUSE_EM84XX -DUSE_GOTOX -DUSE_GRAPHTFT -DUSE_HARDLINKCUTTER -DUSE_JUMPPLAY -DUSE_LIEMIEXT -DUSE_LIRCSETTINGS -DUSE_LIVEBUFFER -DUSE_LNBSHARE -DUSE_MAINMENUHOOKS -DUSE_SETUP -DUSE_NOEPG -DUSE_OSDMAXITEMS -DUSE_PARENTALRATING -DUSE_PINPLUGIN -DUSE_PLUGINMISSING -DUSE_PLUGINPARAM -DUSE_ROTOR -DUSE_SETTIME -DUSE_SOFTOSD -DUSE_SOURCECAPS -DUSE_SORTRECORDS -DUSE_STREAMDEVEXT -DUSE_TIMERCMD -DUSE_TIMERINFO -DUSE_TTXTSUBS -DUSE_VALIDINPUT -DUSE_VOLCTRL -DUSE_WAREAGLEICON -DUSE_YAEPG -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"mcli"' -DCLIENT -I/usr/local/src/DVB/linux/include -I../../../include -I. `xml2-config --cflags` cam_menu.c
cam_menu.c: In member function 'int cCamMenu::CamFind(cam_list_t*)':
cam_menu.c:144: error: call of overloaded 'cOsdItem(char [128], eOSState, int)' is ambiguous
../../../include/vdr/osdbase.h:70: note: candidates are: cOsdItem::cOsdItem(const char*, eOSState, cSubMenuNode*)
../../../include/vdr/osdbase.h:68: note:                 cOsdItem::cOsdItem(const char*, eOSState, bool)
make: *** [cam_menu.o] Fehler 1

Kann jemand helfen?

Grüße
cinfo

Zitat

Original von cinfo
Hi,

ich habe mal versucht das mcli Plugin mit dem Patch zu erstellen, leider erhalte ich folgenden Fehler unter dem VDR 1.70 S2API

Ich habe nur mit VDR 1.7.9 getestet. 1.7.0 ist doch schon recht angestaubt

Die Patches, die das Plugin selber mitliefert, hast du (von dem 1.4er Patch abgesehen) alle angewendet?

Was das Problem mit dem osdteletext-Plugin angeht: Eigentlich will ich den VDR schon noch diese Woche fertig bekommen. Also habe ich mir ein paar Stunden Zeit genommen und noch etwas debuggt.

Möglicherweise liegt das Problem im osdteletext selbst. Hier wurde wohl beim teletext-Plugin an der falschen Stelle gespickt. Im Teletext-Plugin (nicht *osd*teletext!) wird ein Buffer erzeugt, der 60 Bytes größer als der in der "Receive"-Funktion übergebene ist. Dann wird der größere Buffer komplett genullt und der kleinere in den größeren Buffer kopiert.

Das osdteletext-Plugin dagegen addiert pauschal 60 Bytes zur vom VDR übergebenen Länge hinzu und nutzt das dann um ein "cFrame" damit zu bauen. Solange der Buffer, den der VDR übergeben hat, tatsächlich mindestens 60 Bytes größer ist, als angegeben, klappt alles. Im Zusammenhang mit dem mcli-Plugin tritt es aber auf, dass der Buffer schonmal *genau* die angegebene Länge hat. Der Konstruktor der "cFrame"-Klasse liest also über die Buffer-Grenze hinweg --> Segmentation Fault.

Mein Patch entfernt dieses "+ 60" gänzlich. Ergebnis ist, dass das osdteletext-Plugin mit dem mcli-Plugin funktioniert. Ein Test mit einem Tuner direkt im VDR ist auch erfolgreich verlaufen, wobei es mir so vorgekommen ist, als würden die Teletext-Seiten etwas langsamer gefunden als sonst. Kann aber auch Einbildung sein. Wäre schön, wenn ein Profi einmal etwas zu diesen ominösen 60 zusätzlichen Bytes sagen könnte...

Hi,

Zitat

Ich habe nur mit VDR 1.7.9 getestet. 1.7.0 ist doch schon recht angestaubt

Ja stimmt, aber ich setzte eine Reel eHD Ausgabekarte ein und leider kann man hier nicht nachblieben den VDR wechseln, weil dann wieder andere Reel Plugins nicht laufen.

Zitat

Die Patches, die das Plugin selber mitliefert, hast du (von dem 1.4er Patch abgesehen) alle angewendet?

Ja, versucht aber in welcher Reihenfolge gehen die Patches durch?

Ich ernte da nur Fehler am VDR 1.7.0 S2API. Ich habe es dann gelassen, da die Patches ja für den VDR 1.60 bzw. 1.4 waren. Auch mit "reelvdr-device-handling-patch.diff" hatte ich kein Erfolg.

patching file device.c
Hunk #1 FAILED at 270.
Hunk #2 FAILED at 295.
Hunk #3 succeeded at 343 (offset 16 lines).
Hunk #4 succeeded at 357 (offset 16 lines).
Hunk #5 FAILED at 390.
Hunk #6 succeeded at 652 (offset 226 lines).
Hunk #7 succeeded at 869 with fuzz 1 (offset 137 lines).
Hunk #8 FAILED at 908.
4 out of 8 hunks FAILED -- saving rejects to file device.c.rej
patching file device.h
Hunk #1 FAILED at 326.
1 out of 1 hunk FAILED -- saving rejects to file device.h.rej
patching file sections.c
Reversed (or previously applied) patch detected!  Assume -R? [n] mc
Apply anyway? [n] ^C

Hat es schonmal jemand an einem VDR 1.70 extp72 S2API geschaft die Patches aus dem MCLI Plugin zu installieren und in welcher Reihenfolge?

Grüße
cinfo

Hi,

Zitat

Gibt es schon eine neuere Version des mcli-Plugins (größer 0.1)?

mir ist aufgefallen das der Patch für das mcli Plugin bei der
Version /testing/.../mcli-0.1.0 ohne Fehler durch läuft aber bei der aktuellen Version vom mcli Plugin in /testing/.../vdr-mcli-plugin erfolgen diese Fehler.

patching file device.c
Hunk #1 FAILED at 402.
1 out of 1 hunk FAILED -- saving rejects to file device.c.rej

device.c.rej

*************** bool cMcliDevice::GetTSPacket (uchar * &
*** 402,421 ****
  		return false;
  	}
  //      printf("GetTSPacket\n");
  	Data = m_TSB->Get ();
  	return true;
  }
- #ifdef GET_TS_PACKETS
  int cMcliDevice::GetTSPackets(uchar *Data, int count) {
   if (!m_enable || !m_dvr_open) {
    return false;
   }
   return m_TSB->Get (Data, count);
- } // cMcliDevice::GetTSPackets
  #endif

  int cMcliDevice::OpenFilter (u_short Pid, u_char Tid, u_char Mask)
  {
  	if (!m_enable) {
  		return -1;
  	}
--- 402,421 ----
  		return false;
  	}
  //      printf("GetTSPacket\n");
  	Data = m_TSB->Get ();
  	return true;
  }
  int cMcliDevice::GetTSPackets(uchar *Data, int count) {
+ #ifdef GET_TS_PACKETS
   if (!m_enable || !m_dvr_open) {
    return false;
   }
   return m_TSB->Get (Data, count);
  #endif
+ } // cMcliDevice::GetTSPackets

  int cMcliDevice::OpenFilter (u_short Pid, u_char Tid, u_char Mask)
  {
  	if (!m_enable) {
  		return -1;
  	}

Für welche Version ist denn für nun der Patch gedacht die mcli-0.1 [alte] oder vdr-mcli-plugin [neue] Version?

Grüße
cinfo

Was für eine "aktuelle Version" denn? Ich kenne nur mcli-0.1. Das ist, was mir real_schorsch geschrieben hat.

Sorry, aber deine gekürzten svn-Pfade helfen mir da garnicht. Auf dem Reel-SVN zu suchen ist aufgrund dessen Komplexität ein einziger Krampf.

Nachtrag: Ich habe jetzt mal ein

svn ls -R svn://reelbox.org/ | grep vdr-mcli

abgesetzt und gewartet. Ergebnis: Keine Treffer.

Hi,

ja ist schon komisch einzeln bekomme ich es auch nicht ausgecheckt

z.B. mit

svn co svn://reelbox.org/testing/src/vdr-plugins/src/vdr-mcli-plugin/

Aber wenn man den gesamten Tree auscheckt dann ist es dabei

svn co svn://reelbox.org/testing/src/vdr-plugins/src/

Grüße
cinfo

cinfo
läuft eigentlich der doppel dvb-s2 tuner stabil und in ordnung

Zitat

Original von cinfo
Hi,

ja ist schon komisch einzeln bekomme ich es auch nicht ausgecheckt

Wenn sich an der Stelle bitte mal real_schorsch einschalten könnte, um das Problem zu klären...

Muss ich mir wohl ein paar Stunden Zeit nehmen, um zumindest diesen Bereich komplett auszuchecken. Dann werde ich zumindest mal ein Diff zwischen dem mcli-0.1 und diesem angeblich "neueren Plugin" machen.

Was den Doppel DVB-S2-Tuner angeht: Ich habe das Teil bereitliegen, aber noch ist die Firmware im Netceiver nicht aktuell genug. Auch ist die Ausgabe im Moment noch nicht wirklich HD-fähig.

Hi,

Zitat

aber noch ist die Firmware im Netceiver nicht aktuell genug. Auch ist die Ausgabe im Moment noch nicht wirklich HD-fähig.

Ich verwende die Firmware _99E und hiermit ist schon ein gutes HD z.B Arte möglich.

Grüße
cinfo

> Wenn sich an der Stelle bitte mal real_schorsch einschalten könnte, um das Problem zu klären...

Das mcli-PI kommt per Link aus einen externen Repository von BayCom und ist daher nicht direkt unter dem Pfad im RMM-SVN zugreifbar. Es sollte reichen, .../vdr-plugins/src/ auszuchecken oder man nimmt den direkten Link https://svn.baycom.de/repos/vdr-mcli-plugin

> Ich habe das Teil bereitliegen, aber noch ist die Firmware im Netceiver nicht aktuell genug.

Doch, ist sie. Sollte einer der beiden Tuner nicht erkannt werden, ist das ein HW-Problem, das leider erst mit der Massenproduktion aufgetreten ist, d.h. einschicken/umtauschen und gut.

Zitat

Original von real_schorsch
Das mcli-PI kommt per Link aus einen externen Repository von BayCom und ist daher nicht direkt unter dem Pfad im RMM-SVN zugreifbar. Es sollte reichen, .../vdr-plugins/src/ auszuchecken oder man nimmt den direkten Link https://svn.baycom.de/repos/vdr-mcli-plugin

Danke für den Tipp! Also werde ich direkt von baycom.de runterladen.

Eine Frage noch an die Allgemeinheit: Braucht es für den mcli-Daemon zwingend ein dvbloop-Modul, auch wenn man den mcli Daemon nur nutzen will, um darüber die neue Firmware in den Netceiver zu bekommen?

> Braucht es für den mcli-Daemon zwingend ein dvbloop-Modu

AFAIK startet der mcli nicht ohne, habs aber noch nie probiert...

> um darüber die neue Firmware in den Netceiver zu bekommen?

Du kannst auch ohne Daemon per -i direkt die IPv6-Adresse angeben. Das ist der Wust, der immer unter "UUID" aufgeführt wird. Die UUID ändert sich normalerweise auch nicht...

real_schorsch:
Ich muss nochmal nachfragen. Wie weit sind nun eigentlich die Änderungen am CAM-Handling fortgeschritten?
Weil besonders für grundverschlüsselungsgeplagte DVB-C-User wäre mit eigenem CAM-Handling der Netceiver die Ideallösung. Man bräuchte ja nur noch ein CAM im Netceiver.
Bisher ist das total nervig, weil man in jedem VDR und pro Karte jeweils ein CAM braucht.
Wenn der Netceiver die CAMs selbst handeln würde und dann schon einen decodierten Datenstrom liefern würde, das wäre absolut ideal. Dann hätte das Drama damit ein Ende.

Naja, im testing ist es schon. Es gibt noch ein paar Problemchen mit komischen CAMs (zB. Omegacrypt) und ab und zu (insb. bei DD-Ton) scheint die PID verloren zu gehen bzw. nicht dekodiert zu werden. Es braucht noch etwas gutes Zureden...