[0.2 - gelöst] Netceiver wird erst nach VDR-Restart erkannt

yaGuru1968 · 1. September 2010

Hi,

ich habe das Problem, dass mein NetCeiver direkt aus dem Booten heraus nicht erkannt wird ('netcvdiag -a' zeigt 'count: 0' ; keine Kanäle funktionieren).
wenn ich nun (per Konsole/ssh) ein 'sudo stop vdr; sudo start vdr' aufrufe, dann funktioniert es...

Ich habe hier im Forum mal beim Posting-Zappen einen entsprechenden Beitrag dazu gelesen, aber ich finde den nicht mehr und die Suche danach ergibt auch nichts - mir fallen bald keine Keywörter mehr ein, nach denen ich noch suchen könnte

..in besagtem Posting ging es darum, den VDR-Start zu verzögern, bis mcli gestartet ist oder den mcli-start zu verzögern, bis xyz gestartet ist oder sowas in der Richtung; jedenfalls ging es dort um Timing-Abhängigkeiten beim Booten -- ich denke, dass genau dies die Lösung meines Problems wäre!
aber, wie Eingangs erwähnt: ich finde das besagte Posting nicht mehr :-((

kann mir hier bitte einer weiterhelfen?

Danke
yaGuru

steffen_b · 1. September 2010

Code

description     "let VDR wait for the network"
author          "Gerald Dachs <gda@dachsweb.de>"


start on starting vdr 


task


script 
  while DOSOMETHING ; do sleep 1 ; done
end script

Alles anzeigen

DOSOMETHING wäre halt irgendein code der dir sagt ob der netceiver fertig ist.

Ich vermute es reicht nicht einfach dass das netzwerk da ist oder ?

yaGuru1968 · 1. September 2010

ja, genau sowas in der Richtung war das!

ich habe keine Ahnnung, wer da auf was warten muss - das Problem ist auch "neu" bei mir, ursprünglich brauchte ich sowas nicht... aber jetzt scheint es nicht mehr ohne zu gehen!

Frage mich jetzt bitte nicht, warum so plötzlich - ausser ein paar mal "apt-get --reinstall install vdr-plugin-mcli" (da ich generell Probleme damit hatte - Ruckeln, nur wenige Kanäle wurden angezeigt, etc.) habe ich nämlich komplett die Finger vom System gelassen; Fast: im Bios bin ich noch mal auf "Load Failsafe Defaults" gegangen, weil die Kiste sich von selber aus heiterem Himmel ausgeschaltet hatte... ...einen neuen Lüfter musste ich einbauen... ...und den NetCeiver selber habe ich zwischendurch einmal re-bootet, aber sonst ehrlich nichts installiert/de-installiert...

ich weiss nicht, ob der VDR das Problem ist - ich denke eher, dass der mcli das Problem ist, also müsste das Starten des mcli verzögert werden, vermutlich bis das Netzwerk da ist, da könntest du schon recht haben...

Aber wie soll ich im DOSOMETHING überprüfen, ob der NetCeiver da ist?
"netcvdiag" funktioniert ja noch nicht (d.h. ohne gestarteten vdr-mit-mcli-plugin)?

vielleicht ein ping6 oder sowas??? hmmm... mal (ver)suchen...

p.s.
wo muss ich dieses Script einbauen?

steffen_b · 1. September 2010

Ich kenne netceiver nicht, ich dachte der netcvdiag initialisiert irgendwas. Oder kann zumindest irgendwie die Erreichbarkeit des netceivers bestätigen. Wenn du das damit kannst, sollte das ausreichen ein Konstrukt damit dort rein zu tun.

Kannst du schauen ob du so ein Konstrukt gebaut bekommst, oder erklären woran du sehen kannst ob der Netceiver im Netz erreichbar ist ?

Das obige wäre ein upstart script , also /etc/init/netceiver.conf zB

on starting vdr sagt aus : "Wenn vdr startet muss zuerst dieses gestartet sein, nur danach darf vdr starten"

gda · 1. September 2010

Zitat

Original von yaGuru1968
Aber wie soll ich im DOSOMETHING überprüfen, ob der NetCeiver da ist?
"netcvdiag" funktioniert ja noch nicht (d.h. ohne gestarteten vdr-mit-mcli-plugin)?

Ein externes Programm zur Diagnose, dass nur funktioniert wenn der VDR mit einem bestimmten Plugin läuft hört sich für mich ziemlich albern an. Die Quellen deuten auch in keiner Weise darauf hin, dass sich netcvdiag für den VDR interessiert. Für mich ist netcvdiag genau das DOSOMETHING was du brauchst.

Gerald

yaGuru1968 · 1. September 2010

allerdings funktioniert netcvdiag nur, wenn mcli läuft...

konkret:

"stop vdr" -> netcvdiag zeigt keinen NetCeiver an
"start vdr" -> netcvdiag zeigt ihn an

bin mir hier nicht so sicher, ob ich netcvdiag als DOSOMETHING verwenden könnte
(kann ich das mcli-plugin ohne VDR starten? falls ja, wie?)

vermutlich komme ich hier nur mit einem ping6 weiter, habe aber damit noch keine Erfahrung
-- ausserdem nicht ganz so flexibel, da ich auf die spezielle IPv6 Adresse des NetCeiver prüfen müsste ( also nix für den generellen Gebrauch... )

gda · 1. September 2010

Zitat

Original von yaGuru1968
allerdings funktioniert netcvdiag nur, wenn mcli läuft...

Das ist dann wirklich ein komisches Tool, es gibt aber auch noch den mcli-Daemon der unabhängig vom VDR läuft. Entweder man kann den direkt zu Erkennung verwenden, oder in Kombination mit dem netcvdiag.

Gerald

yaGuru1968 · 1. September 2010

diese mcli/dvbloop Daemons waren vor dem vdr-plugin-mcli notwendig für den NetCeiver Betrieb.

Die Frage ist nun, läuft das immer noch so (also mcli/dvbloop anstelle von vdr-plugin-mcli) oder darf ich diese Beiden nur zur Detektion des NetCeivers verwenden und muss sie danach killen (damit das plugin läuft), oder wie oder was?

Die eigentliche Frage ist aber (nach wie vor): wiese bedarf es eines VDR-Restarts, damit der NetCeiver erkannt wird und funktioniert?
- in den Logs ist mir auf den ersten BLick kein Fehler aufgefallen: dort steht, dass das mcli-plugin gestartet wurde, Versions-Nummer etc. - aber nicht mehr (keine gefundenen Tuner vom NetCeiver, keine Kanäle etc.) -- allerdings auch keine explizite Fehlermeldung

im "Gut-Fall" (also nach manuellem Restart) steht das auch genauso dort drinnen - allerdings noch zusätzlich, dass halt 4 Conexant Tuner (oder so) gefunden wurden (mit Versions-Nummer etc.) und die Kanäle etc.

Der Schlecht-Fall sieht einfach so aus, als ob der mcli zwar gestartet wird aber nicht funktioniert...

(ich kann ja nach Feierabend mal die relevanten Infos aus den beiden Fällen hier anhängen)

p.s.
zum netcvdiag: ich denke das ist einfach ein Tool zur Diagnose des gesamten Empfangspfads und nicht zur Analyse, ob ein NetCeiver vorhanden ist - sprich: es zeigt nur etwas an, wenn NetCeiver PLUS die ganzen zusätzlichen Software-Teile zusammen funktionieren...

gda · 1. September 2010

Zitat

Original von yaGuru1968
Die Frage ist nun, läuft das immer noch so (also mcli/dvbloop anstelle von vdr-plugin-mcli) oder darf ich diese Beiden nur zur Detektion des NetCeivers verwenden und muss sie danach killen (damit das plugin läuft), oder wie oder was?

Das ist doch jetzt dein Job das auszuprobieren.

Gerald

yaGuru1968 · 1. September 2010

hmm...

Ok - Herausforderung akzeptiert...

steffen_b · 1. September 2010

evtl manipuliert das plugin die Netzwerkeinstellungen und fangt das nicht ab, wenn keins da ist, also den VDR nach dem Netzwerk zu starten wäre euch noch ein Versuch wert. ( and net-device-up IFACE!=lo - hiermit würde kein restart gehen, aber du könntest die These testen ...) Oder jemand der den Code kennt, sagt uns die Requirements

kris · 1. September 2010

Hi,

Nur ganz kurz, da ich auf dem Sprung bin. Der netceiver bzw der vdr benötigt Netzwerk und ipv6. Ich vermute halt, das der vdr zu schnell startet, daher hilft ein stop/Start vdr

Ich würde also prüfen, ob vdr wirklich nach dem Netzwerk startet.

Die netcv tools brauchen tatsächlich einen funktionierenden vdr, da dieser quasi die die Schnittstelle darstellt.

MfG
Kris

yaGuru1968 · 2. September 2010

DANKE!

ich habe (innerhalb von /etc/init/vdr.conf) aus dem

Code

start on local-filesystems

Folgendes gemacht:

Code

start on (local-filesystems and net-device-up IFACE=eth0.2)

(der NetCeiver hängt an VLAN eth0.2)

damit funktioniert es jetzt direkt nach dem Booten!

(mit 'ner eigenen NetCeiver.conf habe ich auch gespielt, hat aber nicht funktioniert...

Code

script
until dmesg | grep 802.1Q VLAN ; do sleep 1 ; end
end script

-- ich dachte diese Meldung kommt erst, wenn das VLAN Interface up ist, kommt zeitlich jedenfalls nach dem "link up" des physikalischen Interfaces... evtl. doch noch zu früh?
)

jetzt muss ich mich doch noch mit Templates beschäftigen, damit das nach dem nächsten dist-upgrade auch noch drinnen ist

p.s.
ich habe allerdings immer noch das GROSSE Problem, dass meine Kiste einfach so aus heiterem Himmel einfach aus geht
-- aber dies soll ein anderer Thread sein (ich habe letztens so ziemlich alle LifeGuard Settings auskommentiert, weil er eigentlich NIE ausging wenn er sollte - nun geht er immer dann aus, wenn er WILL; wahrscheinlich so was wie die Rache vom LifeGuard...)

p.p.s.
die Zeit bis zur Anzeige des Frontends (bei mir XBMC) ist nun DEUTLICH länger - ich sehe sogar vorher noch das yaVDR Logo!
-- aber das wird wahrscheinlich am dhcp liegen; nächster Halt: statische IP-Adresse...

kris · 2. September 2010

Hi,

perfekt, ggf könnte man versuchen ein netceiver-template zu bauen, welches installiert wird, sobald vdr-plugin-mcli installiert wird.

es würde theoretisch auch reichen, zu warten bis eth0 da ist.

Was meinen die Entwickler?

MfG
Kris

steffen_b · 2. September 2010

Schon am Grübeln Müsste dann aber etwas allgemeingültiger gemacht werden. In dem Zusammenhang wäre es noch schön zu wissen ob

Anstatt IFACE=eth0.2 auch IFACE!=lo geht (ich würde vermuten ja)

gda · 2. September 2010

Da fragt sich ob man gerade beim Netceiver auch das WLAN ausklammern müsste.

Gerald

kris · 2. September 2010

Hi,

steffen_b
was spricht gegen eth0? Das ist i.V. mit dem Netceiver ein "must-have". Wie gda vermutet müsste WLAN rausgenommen werden. Wobei sich mir die Frage stellt, ob Wlan schneller starten soll als kabelgebundenes Lan. Ich glaube eher nicht.

Diejenigen die VLAN haben, kommen mit eth0 auch weiter, meiner Meinung nach zumindest.

yaGuru1968
Vielleicht könntet Du mal testen, ob es mit der Zeile

Code

start on (local-filesystems and net-device-up IFACE=eth0)

auch klappt.

gda
WLAN generell ausklammern macht keinen Sinn. Wer WLAN im gleichen IP-Netz wie den Netceiver betreibt muss ein VLAN haben.

MfG
Kris

gda · 2. September 2010

Zitat

Original von kris
was spricht gegen eth0? Das ist i.V. mit dem Netceiver ein "must-have".

Wieso kann es nicht eth1 sein? Was dagegen spricht wäre, dass wir den script auch für die hdhomerun verwenden wollen und bei der darf es eth1 sein.

Gerald

kris · 2. September 2010

Hi,

gda
es kann auch eth12 sein. Was ist hdhomerun?

Andersrum muss - wenn eine Nic anders als eth0 verwendet wird - ohnehin die plugin.mcli.conf angepaßt werden. Denn ich muss mcli mitteilen, wo es "horchen" soll.

Man könnte in der plugin.mcli.conf dann angeben, das ggf noch eine weitere Datei zwecks Sicherstellung der Netzwerkverfügbarkeit angepaßt werden soll.

Aber zugegeben, ab hier wird es schwierig, eine "template-für-alle-fälle" zu generieren.

Fassen wir das kurz zusammen.

Der Netceiver braucht, BEVOR der VDR gestartet ist, ein Netzwerk. Dies KANN ethX sein, oder aber ein VLAN-Y

Im Fall von VLAN-Y oder eth>0 MUSS ich die plugin.mcli.conf anpassen (im Fall VLAN muss ich sogar noch mehr machen, aber das sprengt den Rahmen).

Evtl reicht halt ein

Zitat

start on (local-filesystems and net-device-up)

also ohne angabe des inferfaces ja schon aus?

MfG
Kris

steffen_b · 3. September 2010

eth0 wäre sehr praktisch, weil es dann keinen seperat zu haltenden Status bräuchte.

Mal ein bischen upstart Theorie, falls es jemand interessiert. Könnte evtl verwirren ...

Also was müssen wir wissen ? Ob ein richtiges Netzwerkgerät oben ist. net-device-up sagt nur ein Netzwerkgerät ist grade hochgekommen , ohne IFACE kann das auch lo also das loopback device sein. Wenn es schon oben ist, kommt kein neuer event. Ein Neustart des VDR würde so hängen.

Also müssten wir uns den Status zwischenspeichern. Für einzelne Netzwerkgeräte passiert das schon. Wir können hierfür den upstart job network-interface benutzen. Wenn wir uns das selbst speichern wollen kann man auch upstart-jobs definieren die nichts tun (also OHNE exec und OHNE script .... end script) Diese kann man dann auf events starten und stoppen und erhält somit den status auch zwischen den events.

Wenn man sich auf ein Netzwerkgerät festlegt sollte folgender upstart job den start verzögern ohne das man die vdr.conf anfassen muss:

kris/yaGuru/Gerald das bitte mal probieren ob es geht:
/etc/init/network-dvb.conf

Code

description     "Block vdr starting, until network is done for network DVB device"
author          "Steffen Barszus <steffenbpunkt@gmail.com>"


start on (starting vdr and started network-interface INTERFACE=eth0)
stop on (stopped vdr or stopped network-interface INTERFACE=eth0)

Wenn man net-device-up IFACE!=lo benutzen will und einen eigenen Status müsste man halt noch einen job zusätzlich definieren.

Man lernt nie aus - So in die Richtung, stelle ich mir vor das wir es einbauen können. Jetzt muss mir nur noch jemand sagen: JA DAS GEHT. Alles andere will ich nicht hören

[0.2 - gelöst] Netceiver wird erst nach VDR-Restart erkannt

Jetzt mitmachen!

Teilen

Benutzer online in diesem Thema