Streamen auf ein NFS-Share unter Neutrino

Digital Recording
petgun
Tuxboxer
Tuxboxer
Beiträge: 5001
Registriert: Montag 11. November 2002, 15:26

Beitrag von petgun »

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

cu,
peter
tHec@
Neugieriger
Neugieriger
Beiträge: 13
Registriert: Samstag 8. Mai 2004, 07:13

Beitrag von tHec@ »

... 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
Schwarzseher
Interessierter
Interessierter
Beiträge: 46
Registriert: Donnerstag 19. Februar 2004, 10:33

Beitrag von Schwarzseher »

petgun hat geschrieben:Hi,
Schwarzseher hat geschrieben:.... Könntest Du vielleicht eine kurze Anleitung für SFU veröffentlichen?...
...ich kanns ja mal versuchen mit einer Anleitung:
Danke!

Werde es mal antesten und dann berichten.

Gruß
Schwarzseher
Schwarzseher
Interessierter
Interessierter
Beiträge: 46
Registriert: Donnerstag 19. Februar 2004, 10:33

Beitrag von Schwarzseher »

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...
Helfen kann ich zwar nicht, aber ... wie kommt man eigentlich an so ein Log?
DrStoned
Tuxboxer
Tuxboxer
Beiträge: 2614
Registriert: Montag 20. Mai 2002, 10:49
Image: JTG-Image [IDE] Version 2.4.4
Image: (7025SS) Merlin

Beitrag von DrStoned »

Helfen kann ich zwar nicht, aber ... wie kommt man eigentlich an so ein Log?
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.

Greetz von DrStoned :lol: :lol: :lol:
Greetz von DrStoned :lol: :lol: :lol:
Tattergreis
Interessierter
Interessierter
Beiträge: 66
Registriert: Sonntag 19. Oktober 2003, 11:10

Beitrag von Tattergreis »

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
Ä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.

Versuch doch einfach mal, Dir auf dem System, wo der NFS-Server läuft, den Share lokal zu mounten und kopiere mal ein paar GB hin und her. Falls das schon nicht klappt liegt es an dem System, wo der NFS-Server läuft. Am Neutrino liegt es meiner Meinung nach nicht, denn es klappt hervorragend - vorausgesetzt, der NFS-Server läuft korrekt.

Gruß, Tattergreis
Frockert
Erleuchteter
Erleuchteter
Beiträge: 865
Registriert: Dienstag 12. März 2002, 21:40

Beitrag von Frockert »

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.


Ähem,

mein Linux-Nfs-Server ist ein Pentium 100 mit 32 MB, die bisher grösste Datei die ich gestreamt habe war 1,5 GB, und das ohne Probleme.


Gruß Frockert
---------------------------
2.6.11-kanotix-3 KDE 3.3.2
http://www.frockert.de
http://www.eifel-forum.de
Tattergreis
Interessierter
Interessierter
Beiträge: 66
Registriert: Sonntag 19. Oktober 2003, 11:10

Beitrag von Tattergreis »

Hi zusammen!

Ich hoffe mal, ich schliddere nicht zu weit ins OT. :oops: 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. :D 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

Viel Spaß beim Direct Recording! :D

Tattergreis

P.S. FLI4L unterliegt einer Dateigrößenbeschränkung von max. 2 GB, daher Splitten nicht vergessen.
Frockert
Erleuchteter
Erleuchteter
Beiträge: 865
Registriert: Dienstag 12. März 2002, 21:40

Beitrag von Frockert »

P.S. FLI4L unterliegt einer Dateigrößenbeschränkung von max. 2 GB, daher Splitten nicht vergessen.

Hi,

noch als Zusatz, der Eisfair arbeitet mit Kernel 2.4.23-4-SMP.

Nach meiner Kenntnis kann ich damit auf einem Ext2 Filesystem mit Dateigrössen bis maximal
2 Terabyte (!) verwalten.

Das sollte für den Anfang reichen...

:lol:

Gruß Frockert
petgun
Tuxboxer
Tuxboxer
Beiträge: 5001
Registriert: Montag 11. November 2002, 15:26

Beitrag von petgun »

hi,
mit einem Schuss von heute (9.5) gibt's nach einer Aufnahme jetzt einen freundlichen Hinweis:
'Die Aufnahme wurde erfolgreich beendet',
die Box muss nicht neu gestartet werden fuer eine erneute Aufnahme
es gibt die funktionierende optionale Moeglichkeit alle Audio PIDs aufzunehmen und splitten funktioniert auch :-)

vielen Dank an alle Entwickler!


cu,
peter
tHec@
Neugieriger
Neugieriger
Beiträge: 13
Registriert: Samstag 8. Mai 2004, 07:13

Beitrag von tHec@ »

@Tattergreis

Ich hab diesen Thread aus verständlichen Gründen sehr wohl von Anfang an mitverfolgt. Dabei stach mir Deine gleichlautende Fehlermeldung (Page 5) auch sofort ins Auge.
Allerdings kann ich mir vorstellen, dass DU den Thread nicht genau mitgelesen hast. Sonst wäre Dir bekannt, dass der Pufferfehler bei mir (im Gegensatz zu dem Verhalten bei Dir, wo ja angeblich ein paar Daten mehr geschrieben werden) prinzipiell_immer_sofort nach dem Streamstart auftaucht (und das unabhängig vom verwendeten NFS-Server).
Deswegen (und auch wegen der 2GB-Grenze) hab ich's gewagt, Deiner wohl durchaus gutgemeinten Aufforderung zur Installation von TrueGrid (siehe Page 6) zu widerstehen und später nur mal zu fragen, ob und wie man den Ringpuffer (!) vergrößern kann (worauf ich übrigens bis jetzt immer noch kein Feedback bekommen habe).

Zur Personal Firewall: entweder lässt sie die Daten bzw. schon den Request durch, oder nicht. Ein Verhalten nach dem Motto, erstmal ein bisschen was durchlassen und dann dichtmachen, kenn ich eigentlich bei keiner Firewall.

Zu Deiner Vermutung, dass es nicht an Neutrino liegen sollte: wenns nicht an Neutrino liegt, warum dann die Meldung des Buffer-Overflows? Irgend'ne Routine meldet mir einen genau spezifizierten möglichen Fehlergrund. Warum probiert man dann nicht erst mal die Vergrößerung des Puffers ? Wenn einer zu mir gesagt hätte "das geht nicht" (fest codiert, zu großer Aufwand, zu kompliziert für einen unix_nicht _sprech-deppen), wärs das halt gewesen. Hat aber keiner gesagt. Immer noch nicht. Hoffentlich stört Dich meine Hartnäckigkeit nicht...!
Übrigens: nachdem ich in der Box den Mount per tcp anstelle von udp initialisiere, läufts! Kannst Du mir sagen, warum? Werden gar bei tcp u.U. andere Puffer als bei udp verwendet ??

Ach ja, und was mir beim weiterlesen des Threads (Du merkst, ich lese!) noch aufgefallen ist: ich komm mir immer noch ignoriert vor...

Gruss
Thomas
petgun
Tuxboxer
Tuxboxer
Beiträge: 5001
Registriert: Montag 11. November 2002, 15:26

Beitrag von petgun »

Hi tHec,
ich kann nicht so ganz vertsehen warum Du hier so ein Fass aufmachst...keiner ignoriert Dich, auch wenn Du keine an Dich persoenlich adressierte Antwort erhaelts.
Ich vermute ein Netzwerkproblem bei Dir und diese Fehlermeldung:

Code: Alles auswählen

.
PANIC: not enough space in ringbuffer, available 55659, needed 80640 
nfs: server 192.168.0.4 not responding, timed out 
.
kommt nach Streamabruch...wenn eben der Ringbuffer nicht rechtzeitig geleert wird. Versuch mal einen neuen Schuss >8.5, da ist etwas in der Richtung geaendert worden.

viel Erfolg,
peter
gagga
Senior Member
Beiträge: 782
Registriert: Dienstag 25. Februar 2003, 21:35

Beitrag von gagga »

Ringpuffer vergrößern bringt nix, wenn das Netzwerk bzw. der NFS Durchsatz zu langsam ist.
Tattergreis
Interessierter
Interessierter
Beiträge: 66
Registriert: Sonntag 19. Oktober 2003, 11:10

Beitrag von Tattergreis »

@ tHeca Wenn Du eh schon alles weißt und Dich außer der Vergrößerung des Ringbuffers keine Lösungsvorschläge interessieren hast Du wohl im falschen Thread und in der falschen Rubrik gepostet. Und nein, es liegt nicht am Neutrino, denn die ganze Funktion steht und fällt mit der Gegenseite, sprich dem NFS-Server. Und das sicher nicht nur bei mir.

Gruß, Tattergreis
petgun
Tuxboxer
Tuxboxer
Beiträge: 5001
Registriert: Montag 11. November 2002, 15:26

Beitrag von petgun »

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

Dein Movieplayer laeuft bei mir wie ein Uhrwerk mit den TS-Files !

Danke fuer die Arbeit,
peter
tHec@
Neugieriger
Neugieriger
Beiträge: 13
Registriert: Samstag 8. Mai 2004, 07:13

Beitrag von tHec@ »

Hi all

@petgun
Wenn ich ein Fass aufmache, dann ists meistens was zum trinken :wink: ... 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.
Deine Vermutung mit Netzwerkproblem ist sicher naheliegend. Deswegen hab ich mal den Durchsatz getestet:
ftp-Tansfer von oder auch zur Box: ca. 960 kByte/s was so übern Daumen ner Rate von 7,9 MBit/s entspricht.
nfs-Transfer (per telnet auf der box angemeldet und ne große Datei einfach mal vom/zum selben mount-Laufwerk kopiert): 470-500 kByte/s schreiben bzw. senden. Also insgesamt ebenfalls ungefähr wie bei ftp. Bricht aber ab und an auch mal bis auf 400 kByte/s ein.
Ich bin jedenfalls ratlos. Snap vom 9.5. auch schon installiert und -wie Du vermutet hast- keine Änderung des Verhaltens.

@gagga
Schon klar. Aber ist der Durchsatz bei mir so grottenschlecht :o ? 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.

@Tattergreis
lese ich da einen Anflug von Trotz zwischen Deinen Zeilen :wink: ?
Nicht böse sein!! So schlimm, wie Du's aufgefasst hast, war es von mir nicht gemeint. Mich hat halt nur genervt, dass ich keine exakte Antwort bekommen hab. Mal die Firewall zu deaktivieren, hatte ich schon als "gebranntes Kind" beim ersten Auftreten des Problems probiert - keine Besserung.
... ich weiss, hier "opfern" viele ihre Freizeit, um das Projekt weiterzubringen oder um Fragen zu beantworten. Ist auch prima von Dir :) .
Trotzdem solltest Du nach Deinem Spruch "Ähem ... ich will ja nichts sagen, aber hast Du eigentlich diesen Thread mal gelesen?" damit rechnen, dass man Dir genauso kommt. An Deiner letzten Antwort sieht man ja, dass Dir das dann auch stinkt :wink: !
Als ehemaliger Raucher biete ich Dir hiermit offiziell die Friedenspfeife an - ok?

Gruss
Thomas
DieMade
Oberlamer, Administrator & Supernanny
Beiträge: 10532
Registriert: Samstag 13. Juli 2002, 10:49

Beitrag von DieMade »

Wenn der Gesamtdurchsatz schlecht ist, hilft der Ringbuffer da nix. Er würde halt nur etwas später überlaufen.
There are 10 types of people in the world: those who know binary and those who don't
rasc
Senior Member
Beiträge: 5071
Registriert: Dienstag 18. September 2001, 00:00

Beitrag von rasc »

wieso Gesamtdurchsatz?

... mehr als bereits getan kann Premiere die Bitraten wohl nicht mehr runterfahren...
DieMade
Oberlamer, Administrator & Supernanny
Beiträge: 10532
Registriert: Samstag 13. Juli 2002, 10:49

Beitrag von DieMade »

Oller Wortklauber ;)
There are 10 types of people in the world: those who know binary and those who don't
mash4077
Tuxboxer
Tuxboxer
Beiträge: 4654
Registriert: Samstag 27. April 2002, 13:19

Beitrag von mash4077 »

rasc hat geschrieben:... mehr als bereits getan kann Premiere die Bitraten wohl nicht mehr runterfahren...
Du zweifelst an den Fähigkeiten von Premiere? Lass Dich überraschen! :wink:

Gruß
mash
tHec@
Neugieriger
Neugieriger
Beiträge: 13
Registriert: Samstag 8. Mai 2004, 07:13

Beitrag von tHec@ »

@made

nur zum Verständnis:
wird der Sendepufferinhalt der Box nicht schnell genug per nfs abtransportiert, kommts zu Overflow.
Je weniger Daten auf den nfs-mount gespeichert werden, umso schneller tritt der Fehler auf.
Ergo: Puffervergrößerung bringt nichts.
Hab ich soweit kapiert.

Was ich nicht kapiere:
- Wieso klappts per tcp, per udp aber nicht?
- Sind ca. 960 kByte Durchsatz zu wenig?

Herrgott Margott! Ich werd noch zum Pferd.
Wirklich das Einzige, was ich noch versuchen könnte: Vielleicht sollte ich NIS nicht nur deaktivieren, sondern mal komplett runterschmeissen (@Tattergreis: Dein Vorschlag! Asche auf mein Haupt!). Das Ding hat mir schon öfter in die Tasse gepinkelt.

Gruss
Thomas
petgun
Tuxboxer
Tuxboxer
Beiträge: 5001
Registriert: Montag 11. November 2002, 15:26

Beitrag von petgun »

Hi
@tHec
ein User im JtG Forum (Serkmann) hat OmniNFS nach aendern der Buffergroesse auf 16Kb von Omni _und_ auf der BOX stabil zum laufen bekommen. Vielleicht hilft Dir das ja etwas...Versuch macht klug!

viel Erfolg,
peter

PS:aendert sich an der Benamung der Dateien was die Sonderzeichen/Umlaute betrifft noch etwas ?
Sieht bei mir zB. so aus:

Code: Alles auswählen

WDR_Köln_Adelheid_und_ihre_M_rder_20040510_210351
Der EPG-Text und die Darstellung auf der Box sind in Ordnung.
tHec@
Neugieriger
Neugieriger
Beiträge: 13
Registriert: Samstag 8. Mai 2004, 07:13

Beitrag von tHec@ »

@pet
danke für den Tip!

cu
phiber
Interessierter
Interessierter
Beiträge: 48
Registriert: Freitag 11. Januar 2002, 13:22

Beitrag von phiber »

Hi All,

leider wird bei mir immer nur das .xml File abgelegt, von dem .ts bzw .0 und .1 File keine Spur.
Habe schon nen Terminal angeschlossen um zu debuggen, leider kein Fehler ersichtlich :(

Ich nutze Omni-NFS Enterprise 5.2 unter Win2k3 Server.
Der NFS-Share wird ordnungsgemäß rw gemountet, kann auch große Dateien dort reinschieben ...

Hat jemand das gleiche Problem?
Gibts vielleicht ne Lösung dafür?

Gruß,
phiber
Der_Onkel
Interessierter
Interessierter
Beiträge: 70
Registriert: Dienstag 19. März 2002, 15:12

Beitrag von Der_Onkel »

@Phiber

Welcher cvs stand ? die version vor/vom 6.5 hatte diesen Bug Streamen ging nur 1mal nach dem Neustart. dannach wurden nur die xml's abgelegt.

@tHec

Probier mal eine andere Netzwerkkarte. AALsoo...

Ich hatte nur Probleme ,ständige hänger und abbrüche sowohl unter Win als unter Linux.
Zwischenzeitlich hab ich mir nen kleinen Eisfairserver (eisfair.org) gebaut (PI-100 !)
mit selben problemen.Nun hab ich mal testweise diese olle Realtec billigschleuder rausgeschmissen und eine uralte ISA 3com Etherlink 10mbit NIC eingebaut .Ergebnis - einfach Perfect , keinerlei abrüche hänger oder sonstwas.