war ein Fehler der aber ab dem 6.5 gefixt ist.prodigy7 hat geschrieben: ich hab mal das NFS-Recording getestet und siehe da, ich habs einmal hinbekommen ....
cu,
peter




Helfen kann ich zwar nicht, aber ... wie kommt man eigentlich an so ein Log?tHec@ hat geschrieben:... machmal kommt man sich wirklich vor, als wäre man nicht existent.
Deswegen nochmal:
Hat keiner hier ne Ahnung, was diese Fehlermeldung verursacht?
Wie kann man den betreffenden Buffer auf den benötigten Wert vergrößern?
--------schnipp----------------------
[controld] VIDEO_EVENT_SIZE_CHANGED 480x576 (16:9 -> 4:3)
Record channel_id: 200850029 epg: 20085002964f3, apids mode 1
[CBasicClient] receive failed: /tmp/zapit.sock
[CBasicClient] receive failed: /tmp/zapit.sock
avia_gt_dmx: queue 0 overflow (count:
PANIC: not enough space in ringbuffer, available 55659, needed 80640
nfs: server 192.168.0.4 not responding, timed out
--------schnapp-----------------------
Hoffe immer noch auf Hilfe...

Im Dbox-Bootmanager die serielle Konsole aktivieren und in der Dbox deine Ausgaben unter Einstellungen-> Diverse Einstellungen->Expert-Bootkonsole auf seriell stellen. Serielles Nullmodem-Kabel muß natürlich mit der Dbox verbunden werden.Helfen kann ich zwar nicht, aber ... wie kommt man eigentlich an so ein Log?
 
   
  
 
   
  

Ähem ... ich will ja nichts sagen, aber hast Du eigentlich diesen Thread mal gelesen? Diese Fehlermeldung hatte ich auf Seite 5 in diesem Thread schon erwähnt ("# PANIC: not enough space in ringbuffer, available 55471, needed 80641"). Gerade das ist ja das Problem. Hast Du mal wie vorgeschlagen TrueGrid angetestet? TrueGrid läßt sich IMO recht schnell und einfach einrichten. Hast Du evtl. eine Personal Firewall auf dem System, wo der NFS-Server läuft? Oder - falls XP - die interne Firewall aktiviert? Das könnte auch derartige Effekte hervorrufen. Mit OmniNFS hatte ich völlig merkwürdige Effekte, Dateien ließen sich selbst auf lokal gemountete Exports nur schwerlich kopieren usw.tHec@ hat geschrieben:... machmal kommt man sich wirklich vor, als wäre man nicht existent.
Deswegen nochmal:
Hat keiner hier ne Ahnung, was diese Fehlermeldung verursacht?
Wie kann man den betreffenden Buffer auf den benötigten Wert vergrößern?
--------schnipp----------------------
[controld] VIDEO_EVENT_SIZE_CHANGED 480x576 (16:9 -> 4:3)
Record channel_id: 200850029 epg: 20085002964f3, apids mode 1
[CBasicClient] receive failed: /tmp/zapit.sock
[CBasicClient] receive failed: /tmp/zapit.sock
avia_gt_dmx: queue 0 overflow (count:
PANIC: not enough space in ringbuffer, available 55659, needed 80640
nfs: server 192.168.0.4 not responding, timed out
--------schnapp-----------------------
Hoffe immer noch auf Hilfe...
Gruß
Thomas

Tattergreis hat geschrieben: Dann hab ich mit verschieden wsize-Größen auf meinem recht schwachen Linux-Server gespielt. 8192 scheint der optimale Wert zu sein, mit kleineren Werten bricht der Stream noch viel früher ab. Auf meinen P1 166 MHz unter Linux läßt sich aber definitiv nicht erfolgreich streamen, hab auch mal verschiedene Parameter des NFS-Servers getestet (u. a. sync, nosync, ... Thx an thegoodguy). Die Mühle ist aber wohl zu schlapp. Ich denke auch, das ist der Haken an der ganzen Sache. Wenn der NFS-Server mal etwas hakt bricht sofort der Stream ab.

 Es gibt ja noch einige FLI4L-User hier im Forum, evtl. nützt es dem ein oder anderen ja: Mein NFS-Problem auf dem FLI4L-System ist gelöst.
 Es gibt ja noch einige FLI4L-User hier im Forum, evtl. nützt es dem ein oder anderen ja: Mein NFS-Problem auf dem FLI4L-System ist gelöst.   Es lag an den Binaries, die im Opt-Paket enthalten waren. Mit diesen erzeugte der nfsd-Prozess eine zu hohe CPU-Last, um erfolgreich Streamen zu können. Ich habe deshalb die Binaries aus dem Eisfair-NFSD-Paket genommen und in den FLI4L gebaut. Hiermit liegt die Last des nfsd-Prozesses beim Direct Recording bei ca. 5% (P1 166 MHz) ggü. vorher 70%. Für die, die vom gleichen Problem geplagt sind hilft also Binaries tauschen. Ich hab aber auch ein Opt-Paket geschnürt, das die Binaries schon enthält: opt_nfsd.zip
 Es lag an den Binaries, die im Opt-Paket enthalten waren. Mit diesen erzeugte der nfsd-Prozess eine zu hohe CPU-Last, um erfolgreich Streamen zu können. Ich habe deshalb die Binaries aus dem Eisfair-NFSD-Paket genommen und in den FLI4L gebaut. Hiermit liegt die Last des nfsd-Prozesses beim Direct Recording bei ca. 5% (P1 166 MHz) ggü. vorher 70%. Für die, die vom gleichen Problem geplagt sind hilft also Binaries tauschen. Ich hab aber auch ein Opt-Paket geschnürt, das die Binaries schon enthält: opt_nfsd.zip 
 
P.S. FLI4L unterliegt einer Dateigrößenbeschränkung von max. 2 GB, daher Splitten nicht vergessen.
 
 



Code: Alles auswählen
.
PANIC: not enough space in ringbuffer, available 55659, needed 80640 
nfs: server 192.168.0.4 not responding, timed out 
.


schon klar und ich denke tHec wird auch nicht gluecklich mit dem neuen Schuss, wenn er sein Netzwerk nicht in Ordnung bringt.gagga hat geschrieben:Ringpuffer vergrößern bringt nix, wenn das Netzwerk bzw. der NFS Durchsatz zu langsam ist.

 ... aber mal im Ernst: ich hab weder ein persönliches Reply noch irgendne besondere Behandlung erwartet - ich hab zunächst mal nur die Fragen "Hat keiner hier ne Ahnung, was diese Fehlermeldung verursacht?" und "Wie kann man den betreffenden Buffer auf den benötigten Wert vergrößern?" gestellt.
 ... aber mal im Ernst: ich hab weder ein persönliches Reply noch irgendne besondere Behandlung erwartet - ich hab zunächst mal nur die Fragen "Hat keiner hier ne Ahnung, was diese Fehlermeldung verursacht?" und "Wie kann man den betreffenden Buffer auf den benötigten Wert vergrößern?" gestellt. ? Falls nicht, interpretiere ich Deine Antwort mal so, dass das Problem dann evtl. durch Ringpuffervergrößerung gelöst werden könnte. Ich hab aber keinen Plan, wo man da schrauben muss und ob das ein nicht-dev/nicht-unix-mächtiger überhaupt bewerkstelligen kann.
 ? Falls nicht, interpretiere ich Deine Antwort mal so, dass das Problem dann evtl. durch Ringpuffervergrößerung gelöst werden könnte. Ich hab aber keinen Plan, wo man da schrauben muss und ob das ein nicht-dev/nicht-unix-mächtiger überhaupt bewerkstelligen kann. ?
 ? .
 . !
 !


Code: Alles auswählen
WDR_Köln_Adelheid_und_ihre_M_rder_20040510_210351


