Jack the Grabber

Hi,

ich vermisse die Funktion, die das Log-File auch bei Streamserver-Aufnahmen speichert. Das sollte möglichst so aussehen:

Zusammenfassung der Aufnahme:
- Zeit, Dauer, Programm, EPG, APIDs, usw.
- Datenraten-Peak, -Durchschnitt, usw.

Fehler:
- Resyncs, andere Fehler

Protokoll:
- Auflistung aller Meldungen, Zeitangabe bitte relativ zum Aufnahmestart, nicht absolut. Das hilft besser, die Fehlerstellen im File zu finden.
- Hier bitte noch die Möglichkeit einbauen, dass in diesem Protokoll das Übersteigen der Datenrate ab einem einstellbaren Schwellenwert vorgenommen wird. Damit ist die Fehlersuche etwas leichter, wenn z.B. im Log steht, dass >6MBit und danach eine Reige Resyncs folgen.
- Umgekehrt sollte bei jedem Fehlerereignis eine Zeile mit den aktuellen Daten (Datenrate, CPU-Last) erfolgen.


Gag

irgendwann musste dass ja kommen
Aber über eine Kausalprüfung bei den ReSyncs habe ich auch schon nachgedacht. Sollte relativ einfach zu machen sein.

Levi

Hi,

Gag Halfrunt hat geschrieben: Zusammenfassung der Aufnahme:
- Zeit, Dauer, Programm, EPG, APIDs, usw.
- Datenraten-Peak, -Durchschnitt, usw.

Fehler:
- Resyncs, andere Fehler

faende ich auch gut...

Zeitangabe bitte relativ zum Aufnahmestart, nicht absolut.

das besonders...

Übersteigen der Datenrate ab einem einstellbaren Schwellenwert vorgenommen wird. Damit ist die Fehlersuche etwas leichter, wenn z.B. im Log steht, dass >6MBit und danach eine Reige Resyncs folgen.
- Umgekehrt sollte bei jedem Fehlerereignis eine Zeile mit den aktuellen Daten (Datenrate, CPU-Last) erfolgen.

das finde ich weniger sinnvoll. Ich denke die Abhaenigkeit zwischen Datenrate und Resync ist bei den neueren Images mit dem BH-Mode nicht mehr gegeben und wenn man noch ein altes Image drauf hat, die CPU-Last der Box beim streamen am Anschlag ist, sollte man nicht noch mit 'top' fuer's log die BOX-CPU-Last abfragen....sind wieder zusaetzliche >5% CPU-Last und die Aufnahme ist mit Sicherheit danach ganz im Eimer.


cu,
peter

@petgun: Nicht alle Leute sitzen neben Box und Rechner während eine Aufnahme läuft. In der Regel programmiere ich eine Liste an Sendungen und lasse die Kiste tickern, wenn ich nicht zu Hause bin.
Deshalb, und genau deshalb ist für mich ein detailliertes Log wichtig.

Ich hab gestern mal wieder versucht, Pearl Harbor zu streamen -- noch mit der Wingrabengine. Ich hatte wieder an zwei Stellen Ausfälle.

Und ich möchte gerne die Fehlerursache finden -- auch wenn es mit dem anderen Treiber klappt.

Gag

ich wüsst leider ned was ich mit den infos zu "resync" anfangen soll,
kann ich den film bei 2 resyncs vergessen ??

Joe

Ducati hat geschrieben:ich wüsst leider ned was ich mit den infos zu "resync" anfangen soll,
kann ich den film bei 2 resyncs vergessen ??

Am anfang habe ic hdie Teile dann in die Tonne gehauen. Aber mittlerweile schau ich mir die Stelle dann doch mal an. Bei 50 % der Fälle bekommt man das nichtmal mit, weil die Stelle im Film "ideal" für einen ReSync war...

Levi

Ich habe eigentlich immer ein oder zwei Resyncs.
Einen gleich am Anfang, zw. Programmvorschau und Filmbeginn und evtl. einen beim Abspan bzw. beim Filmende.
War schon unter Ngrab so.
Hab ich nie bemerkt, wahrscheinlich bei den Teilen bei, die ich wegschneide.
Streame übrigens wieder unter wingrab (klappt 1a )

Hi,

Gag Halfrunt hat geschrieben:Deshalb, und genau deshalb ist für mich ein detailliertes Log wichtig.

Und ich möchte gerne die Fehlerursache finden -- auch wenn es mit dem anderen Treiber klappt.

klar, hab ich auch so verstanden, ich bezweifle nur dass Du das mit dem momentanen Log inklusive CPU-Last und Deinen Vorschlaegen herausbekommst.....es sei denn, die Konsole-Ausgaben waeren noch mit dabei. Nach meinen (stundenlangen) Beobachtungen gibt's eben nicht mehr die Korrelation zwischen BOXCPU-Last und Resyncs...wohl die zwischen Resync und DMX buffer overflows und die siehst Du nur auf der seriellen Konsole.
Die Jagd nach den letzten Resyncs ist schwierig, aber ich hoffe das das auch bis Ende des Jahres gegessen ist.
So wie die abenteuerliche CPU-Last (keventd) waehrend des streamens imho ein klarer Design-Fehler war den Gandalfx und Obi mit dem BH-Mode gefixt haben, halte ich diese DMX-Buffer overflows fuer einen klaren Softwarefehler, der mit etwas mehr Anstrengung eigentlich auch gefixt werden koennte....nee, keinen Wuergaround sondern eine echte Fehlerbeseitigung.

cu,
peter

Die CPU-Last der Box mit den Resyncs in Zusammanhang zu bringen, hab ich auch aufgegeben -- zumal die Abfrage dieser Info die Box zusätzlich belastet.

Für mich interessant ist hauptsächlich die Datenrate. Denn es ist schon irgendwie komisch, dass ich Perl Harbor mit AC3 mit Wingrab nicht ohne Resyncs auf die Platte bekomme.

Gag

Hi,

Gag Halfrunt hat geschrieben:Für mich interessant ist hauptsächlich die Datenrate. Denn es ist schon irgendwie komisch, dass ich Perl Harbor mit AC3 mit Wingrab nicht ohne Resyncs auf die Platte bekomme.

...nach meinen Beobachtungen gibt's genau diesen Zusammenhang mit sehr hohen Spitzen bei den Datenraten (> 7000 kbit/sek) und/oder laengere Perioden mit moderateren Datenraten (zwischen 5500-6500 kbit/sek) und diesen dmx bufferoferflows mit nachfolgendem/oder vorauseilenden Resync....keine Ahnung ob das Ei zuerst da war oder die Henne
Ich denke das wir versuchen muessen die DBOX-Devs zu motivieren, sich intensiver darum zu kuemmern....ich glaube nicht das es besonders schwer fuer die Cracks ist, so einen Fehler zu _fixen_ anstatt die Buffer einfach nur zu vergroessern bzw. sich andere Wuergarounds auszudenken (Ringbuffer). Eine live 'Fuellstandsanzeige' dieses Buffers, waere fuer weitere Beobachtungen sicher schon mal ganz hilfreich...??

Just my 2C,
peter

Auch auf die Gefahr hin totalen Müll zu erzählen, habe ich das so mitbekommen, dass die "dmx buffer overflows" zustande kommen, wenn eben der ringpuffer überläuft, was bei hohen Datanraten öfters passiert. Da dieser 64k hardwareseitig hat, ist da nicht viel mit Puffervergrößerung...
Was ich sehe, ist keine Verbesserung zum Jahresende sondern einen Abwärtstrend. Lies Dir mal die Threads (hast Du sicher schon) im TuxBox durch, je neuer das Image, desto größer die Probleme. Aber wir brauchen ja unbedingt einen MP3 Player, einen MoviePlayer und unsere Lemminge in der Box. Nicht das das nun unbedingt was mit dem Streamen zu tun hat, aber die wievielte API Änderungen hatten wird in den letzten anderthalb Jahren ? 3 ? Und dem alexw haben sie auch vorgeworfen, dass ein Rückschritt nix bringt, obwohl er es geschafft hat, die Treiber einigermaßen stabil zu bekommen.
Vielleicht ist mein Standpunkt auch etwas vermessen, da ich von den Treiber fast null Kennung habe, aber //IRONI ON jede Woche bei Null anfangen //IRONI OFF kanns meiner Meinung nach auch nicht sein.

Levi

Hi,

Levithan hat geschrieben:dass die "dmx buffer overflows" zustande kommen, wenn eben der ringpuffer überläuft, was bei hohen Datanraten öfters passiert. Da dieser 64k hardwareseitig hat, ist da nicht viel mit Puffervergrößerung...

da haben die Jungs aber dran geschraubt ohne Ende und mkdvd von Tonsel hat noch einen draufgesetzt, ist aber langfristig auch nicht sicher vor diesen Buffer Overflows.

Aber wir brauchen ja unbedingt einen MP3 Player, einen MoviePlayer und unsere Lemminge in der Box

.
klar, ist doch ein anarchistisches Spassprojekt

Nach meiner Meinung sehen die Jungs vor lauter Baeumen den Wald nicht mehr und suchen, schrauben und fixen alle an den gleichen (falschen?) Stellen. Du weisst doch sicher wie man Ringbuffer programmiert und wie man die Pointer dazu abfragt und zB. nach einem Resync zuruecksetzt....da scheint mir einiges fehlerhaft zu sein: Oft hat man nach beginn einer Aufnahme lange Ruhe mit Resyncs....wenn dann aber der erste Resync kommmt ist es oft vorbei mit lustig...es folgen oft weitere Resyncs in _kuerzeren_ Abstaenden. Fuer mich ein Hinweis darauf, das dieser Buffer evtl. Garbage enthaelt, der nicht entsorgt worden ist.

cu,
peter

--
Um klar zu sehen, genügt oft ein Wechsel der Blickrichtung.
[Antoine de Saint-Exupéry]

Um an ein IMAGE zui gelangen, das nicht die ganzen Spielereine enthält, sollten wir vielleicht mal mit MUESLI Kontakt aufnehmen. er hat mal ein Projekt gestartet, bei dem er eigene IMAGES erstellt hat und sich dabei nur auf das Wesentliche konzentrierte.

Ich werd' mal schauen, ob ich dazu noch ein paar Infos auftreiben kann, und die IMAGES gegebenenfalls mal testen.

Cu leth

da scheint mir einiges fehlerhaft zu sein: Oft hat man nach beginn einer Aufnahme lange Ruhe mit Resyncs....wenn dann aber der erste Resync kommmt ist es oft vorbei mit lustig...es folgen oft weitere Resyncs in _kuerzeren_ Abstaenden. Fuer mich ein Hinweis darauf, das dieser Buffer evtl. Garbage enthaelt, der nicht entsorgt worden ist.

Ganz genau. Wenn der erste ReSync passiert ist, bleibts meistens nicht bei einem. Aber uns bleibt da leider nur das Warten und Hoffen

Levi[/quote]

Hab muesli mal ein PM geschickt. Vielleicht kommt dabei ja was raus

cu leth