holzmichel

Ja, da hast Du wohl recht

Ich habe mit dem "renice 20" gerade eine ganze Sendung ohne Fehler aufnehmen können. Man darf allerdings während einer Aufnahme nicht via telnet auf die Box gehen, dann bricht sie mit der Fehlermeldung "Daten zu langsam ..." ab. Wenn man das berücksichtigt ist deine Lösung eine feine Sache. Bliebe für die CVS Entwickler evtl. noch die Frage wieso das renice im März Image nicht nötig war?! Vielen Dank für die tolle Unterstützung und Lösung

Sieht gut aus. Deine Idee scheint das Problem einzugrenzen. kleiner Tipp zur Vereinfachung: renice kann mehrere PIDs in einem Befehl annehmen. Ich habe also vor der Aufnahme renice 20 141 142 143 ausgeführt und sofort nach der Aufnahme renice 20 141 142 143 162 163 siehe da - die ORF Aufnahme läuft jetzt schon 15 Minuten ohne Fehler und das mit allen Audio PIDs bei einem Hauptfilm...

Ich habe die Pozesslast auf meiner Box mal etwas beobachtet. Die sectionsd ist bei meinem Juni Image nicht sehr ressourcen-hungrig weder im Normalbetrieb noch während der Aufnahme. Nichts desto trotz habe ich mal ein "killall sectionsd" durchgeführt. Das hat mein Aufnahme Problem mit dem Juni Image aber nicht positiv beeinflußt. Ich habe mal die "aufnahme-dominanten" Prozesse neutrino und rpciod bei einer ORF und einer "normalen" Aufnahme mit 'top' verglichen. ORF: Systemlast schwankt zwischen 15% und 80% neutrino benötigt ca. 20% CPU Perf. rpciod schwankt zwischen 10% und 20 % CPU Perf. RTL: Systemlast schwankt zwischen 15% und 60% neutrino benötigt ca. 20% CPU Perf. rpciod bleibt bei ca. 5% CPU Perf. Der Vergleich mit dem März Image: ORF: Systemlast schwankt zwischen 15% und 90% neutrino benötigt bis zu 40% CPU Perf. rpciod schwankt zwischen 5% und 15% CPU Perf. Falls man daraus überhaupt etwas ableiten kann, dann vielleicht, dass das Juni Image 'neutrino' keine 40% CPU Perf. zur Verfügung stellen kann ohne die Aufnahme abzubrechen. Oder alternativ, dass der rpcio Daemon im Juni Image mehr Ressourcen schluckt als im März Image? Sectionsd spielt in meiner Top Liste eine untergeordnete Rolle?! Ich downgrade wieder auf mein liebgewonnenes März Image und bin ganz gespannt auf euer nächstes Image. Vielen Dank für die Unterstützung.

Ich habe den Ringbuffer mal auf 80 gestellt. Die Aufnahme bricht weiterhin ab, selbst bei einem Kindercomic, der wahrscheinlich nicht in allzu hoher Qualität ausgestrahlt wird. Das März Image lief bei mir über einen Monat ohne Aufnahmeprobleme. Ich habe alle möglichen Filme aufgenommen (meistens Hauptfilme aber auch anderes Zeug). Beim Juni Image kann ich aufnehmen was ich will spätestens nach einer Minute bricht die ORF Aufnahme ab. Es dauert etwas länger wenn ich nicht alle Audio PIDs aufzeichne aber auch dann bricht die Aufnahme nach spätestens 2 Minuten ab. Ich stimme Dir zu Kai-t, dass das Problem bestimmt auch an der onboard Via NIC in meinem Linux Mini-Server liegt, so dass das Juni Image bei einer 'normalen' NIC problemlos mit ORF funktioniert. Aber irgendwas muss das März Image anders (effektiver) gemacht haben, als das Juni Image, da ich das Problem mit diesem Image nicht kenne. Ich habe den direkten Vergleich wenn ich die Images über 'Service - Software Aktualisierung -...- einzelne Partition einspielen' kurzfristig tausche. Bei der gleichen ORF Sendung: - März Image -> funzt prima. - Juni Image -> Aufnahme bricht ab.

Hallo Keyworld Team, das März Image war bisher mein absoluter Favorit. Das einzige Manko waren vereinzelte Hänger nach denen Bild und Ton nicht mehr synchron waren. Aus diesem Grund habe ich jetzt gleich mal das Juni Image ausprobiert. Jetzt kämpfe ich erstmal mit einem neuen Problem, welches ich bei dem März Image nicht hatte. Das Aufnehmen von ORF via NFS bricht minütlich ab. Fehlermeldung: Die Daten konnten nicht schnell genug übertragen werden. Ich habe alle Einstellungen überprüft und identisch zum März Image gemacht. Des Weiteren habe ich sowohl das Squash als auch das JFFS2 Image ausprobiert. Nach einer Rescherche im Web habe ich verschiedene Werte der RSIZE; WSIZE bzw. RINGBUFFER Variablen ausprobiert. Leider habe ich das Problem damit nicht beheben können. Alle anderen Sender (auch P** Start) machen keine Probleme bei der NFS Aufnahme. Hat jemand eine Idee wieso ich mit dem März Image ORF aufnehmen kann und mit dem Juni Image nicht mehr.

Die Datei /etc/exports existiert nicht in der box sondern auf dem (Linux) NFS Server. Mit dieser Datei gibst Du an wer auf welche Freigraben zugreifen darf und wie die Freigabe angesprochen wird -> als sync oder async. Solltest Du deinen NFS Server unter Wi*** betreiben, so kann ich dir leider nicht sagen, wo man hier den Parameter anpasst bzw. ob das überhaupt möglich ist. Die Parameter fdatasync und o_sync habe ich auf aus (Default). Gruesse.

Die Anzahl der Ringpuffer gibt an wie gross der Zwischenspeicher ist. Falls Daten nicht sofort geschrieben werden können werden diese im Ringpuffer zwischengespeichert. Ein Ringpuffer entspricht ca. 64 kByte Ich hatte ebenfalls mit vielen Images Probleme mit vereinzelten Files beim Streamen. Ein Image welches bei mir immer komplette Streams erzeugt ist NAIS2000 vom 11.12.04. Da das aktuelle Keyworld Image interessante Features bietet, habe ich mich dem Problem nochmal zugewandt. Folgender Ansatz hat bei mir das Problem behoben. Ich betreibe meinen NFS Server unter Debian Sarge mit dem Defaultwert "synchrones schreiben". Nach dem ich hier die Einstellung auf "asynchrones Schreiben" geändert habe, bekomme ich selbst bei Filmen mit 3 Audio Streams (dt. - engl. - AC3) keine vereinzelte Files mehr. -> alter Inhalt der /etc/exports /freigabeverzeichnis *(rw,sync) ---- -> neuer Inhalt der /etc/exports /freigabeverzeichnis *(rw,async) Den Wert für Ringpuffer auf der dbox habe ich auf 20 (Default) gelassen. Gruesse.