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

Kurzer Nachtrag:

Nachdem ich das live plugin in der version 0.2.0 kompiliert habe und nutze treten die Abstürze bei hdtv-Aufnahmen nicht mehr auf!
Selbst die gleichzeitige Aufnahme von ARD/ZDF und ARTE HD läuft reibungslos und ohne den Server in irgendeiner Weise zu belasten - richtig klasse!

Hi,

Zitat von real_schorsch

Achje, geht das mit dem Tunertimeout hier auch schon los. Was der schon alles verursacht haben soll. Anscheinend war er auch an der Pleite Griechenlands schuld...

auch wenn Du es nicht hören magst, aber seit dem 3.7 habe ich die neue netceiver.conf mit dem erhötem Tunertimeout eingespielt und bis heute keine 0 byte Aufnahmen mehr. Sprich; alles i.O. (bei 18 Aufnahmen)

Zitat von real_schorsch

Nochmal auch hier: Im NetCeiver sind der Streamingteil und der Tunerteil getrennt (zwei getrennte Programme). Der Tunertimeout ist eine interne Sache des Tunerteils. Der Streamingteil verlangt nur eine bestimmte Frequenz, der Tunerteil kümmert sich um den Rest (Treiber, Diseqc, Rotor, ...). Ob da die Tuner im Powerdown sind oder nicht, ist völlig egal.

das wird mit sicherheit alles stimmen, aber zur zeit sieht es so aus, das BEI MIR ein Timeout von 5 Tagen dazu führt, das mein 24/7 Server alles aufnimmt was ich möchte ohne dabei sich auf 0byte zu beschränken.

Zitat von real_schorsch

Warum der 1.7.18 so ungern aufnimmt, weiss ich nicht. Aber evtl. passt da ein Patch für den vdr nicht mehr. Reines Tunen hilft auf dem NetCeiver nichts, man muss mindestens eine PID ziehen. D.h. wenn man davor schon auf den Lockstatus schaut und wartet, wird nie ein Lock kommen, Henne-Ei...

Das glaub ich so nicht, denn via Streamdev hatte ich immer ein Bild. Ich weiss natürlich nicht, ob der streamdev da irgendwas in der Richtung macht.

Rein Hypotethisch, was passiert wenn ich ein Tunertimeout von sagen wir 2 min habe und der VDR bleibt 10 min auf ein und denselben kanal, gibt das mcli-plugin an den Netceiver eine Meldung ala "hier guckt noch jemand"? Was ist, wenn aus irgendeinem Grund eben diese Meldung wegbleibt und der tuner einfach ausgeht...

Zitat von real_schorsch

Ich hab neulich auf meinem Notebook 11.04 installiert, ich schau mal, was da fehlt.

hattest du mal zeit gehabt zu schauen?

Alles verdammtes vodoo Zeug

MfG
KRis

Ist ja schön, aber der höhere Timeout dort löst das ursächliche Problem nicht. Und das ist, dass es so oder so evtl. länger als bei lokal angebundenen Tunern dauern kann, bin ein Lock da ist und Daten kommen. Ob die Tuner an oder aus sind, ändert nichts an deren Verfügbarkeit für den vdr selbst, also kann es nur was mit dem Zustand zu tun haben,,, Aber was jetzt da so "intelligent" ist, sehe ich im Code grad nicht...

> Das glaub ich so nicht, denn via Streamdev hatte ich immer ein Bild. Ich
> weiss natürlich nicht, ob der streamdev da irgendwas in der Richtung
> macht.

Die Auswahl der Tuner macht jede Datensenke selbst, von daher kann es da schon grosse Unterschiede geben.

> Rein Hypotethisch, was passiert wenn ich ein Tunertimeout von sagen wir 2
> min habe und der VDR bleibt 10 min auf ein und denselben kanal, gibt
> das mcli-plugin an den Netceiver eine Meldung ala "hier guckt noch
> jemand"? Was ist, wenn aus irgendeinem Grund eben diese Meldung
> wegbleibt und der tuner einfach ausgeht...

Das mcli-PI hat einen Timeout von 10 SEKUNDEN (!!!) für alle PID-Receiver, die keinen ganzen Service ziehen. Der vdr (und die diversen Plugins) gibt nämlich freiwillig (d.h. ohne Tunerknappheit) keine PIDs mehr her, wenn er mal den Tuner angefasst hat. Damit würden alle Tuner bis zum Abschalten belegt werden, und das nur für SI, EPG und so Kleinkram. Das würde die ganze Ressourcenverwaltung ruinieren.

Alle PIDs, die einem Service zugeordnet sind (also "Programme" fürs Schauen, Aufnehmen und Streamen) sorgen für einen regelmässigen Refresh aller abonierten Multicastgruppen übers Netz (d.h. alle ~10s geht per MLDv2 eine Liste aller gewünschten Transponder + deren PIDs raus). Damit haben die Multicastgruppen (MCG) für einen Transponder einen Usage Count !=0 im NetCeiver, daher läuft das Streaming der PIDs weiter. Im NetCeiver werden die MCG entweder aktiv über MLDv2 gelöscht (via DelPid() zB. beim Zappen) oder die Updates werden nicht mehr empfangen (Empfänger "verendet", spontan vom Netz gefallen, ...). Ohne Update gibts einen weiteren Timeout (auch 10s), der für jedes Empfänger<->MCG-Paar den MCG-Usage Count runterzählt. Ist er 0, will gar keiner mehr diese PID von dem Transponder haben und das Streaming dafür wird eingestellt (der NetCeiver streamt ja nur selektiv PIDs). Ist der Usage-Count für den Transponder insgesamt 0, fängt der Tuner Timeout an zu zählen.

Ist alles sehr schön zu sehen: Nimm netcvlogview (die NetCeiver-Logs werden auch per Multicast gesendet) und schau, was so passiert, wenn man den ganzen vdr "im Lauf" zB. per SIGSTOP oder Debugger anhält. Das triggert mangels MLD-Update die MCG-Timeouts, der Usage Count für den/die benutzten Tuner fällt sehr schnell auf 0. Wenn dann noch der Tuner Timeout kurz ist, wird kurze Zeit später BER auf "deaddead" gesetzt. Dann erst ist der Tuner (inkl. LNB-Versorgung) aus.

> hattest du mal zeit gehabt zu schauen?

Ja, Den DVB-register-Calls vom Kernel ist wieder mal ein neuer Parameter gewachsen. Leider hat C keine Default-Werte wie C++, damit würde das gar nicht auffallen. Compilieren tuts schon wieder, aber testen muss ich es noch.

Hi bezel,

habe deinen Post gesehen und würde dir bei deinem Problem gern behilflich sein.Um eine Schritt für Schritt Anleitung zu schreiben muss ich von dir wissen welche Netzwerkhardware du benutzt und wie du dein PC und den Netceiver angeschlossen hast.Ich kann dir schon mal soviel sagen das der Loopbacktreiber von Microsoft nicht nötig ist.Ich will ja nicht das deine Verzweifelung noch schlimmer wird.Wie soll das Howto sein für einen Laien oder für einen Nutzer der Grundlagen von Windows beherscht?
Sende deine Antwort bitte an guido.gratzke@web.de . Je nach Erfahrungsgrad kann das Howto größer werden und eventuell den üblichen Rahmen hier spengen. Es wird dann aber hier als Howto in PDF Format erscheinen sofern Interesse besteht.

mfg guigra

Hi,

Zitat

Ist alles sehr schön zu sehen: Nimm netcvlogview (die NetCeiver-Logs werden auch per Multicast gesendet) und schau, was so passiert, wenn man den ganzen vdr "im Lauf" zB. per SIGSTOP oder Debugger anhält. Das triggert mangels MLD-Update die MCG-Timeouts, der Usage Count für den/die benutzten Tuner fällt sehr schnell auf 0. Wenn dann noch der Tuner Timeout kurz ist, wird kurze Zeit später BER auf "deaddead" gesetzt. Dann erst ist der Tuner (inkl. LNB-Versorgung) aus.

werde ich mal machen, ich habe aber noch eine Frage dazu, villeicht hast Du Erfahrungswerte sammeln können. Der VDR läuft bei mir als user "vdr" gibt es ggf Einschränkungen vom Kernel? Bei ReelVDR meine ich läuft der vdr als root, vielleicht gibt es ja daher das problem nicht? Im Log sehe ich zwar keinen Hinweis drauf, muss man aber auch zwangsläufig ja nicht.

Ich könnte dem vdr ja mal spaßeshalber die uid und gid 0 verpassen

MfG
KRis

Sind die 0er-Aufnahmen von FTA-Sendern oder hängt da ein CAM dazwischen?

HI,

die 0 byte Aufnahmen bei mir kommen (kamen) überwiegend von FTA, ich nehme zzt selten von SKy oder ähnlichen auf. Ich habe übrigens keine Hardware-CAM

Was für Software-Voraussetzungen benötigt eigentlich dvbloop? Könnte man die notwendigen Softwarebestandteile "isolieren" und aus dem dvbloop ein dkms paket zaubern?

Ich weiß, die frage ist Saudämlich aber ich teste gerade openelec-pvr (XBMC als Linux-FIrmware verpackt) i.V. mit vdr-1.7.16 unter Ubuntu-Server 10.04 und habe dabei folgendes Scenario festgestellt:

Mcli-Plugin (r183) auf dem Server:
- ich kann via xbmc auf dem Server zugreifen, aber die Kanäle lassen sich sehr unwillig umschalten, dabei ist es egal ob FTA oder verschlüsselt, Abhilfe schafft das, mehrmals hin- und her zuschalten
- Die umschaltzeiten sind "schlimm", zwischen 2 und 5 sekunden dauert das ganze, kommt noch Pay-TV dazu, wird es "spannend".

dvbloop/mcli-dämon
- keines der oben genannten Probleme. Ich kann zappen bis die Batterie leer wird, dabei liegen die umschaltzeiten zwischen 1 und 3 sek. Auch das zappen innerhalb von HD+/SKy (über böses plugin) ist sehr angenehm (liegt, je nachdem ob HD oder SD zwischen 2 und 4 sek)

Ich lasse dabei dvbloop/mcli als root laufen.

Ich bin zzt mit der dvbloop/mcli Lösung sehr zufrieden, zudem kommt noch, das epgsearch mir nun nicht jedesmal mitteilt, das zuwenig Tuner zur Verfügung stehen (der kann mit dem mcli-plugin nichts anfangen). Da ich das ein- oder andere dkms gebastelt habe, würde ich es gerne mit einem dvbloop-dkms versuchen, aber ich habe von den C-Kram zu wenig ahnung und weiss nicht genau, welche Voraussetzung noch gegeben sein müssen.

MFg
Kris

Ich will auch wieder zurück auf dvbloop. Hatte mich schonmal versucht das ganze an aktuelle Kernel anzupassen, aber mit dem umbenennen von ein paar IOCTLs ist es diesmal nicht getan

Hi,

wer mal sein NetCeiver mit der aktuellen Reelversion /Ubuntu 10.04 testen möchte, dazu gibt es hier ein ISO für ein
USB-Stick. Nehme ich sehr gerne zur Hilfe, wenn es darum geht zu verstehen wie der NrtCeiver tickt.

Link:
http://www.easyvdr-forum.de/fo…12410.msg102373#msg102373

Einfach die Live-DVD installieren und nach dem nächsten reboot läuft der USB-Stick im VLAN2 Betrieb.
Kann man auch in der /etc/default/mcli umstellen.

Geht auch alles über eine Netzwerkkarte.

Vielleicht hilft es ja dem Einen oder Anderem.

Grüße
cinfo

Hallo Zusammen,

ich bin brandneu hier im Forum, aber ein jahrelanger Reel Anwender.

Inzwischen AVG mit externem Netceiver im Einsatz, nun wollte ich erstmal von einem Ubuntu10.04 Rechner über netcv2dvbip und vlc zugreifen.
Später dann auch mal über Windows PCs...

Ich komme soweit ( nach ifconfig lo multicast

Read 94 channels, M3U playlist file "channels.m3u" generated.
Looking for netceivers out there....

Found NetCeiver: fe80::208:54ff:fe56:e52c
Tuner: Philips TDA10023 DVB-C, Type 1
Tuner: Philips TDA10023 DVB-C, Type 1
Tuner: Philips TDA10023 DVB-C, Type 1

Listening on interface lo (127.0.0.1)

IGMP setsockopt(MRT_INIT): Address already in use
IGMPv2 won't work! Please enable multicast router option in the kernel configuration!
IGMP setsockopt(MRT_ADD_VIF): Address already in use
IGMP timeout handler thread started.
IGMP: Starting General Query.
IGMP main thread: Sleeping 31000 ms
IGMP listener thread started.
IGMP: SrcAddr: 192.168.0.13 -> DstAddr: 224.0.0.1
IGMP: Version: 3, Type: Membership Query, Maximum Response Time: 100
Group: 0.0.0.0

Die multicast router option sollte im kernel aber enabled sein...

Möglicherweise ist das eine Kleinigkeit, die in den 50 Seiten des Threads schon mal gefragt wurde, aber ich habe es zumindest nicht gefunden.

Vielen Dank für Eure Unterstützung...

Beste Grüsse
maier2505

UPDATE...

Nachdem ich in der /etc/sysctl.conf die Weiterleitung von IPv4 und IPv6 Paketen freigegeben habe, ist jetzt der Broadcastfehler beim Start weg, trotzdem noch immer kein Bild in VLC...:

root@maier2505-desktop:/reelbox# ./netcv2dvbip -i eth0.2
Interfaces (count = 3):
1 - lo : addr 127.0.0.1
2 - eth0 : addr 192.168.0.13
3 - eth0.2 : addr 10.0.0.1
Starting netcv2dvbip. Streams will be sent to port: 12345
1: udp://@239.255.0.1:12345 - Das Erste HD
2: udp://@239.255.0.2:12345 - ZDF HD
3: udp://@239.255.0.3:12345 - Bayerisches FS Süd
..
..
92: udp://@239.255.0.92:12345 - D 3 - 01:45
93: udp://@239.255.0.93:12345 - D 4 - 23:00
94: udp://@239.255.0.94:12345 - D 5 - 18:00
Read 94 channels, M3U playlist file "channels.m3u" generated.
Looking for netceivers out there....

Found NetCeiver: fe80::208:54ff:fe56:e52c
Tuner: Philips TDA10023 DVB-C, Type 1
Tuner: Philips TDA10023 DVB-C, Type 1
Tuner: Philips TDA10023 DVB-C, Type 1

Listening on interface lo (127.0.0.1)

IGMP timeout handler thread started.
IGMP: Starting General Query.
IGMP main thread: Sleeping 31000 ms
IGMP listener thread started.
IGMP: SrcAddr: 192.168.0.13 -> DstAddr: 224.0.0.1
IGMP: Version: 3, Type: Membership Query, Maximum Response Time: 100
Group: 0.0.0.0
IGMP: SrcAddr: 192.168.0.13 -> DstAddr: 224.0.0.22
IGMP: Version: 3, Type: Membership Report, Number of Records: 2
---> Record No: 1, Type: 4, Number of Sources: 0
Group: 224.0.0.2
---> Record No: 2, Type: 4, Number of Sources: 0
Group: 224.0.0.22
IGMP: SrcAddr: 192.168.0.13 -> DstAddr: 224.0.0.22
IGMP: Version: 3, Type: Membership Report, Number of Records: 2
---> Record No: 1, Type: 4, Number of Sources: 0
Group: 224.0.0.2
---> Record No: 2, Type: 4, Number of Sources: 0
Group: 224.0.0.22
IGMP: SrcAddr: 192.168.0.13 -> DstAddr: 224.0.0.22
IGMP: Version: 3, Type: Membership Report, Number of Records: 2
---> Record No: 1, Type: 2, Number of Sources: 0
Group: 224.0.0.2
---> Record No: 2, Type: 2, Number of Sources: 0
Group: 224.0.0.22
IGMP: Starting General Query.
IGMP main thread: Sleeping 31000 ms
IGMP: SrcAddr: 192.168.0.13 -> DstAddr: 224.0.0.1
IGMP: Version: 3, Type: Membership Query, Maximum Response Time: 100
Group: 0.0.0.0
IGMP: SrcAddr: 192.168.0.13 -> DstAddr: 224.0.0.22
IGMP: Version: 3, Type: Membership Report, Number of Records: 2
---> Record No: 1, Type: 2, Number of Sources: 0
Group: 224.0.0.2
---> Record No: 2, Type: 2, Number of Sources: 0
Group: 224.0.0.22

Ich habe eine VLAN Schnittstelle eth0.2 angelegt und der die IP10.0.0.1 eingegeben.netcv2dvbip iwrd dann mit -i eth0.2 gestartet.

Hier die Ausgaben von ifconfig für die drei Schnittstellen:

maier2505@maier2505-desktop:/reelbox$ ifconfig lo
lo Link encap:Lokale Schleife
inet Adresse:127.0.0.1 Maske:255.0.0.0
inet6-Adresse: ::1/128 Gültigkeitsbereich:Maschine
UP LOOPBACK RUNNING MULTICAST MTU:16436 Metrik:1
RX packets:26 errors:0 dropped:0 overruns:0 frame:0
TX packets:26 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:0
RX bytes:1296 (1.2 KB) TX bytes:1296 (1.2 KB)

maier2505@maier2505-desktop:/reelbox$ ifconfig eth0
eth0 Link encap:Ethernet Hardware Adresse 00:0c:6e:ba:aa:10
inet Adresse:192.168.0.13 Bcast:192.168.0.255 Maske:255.255.255.0
inet6-Adresse: fe80::20c:6eff:feba:aa10/64 Gültigkeitsbereich:Verbindung
UP BROADCAST RUNNING MULTICAST MTU:1500 Metrik:1
RX packets:374344 errors:0 dropped:0 overruns:0 frame:0
TX packets:776 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:1000
RX bytes:103622088 (103.6 MB) TX bytes:113652 (113.6 KB)
Interrupt:17

maier2505@maier2505-desktop:/reelbox$ ifconfig eth0.2
eth0.2 Link encap:Ethernet Hardware Adresse 00:0c:6e:ba:aa:10
inet Adresse:10.0.0.1 Bcast:10.255.255.255 Maske:255.0.0.0
inet6-Adresse: fe80::20c:6eff:feba:aa10/64 Gültigkeitsbereich:Verbindung
UP BROADCAST RUNNING MULTICAST MTU:1500 Metrik:1
RX packets:361277 errors:0 dropped:0 overruns:0 frame:0
TX packets:393 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:0
RX bytes:93484875 (93.4 MB) TX bytes:56545 (56.5 KB)

maier2505@maier2505-desktop:/reelbox$

Mache ich da immer noch etwas falsch ?

vlc starte ich dann mit

vlc channels.m3u

MfG

maier2505

Hi,

ich versuche meinen Netceveier auch mit anderer Software( mythtv und VLC )einzusetzten.
Da nützt mir ein Plugin für den VDR reichlich wenig. (Ich weiß hier ist das VDR-Portal und der VDR ist Klasse).

Ich brauch halt den DVBloop.

Als real_schorsch schrieb:

Zitat von real_schorsch

> hattest du mal zeit gehabt zu schauen?

Ja, Den DVB-register-Calls vom Kernel ist wieder mal ein neuer Parameter gewachsen. Leider hat C keine Default-Werte wie C++, damit würde das gar nicht auffallen. Compilieren tuts schon wieder, aber testen muss ich es noch.

War ich völlig aus dem Häuchsen.

Reel schreibt auf der Web-Seite zum Netceiver ja auch:

Unterstützte Client-Betriebssysteme
»Linux Kernel 2.6.22 oder höher

x86-kompatibel Netzwerkeigenschaften

Streaming-Client-Software » z.B. VDR, MythTV, Kaffeine, VLC Media Player, M-Player

Was ist jetzt mit 2.6.38 und auch du Schreck demnächst 3.0

@reel_schorsch

bitte melde dich

Es ist einige Zeit her als ich das letzte Mal mit dem Netceiver zu tun hatte.

Wenn ich den Source des Plugins via SVN bei Baycom auschecke fehlt mir ein Makefile. Wo und wie bekomme ich den kompletten Source?

Nachtrag: War ein Fehler meinerseits. Funktioniert jetzt. Allerdings funktioniert das Kompilieren jetzt wohl etwas anders. Musste einiges an meinen Build-Scripten ändern...

netc2bip heisst das zauberwort

Hi,

Moorviper
hier kosten Buchstaben keinen cent extra ;), das Tool heißt wohl netcv2dvbip aber was hat netcv2dvbip mit einem dvb-kompatiblen gerät zu tun? netcv2dvbip streamt bzw wandelt doch "nur" ts -pakte zu ipv4 ? Müsste man da nicht sowas wie Playlisten erstellen? Macht ja nicht viel spaß

MFG
KRis

ja ja das V 2x vergessen Im deutschunterricht wurde das aber immer nur 1 mal gewertet (Wiederhohlungsfehler)

Ne man braucht nur ne channels.conf und das teil baut dann ne .m3u
die man dann mit dem vlc öffnen kann

deswegen --> unterstützung mplayer vlc und so weiter ...

die können ja auch mit dvbloop nicht darauf zugreifen (vlc bin ich mir sicher (mplayer lasse ich mich eines besseren belehren ) )

Zitat von Moorviper

ja ja das V 2x vergessen Im deutschunterricht wurde das aber immer nur 1 mal gewertet (Wiederhohlungsfehler)

Ne man braucht nur ne channels.conf und das teil baut dann ne .m3u
die man dann mit dem vlc öffnen kann

deswegen --> unterstützung mplayer vlc und so weiter ...

die können ja auch mit dvbloop nicht darauf zugreifen (vlc bin ich mir sicher (mplayer lasse ich mich eines besseren belehren ) )

Alles anzeigen

Hallo moorviper,

nachdem Du Dich ja scheinbar mit netcv2dvbip auskennst, ich hatte ein paar Threads weiter relativ verzweifelt meine Probleme geschildert.

Irgendwelche verwertbaren Tips ?

Beste Grüsse

maier2505

maier2505:

Ich habe den selben Tuner. Bei DVB-C gibt es noch ein Problem, ich bin gerade dabei einen Patch zu schreiben und an den Entwickler zu schicken. Sollte also in nicht allzu langer Zeit auch im SVN sein. Eventuell betrifft das auch DVB-T Tuner, aber genau kann ich das nicht sagen.

Grüße

Smiler ist deine Änderung schon im SVN?

Gruß
compi

Ja, in Revision 188 ist die Änderung eingepflegt. Eventuell kann das Problem noch mit DVB-T auftreten. Falls da jemand Probleme hat und das testen kann bitte PN an mich