Größerer Buffer beim Movieplayer

Wünsche, Anträge, Fehlermeldungen
rolano
Erleuchteter
Erleuchteter
Beiträge: 601
Registriert: Montag 14. März 2005, 08:49

Beitrag von rolano »

petb hat geschrieben: (...) Timeshift (...)
gmo18t hat geschrieben:
sollte eher am nfs liegen, denn bei selbigem Scenario, lediglich Box2 spielt via streamer ab (anstelle nfs), klappt's prima.
Aber wäre natürlich interessant, diesem "nfs"- Verhalten mal genauer
auf die Spur zu kommen ...
....an diesem Problem knabbere ich seit Monaten - ohne eine annähernd befriedigende Lösung zu finden. Wie petb schon geschrieben hat, funktioniert das Aufnehmen und gleichzeitige/zeitversetzte abspielen via PC (dabei ist es völlig unerheblich wie das Zeugs verkabelt ist) völlig problemlos.....was nicht funktioniert ist schreiben mit Box1 und lesen mit Box2 (jeweils mit NFS/udp). Ich habe/hatte mich damit abgefunden, dass konkurrierende Schreib-/Lesezugriffe über UDP einfach nicht funzen (tcp kann meine WL-HDD nicht - vielleicht könnte petb das mal testen....schreiben mit udp - lesen mit Box2 über tcp...). Mit 2 Boxen gleichzeitig schreiben geht.....

Keine Ahnung, ob das ganze nicht "OFF-Topic" ist :gruebel:

rolano
petb
Erleuchteter
Erleuchteter
Beiträge: 785
Registriert: Samstag 6. August 2005, 03:39

Beitrag von petb »

rolano hat geschrieben: Keine Ahnung, ob das ganze nicht "OFF-Topic" ist :gruebel:
rolano
naja, wollte damit ja nur sagen das ich denke das mit einem größeren Puffer eventuell besser klappen könnte.
Mein Hintergrund ist der das z.B. Tommy hofft mit einem 4fach NIC besser zurecht zu kommen und ich das bei mir, mit mehreren NICs im Server auch testen will.
Und bei mir die Aufnahme/Wiedergabe auch mit bis zu 7 Boxen glatt läuft, solange ich:
1.) während der Wiedrgabe nicht wild zappe oder die Pausefunktion nutze
2.) die Wiedergabestreams keine hochratigen Streams sind.
Mit bis zu 4 Boxen klappt das gerade noch so.

Ohne es jetzt zu wissen, denke ich wäre ein größerer Puffer auf jeden Fall testenswert.
Denn es krankelt nur beim Player, die Aufnahmen laufen weiter.

Zum Timeshift, ja, denke das wäre hier OT. :lol:
Bye
PetB
1 x DBOX2 Phillips, 1 x DBOX2 Nokia, 1 x DBOX2 Sagem, 100er Gibertini (Astra / Hotbird), NFS Server
gmo18t
Erleuchteter
Erleuchteter
Beiträge: 553
Registriert: Freitag 27. Februar 2004, 14:30

Beitrag von gmo18t »

petb hat geschrieben: Ohne es jetzt zu wissen, ...
das ist immer schlecht :)
aber du solltest auch besser schreiben: "ohne es ausprobiert zu haben" !
denke ich wäre ein größerer Puffer auf jeden Fall testenswert.
Denn es krankelt nur beim Player, die Aufnahmen laufen weiter.
also wie schon x-mal gesagt: ich habe größere Puffer getestet (und noch vieles mehr), hat aber keine Verbesserung gebracht.
Wenn mir einer einen wirklich sinnvollen Vorschlag macht, woran es liegen könnte, wäre ich der Erste, der das im MP einproggen würde ...

Und daß das Timeshift-Problem nix mit dem MP zu tun haben kann, geht aus meinem obigen Posting hervor !

Und nochwas zum Nachdenken: man stelle sich einmal vor, die Box hätte ordentlich RAM, ausreichend für Puffer von zig MBs, dann würde es nach jedem "minutenweise" Springen auch Minuten dauern bis es wieder weitergeht - aber wer will das schon ?
(Erklärung: da ja an einer anderen Stelle des Filmes weitergemacht wird, ist der Pufferinhalt nach dem Sprung ja nicht mehr brauchbar und muß erst neu mit 10MBit/sec gefüllt werden)

- GMo -
rolano
Erleuchteter
Erleuchteter
Beiträge: 601
Registriert: Montag 14. März 2005, 08:49

Beitrag von rolano »

gmo18t hat geschrieben: also wie schon x-mal gesagt: ich habe größere Puffer getestet (und noch vieles mehr), hat aber keine Verbesserung gebracht.
.... das habe ich schon nach gaggas Statement geglaubt....und das glaube ich noch.....
Und daß das Timeshift-Problem nix mit dem MP zu tun haben kann, geht aus meinem obigen Posting hervor !
....auch das ist mir klar (deshalb der Hinweis auf "OFF-Topic") - allerdings wollte ich mir die Gelegenheit dieses "Problem" mal wieder hochzukochen nicht entgehen lassen 8) . Vielleicht kannst Du Dich ja mal zu der Vermutung "konkurrierende Schreib-/Lesezugriffe mit UDP" äußern....auch wenn sie totaler Quatsch sein sollte...

rolano
gmo18t
Erleuchteter
Erleuchteter
Beiträge: 553
Registriert: Freitag 27. Februar 2004, 14:30

Beitrag von gmo18t »

rolano hat geschrieben:.... das habe ich schon nach gaggas Statement geglaubt....und das glaube ich noch.....
... hatte dich ja auch nicht gemeint, siehe quotes :)
Vielleicht kannst Du Dich ja mal zu der Vermutung "konkurrierende Schreib-/Lesezugriffe mit UDP" äußern....auch wenn sie totaler Quatsch sein sollte...
na ja, nfs via tcp verhält sich ja genauso !
Vielleicht geht das mehr in richtung "locks", so das Schreiben priorisiert ist und das Lesen u.U. warten muß ...

- GMo -
Sagem 1x Kabel, AVIA600_vb028, cam-alpha 01_02_105D, int. ucode, .sp_ts + .hw_sections
Torsten73
Erleuchteter
Erleuchteter
Beiträge: 547
Registriert: Mittwoch 30. Juni 2004, 16:06

Beitrag von Torsten73 »

Hi,
kurz zum OT Timeshift, es gibt vielleicht doch Wege, auch wenn ich nicht genau weiß wie. Aber was geht ist die gleich Datei gleichzeitig auf mehreren Boxen sich anzuschauen (jede Box mit separatem Nic). Warum das beim R/W nicht gleichzeitig geht ist mir aber ein Rätsel.

http://forum.tuxbox-cvs.sourceforge.net ... 728#290728

Cu
Torsten
petb
Erleuchteter
Erleuchteter
Beiträge: 785
Registriert: Samstag 6. August 2005, 03:39

Beitrag von petb »

gmo18t hat geschrieben:
petb hat geschrieben:Ohne es jetzt zu wissen, ...
das ist immer schlecht :)
aber du solltest auch besser schreiben: "ohne es ausprobiert zu haben" !
*Zunge rausstreck und grins* Hast ja Recht :lol:
denke ich wäre ein größerer Puffer auf jeden Fall testenswert.
Denn es krankelt nur beim Player, die Aufnahmen laufen weiter.
also wie schon x-mal gesagt: ich habe größere Puffer getestet (und noch vieles mehr), hat aber keine Verbesserung gebracht.
Wenn mir einer einen wirklich sinnvollen Vorschlag macht, woran es liegen könnte, wäre ich der Erste, der das im MP einproggen würde ...
naja, mir erschliest sich nach wie vor nicht, warum der Player so schnell aus dem Tritt kommt.
Wenn es denn am nfs liegt, wo und wie könnte man das dann beinflussen ?
Und daß das Timeshift-Problem nix mit dem MP zu tun haben kann, geht aus meinem obigen Posting hervor !
Nö, nicht wirklich. Für mich heist das nur das die Daten auf diese Weise (streamer) ohne zu stocken zum MP gelangen. Und das nfs oder auch irgend was anderes dafür sorgt das die Daten sonst eben nur stockend ankommen. Aber sie kommen grundsätzlich an.
Was ich sehe ist:
Der Server schafft es allemal die Daten zu liefern um Timeshift, als auch ruckelfreies Abspielen hochratiger Streams zu gewährleisten. Das hast du mit Streamer etc. bewiesen.
Und das der MP, sofern er die Daten nicht stockend, also rechtzeitig bekommt diese auch Abspielen kann.
Und für dich selbst hast du bewiesen das ein größerer Puffer nichts bringt.
Jetzt gilt es zu klären ob nfs, udp oder was anderes für Ruckler verantwortlich sein kann.
Und da habe ich jetzt bewiesen das es mit nfs und udp und einem weiteren Nic im Server der nur für die eine abspielende Box zuständig ist "minimal besser geht.
Um jetzt das ganze weiter zu verfolgen, werde ich, wenn ichs schaffe, am Wochenende noch mehr Nics in den Server stecken und die mit jeweils unterschiedlichen Protokollen an die Boxen bringen, NFS/CIFS/FTP.
Dazu werde ich dann niederratige Aufnahmen nutzen um den Flaschenhals 10MBit gedanklich weiter weg zu rücken.
Dann bin ich mal gespannt was der Player dann macht.
Und nochwas zum Nachdenken: man stelle sich einmal vor, die Box hätte ordentlich RAM, ausreichend für Puffer von zig MBs, dann würde es nach jedem "minutenweise" Springen auch Minuten dauern bis es wieder weitergeht - aber wer will das schon ?
(Erklärung: da ja an einer anderen Stelle des Filmes weitergemacht wird, ist der Pufferinhalt nach dem Sprung ja nicht mehr brauchbar und muß erst neu mit 10MBit/sec gefüllt werden)
- GMo -
Ja, klar.
Aber es geht ja nicht ums springen.
Da dürfte der MP meines Erachtens auch eine kleine Auszeit nehmen
Es geht ja eigentlich darum das der MP ins stocken gerät, sobald Netzwerklast da ist.

Mir ist die letzten tage während des testens auch aufgefallen das wenn ich wild hin und her springe, bzw. die (jetzt kommts) Pausefunktion nutze bei 3 weitern Boxen die gerade aufnehmen, die Aufnahme unterbrochen wird und in einer neuen Datei fortgesetzt wird.
Insofern kann ich mir um eine Brücke zu deinen Gedanken zu bauen, grundsätzlich auch Probleme beim Protokoll oder auch anderen Dingen vorstellen. Ich will das auf keinem Fall ausschliesen. Würde mich aber freuen, wenn jemand der den Siurce versteht nachschaut wie die Pausenfunktion programmiert ist.
Hört der MP wirklich auf zu lesen oder liest er seinen kleinen Puffer nach wie vor unendlich weiter oder liest er die daten des letzten Bildes(er) dauernd .... ?

Du weist doch,
nur was man schwarz auf Weis, bzw. mit eigenen Augen sieht kann man akzeptieren, wenn man sonst nicht dran glauben will. :lol:
Die Hoffnung stirbt zuletzt :lol:
Ein Bekannter von mir ist auch der Meinung das es sehr stark am Linux, als nicht Echtzeit BS, oder an den Protokollen liegen kann. :wink:
Aber ich sags auch nochmal: Wenn der Prophet nicht zum berg kommt, muss der berg zum proheten kommen.
Also sollte man überlegen wie man die stockenden Daten so auf die Box bekommt, zum puffern, damit der MP stets sauber gefüllt werden kann.
(Ich weis ich bin unverbesserlich, :sorry:)
Bye
PetB
petb
Erleuchteter
Erleuchteter
Beiträge: 785
Registriert: Samstag 6. August 2005, 03:39

Beitrag von petb »

Torsten73 hat geschrieben:Hi,
kurz zum OT Timeshift, es gibt vielleicht doch Wege, auch wenn ich nicht genau weiß wie. Aber was geht ist die gleich Datei gleichzeitig auf mehreren Boxen sich anzuschauen (jede Box mit separatem Nic). Warum das beim R/W nicht gleichzeitig geht ist mir aber ein Rätsel.
http://forum.tuxbox-cvs.sourceforge.net ... 728#290728
Cu
Torsten
Ja, man kann auf 6 Boxen gleichzeitig die gleiche oder unterschiedliche Aufnahmen anschauen.
Das Problem sind wirklich nur r/w Zugriffe.
Während eines write ist die Datei halt kurz gelockt.
der Server kommt ja schnell genug hinterher um die Filepointer (bzw. den Kopf der Platte) zu positioneiren, wenn ers eh nicht noch im Ram hat.
Nur das protokoll muss dann halt kurz warten oder bei udp neu senden usw.
Und da meine ich halt wieder, mach ich nur den puffer auf der box groß genug, das ich vorlesen kann, jucken mich die aussetzer nicht, es sei denn das Protokoll oder/und das Handling des Buffers machen auf der Box so große Last und damit Probleme.

Timeshift jetzt mal aussen vor gelasen.
Mit niederratigen Streams, wenn ich die verbindung BOX zu Server bzw. Switch und dann Server nicht so stark belaste, kann der MP auch gut wiedergeben.
Auch wenn mehrere Aufnahmen laufen
Nicht jedoch wenns auf der 10MBit Strecke eng wird.
Dann müssen mehr daten laufen und dann kommt der MP durcheinander.
Sonst hat der MP mit den Aussetzern durch z.B. r/w Zugriffen usw. ja keine Probleme !

Noch zum Timeshift, das ja vom PC aus über CIFS geht:
Dann sollte eine Box über einen CIFS Mount das gleiche volbringen können.
Niederratigen Stream vorausgesetzt.
Wenn nicht, ist das Protokol auf der Box schlecht implementiert (oder doch der Puffer zu klein ?).

ich werde auch mal versuchen Server1 über nfs mit server2 zu verbinden und dann vom pc aus über server2 auf server1 zuzugreifen.
Wenns dann am nfs liegt müsste das ja dann auch Probleme machen, oder ?

Nochwas, der Player läuft ja immer eine gewisse Zeit und fängt dann erst an zu ruckeln. So als ob er dann den Puffer einholt.
bye
PetB
rolano
Erleuchteter
Erleuchteter
Beiträge: 601
Registriert: Montag 14. März 2005, 08:49

Beitrag von rolano »

...wenn es um Timeshift geht, sollte vielleicht hier weiter diskutiert werden: http://forum.tuxbox.org/forum/viewtopic ... =timeshift.
Ich denke es macht Sinn, die 2 Probleme nicht in einen Topf zu werfen (bisher sind es für mich 2 Probleme); bis der Beweis erbracht ist, dass sie vielleicht doch zusammenhängen - glauben tue ich das allerdings nicht.

Gruß
rolano
petb
Erleuchteter
Erleuchteter
Beiträge: 785
Registriert: Samstag 6. August 2005, 03:39

Beitrag von petb »

Hallo,

es scheint das wirklich nfs ein großen problem darstellt. :cry:
Unter CIFS geht Timeshift fast Problemlos.

Unt wenn ich tcp statt udp nehme geht der Mp auch besser.
Also kriegt er die Daten doch aufgrund der resends zu unregelmäßig, oder ?
bye
PetB
1 x DBOX2 Phillips, 1 x DBOX2 Nokia, 1 x DBOX2 Sagem, 100er Gibertini (Astra / Hotbird), NFS Server
PauleFoul
Wissender
Wissender
Beiträge: 1839
Registriert: Sonntag 17. August 2003, 01:39

Beitrag von PauleFoul »

Also ich sag jetzt einfach mal das der Puffer net richtig funktioniert.

Wenn ich einen Film starte passiert folgendes:

1. Puffer wird gefüllt. (Sehe ich an meinen Netzwerk-LED es der dbox)
2. Abspielen beginnt / Netzwerkübertragung geht aus.
3. Nach mehreren Sekunden (je nach Film) gehen die Netzwerk LED es wieder an und bleiben dann auch über den ganzen Film aktiv.

Daraus schließe ich, dass beim Start der Puffer gefüllt wird, dann wieder
geleert und dann die Übertragung LIVE abläuft.

Sieht man auch daran (und das ist eindeutig) dass die LED es erst mit
Filmende aus gehen (gleichzeitig). Wäre der Puffer voll müssten dies
ja vorher aus gehen.


Gruß
____Paule

PS: Der von mir verwendete Testfilm bringt das Netz keinesfalls an seine
Grenzen.
petgun
Tuxboxer
Tuxboxer
Beiträge: 5001
Registriert: Montag 11. November 2002, 15:26

Beitrag von petgun »

Hi,
nehmt's mir bitte nicht uebel, wenn ich doch noch mal was dazu schreibe.
PauleFoul hat geschrieben: 1. Puffer wird gefüllt. (Sehe ich an meinen Netzwerk-LED es der dbox)
2. Abspielen beginnt / Netzwerkübertragung geht aus.
3. Nach mehreren Sekunden (je nach Film) gehen die Netzwerk LED es wieder an und bleiben dann auch über den ganzen Film aktiv.

Daraus schließe ich, dass beim Start der Puffer gefüllt wird, dann wieder
geleert und dann die Übertragung LIVE abläuft.
..sensationeller pragmatischer Ansatz der imo nur diesen Schluss zulaesst...super Beweis!
digi_casi

Beitrag von digi_casi »

petgun hat geschrieben:Hi,
super Beweis!
un nu?
wo bleibt die verhaftung?
petgun
Tuxboxer
Tuxboxer
Beiträge: 5001
Registriert: Montag 11. November 2002, 15:26

Beitrag von petgun »

digi_casi hat geschrieben: wo bleibt die verhaftung?
;-) ich verhafte keinen, bin nur sehr dankbar, dass es jetzt endlich weiter gehen kann...und die Heiligsprechung des Movieplayer-Codes nicht richtig war.
PauleFoul
Wissender
Wissender
Beiträge: 1839
Registriert: Sonntag 17. August 2003, 01:39

Beitrag von PauleFoul »

petgun hat geschrieben:Hi,
nehmt's mir bitte nicht uebel, wenn ich doch noch mal was dazu schreibe.
PauleFoul hat geschrieben: 1. Puffer wird gefüllt. (Sehe ich an meinen Netzwerk-LED es der dbox)
2. Abspielen beginnt / Netzwerkübertragung geht aus.
3. Nach mehreren Sekunden (je nach Film) gehen die Netzwerk LED es wieder an und bleiben dann auch über den ganzen Film aktiv.

Daraus schließe ich, dass beim Start der Puffer gefüllt wird, dann wieder
geleert und dann die Übertragung LIVE abläuft.
..sensationeller pragmatischer Ansatz der imo nur diesen Schluss zulaesst...super Beweis!
Irgendwie bin ich mir jetzt net sicher wie Du das meinst... :gruebel:
PauleFoul
Wissender
Wissender
Beiträge: 1839
Registriert: Sonntag 17. August 2003, 01:39

Beitrag von PauleFoul »

digi_casi hat geschrieben:
petgun hat geschrieben:Hi,
super Beweis!
un nu?
wo bleibt die verhaftung?

??? Welchen Sinn hat dieses Posting ???
petgun
Tuxboxer
Tuxboxer
Beiträge: 5001
Registriert: Montag 11. November 2002, 15:26

Beitrag von petgun »

hi,
PauleFoul hat geschrieben:Irgendwie bin ich mir jetzt net sicher wie Du das meinst... :gruebel:
so wie es da steht! Du hast imo mit Deiner Beobachtung bewiesen, dass das Bufferhandling nicht richtig funktioniert. Wuerde es funktionieren, muessten die Netzwerk-Led's aehnlich unmotiviert wie zB. Disk-Led's aufflackern...also ohne Bezug zur Datenrate. BufferLow wird unterschritten >>> volle Kanne Netzwerktransfer bis der Buffer wieder voll ist....Film laeuft immer weiter...BufferLow Marke wird wieder unterschritten und das Spiel beginnt erneut. Der Netzwerktransfer muesste bei richtigem Bufferhandling so sein wie bei udrec...iss er aber nicht...spiegelt live die Datenrate wieder...shit, dass mir das nicht vorher aufgefallen ist ;-) Nee, mein Glueckwunsch zu dieser Beobachtung und der imo richtigen Schlussfolgerung.....jetzt kann ich auch den Peak (siehe erstes Diagramm) beim starten des Movieplayers einordnen...vollkommen klar!

cu,
peter
Zuletzt geändert von petgun am Donnerstag 23. Februar 2006, 18:53, insgesamt 1-mal geändert.
PauleFoul
Wissender
Wissender
Beiträge: 1839
Registriert: Sonntag 17. August 2003, 01:39

Beitrag von PauleFoul »

petgun hat geschrieben: Nee, mein Glueckwunsch zu dieser Beobachtung und der imo richtigen Schlussfolgerung.

cu,
peter
Danke.

Jetzt hoffe ich nur das es auch was bringt...


Gruß
____Paule
gmo18t
Erleuchteter
Erleuchteter
Beiträge: 553
Registriert: Freitag 27. Februar 2004, 14:30

Beitrag von gmo18t »

Hi,

wenn ich dann irgendwann dazu komme, werd ich ne völlige andere "Pufferstrategie" ausprobieren.
Aber weil es wegen des "WAF"-Faktors fast unmöglich ist, an der Box zu testen, kann das noch recht lange dauern.

Deshalb hier einmal die Theorie dazu, falls einer es vor mir realisieren kann (will):

1. wichtig ist die größe des DEMUX-Buffersm ! Da sollte ein relativ kleiner Wert gewählt werden (im Gegensatz zu dem wie's jetzt ist), um dem Phänomen, das PauleFoul beobachtet hat, Rechnung zu tragen -> könnte sein, daß ein neuerwrite solange hängt bis der Puffer entgültig leer ist obwohl die Daten eigentlich sofort reinpassen würden !? :gruebel:
Ich rechne mal mit einer idealen Größe von 16-32 KB, die im Weiteren auch als Segment-Größe bezeichnet werden soll, weil sie für den weiteren Verlauf eine tragende Rolle spielt.

2. Dann muß noch ein extra Thread für's Lesen (Reader) plaziert werden, wobei die Verbindung zw. ihm und dem Schreiben ins dvr-device (Writer) über eine "Pointer-Queue" gekoppelt wird.
Die Queue hat dann 3 Level, einmal für wenn genug drin ist (high-water), dann wenn's fast zu Ende geht (low-water) und noch einen ungefähr in der Mitte oder im oberen Drittel (optimal-water).
Die Queue wird gefüttert mit Pointer auf allokierte Speicherbereiche (RAM) die genau die oben erwähnte Segment-Größe haben !

3. Beim Startvorgang sollte der "Writer" erst mal schlafen. Der "Reader" füllt jetzt die Queue wie folgt bis zum "high-water":
-> allokiere jeweils ein Segment
-> fülle dies mit Daten via Netzwerk
-> reihe das Segment in die Queue ein
Wenn dann genug Segmente in der Queue drin sind (high), kann der Reader schlafen gehen, aber weckt vorher den Writer auf :)

4. Der Writer kann jezt ein Segment nach dem anderen aus der Queue holen in das dvr-device schreiben und den durch das Segment belegte Speicher wieder freigeben.
Sobald er bemerkt, daß die Queue unter den "optimal"-Level fällt, weckt er den Reader, so daß nun beide werkeln können und die Queue vor sich hin wabbert.

5. Schlafen geht der Reader also immer nur bei "high", der Writer immer nur bei "low". Für's Wecken gilt erstmal: Reader weckt Writer bei "high" (evtl. auch schon bei > "optimal") und Writer weckt Reader bei <= "optimal".

6. Beim minutenweisen Springen wird die Queue kmpl. geleert und es geht wieder los wie im "Startfall".

Die Queue-Geschichte sollte neu geproggt werden, das geht mit OO prima (evtl. mach den Code dazu demnächst), damit kein unnötiger Balast drin ist.
Die Thread Synchronistaion geht wie üblich über "Mutex" und "Conditions"...

Diese Konzept schlummert jetzt schon eine Weile in meinem Kopf, aber komme halt einfach nicht dazu, es zu realsieren - vor allem weil das Testen mit der Box wegen "WAF" unmöglich ist.

Egal wie's ausgeht, in jedem Fall hat man den Gewinn, daß der MP rechtzeitig in einen definierten Pausezustand (Bild anhalten und ne Puffern Box angzeigen) bringen kann, bis die Queue wieder einen vernünftigen Level hat.
Das geht deshalb, weil man ja über den Low-Level feststellen, kann, daß der Writer zu schnell ist. Man wählt für low am Besten 2 aus, dann kann man noch einmal in den dvr-Buffer einschreiben, bevor man dan den Demuxer/Decoder anhält, kann evtl etwas zeitkrtisch werden bei 16-32k Segmentgröße.
Aber das ist dann später sowieso experimentell festzulegen, welche Werte für das "Queue-Controlling" usw. am Besten sind :)

Hoffe, ich hab nix vergessen. Aber prinzipiell läuft so ne "Wabber-Queue" prima, hab da bei anderen Projekten gute Erfahrung gemacht.

na dann viel Spaß beim diskutieren !

- GMo -
PauleFoul
Wissender
Wissender
Beiträge: 1839
Registriert: Sonntag 17. August 2003, 01:39

Beitrag von PauleFoul »

@gmo18t

Also da biete ich mich doch gleich mal als Betatester an... :D :D


Gruß
____Paule
Zuletzt geändert von PauleFoul am Donnerstag 23. Februar 2006, 19:42, insgesamt 1-mal geändert.
petgun
Tuxboxer
Tuxboxer
Beiträge: 5001
Registriert: Montag 11. November 2002, 15:26

Beitrag von petgun »

PauleFoul hat geschrieben:Jetzt hoffe ich nur das es auch was bringt...
...ich auch. Bei einem funktionierenden Ringbuffer und sehr kleinen Transferpaketen und wenn der Buffer quasi immer voll ist, wuerde die Netzwerktransferrate/Fuellrate der zeitlich versetzten 'Entleerungsrate' des Buffers entsprechen..und bei der Abtastrate fuer das Netzwerkdiagramm wuerde man die theoretischen 100% Spitzen mit nachfolgendem Leerlauf nicht sehen. Warum man keinen Debugcode einbaut/einbauen kann, um evtl Bufferunderruns zu erkennen, koennen vielleicht die Entwickler erklaeren...wenn sie noch wollen ;-)

<edit>
..gerade erst die Antwort von gmo18t gelesen...hat sich mit meinem Posting hier ueberschnitten...danke! 'Wabber-Queue' klingt geil :lol:
</edit>
wolgade
Semiprofi
Semiprofi
Beiträge: 1313
Registriert: Donnerstag 2. Dezember 2004, 00:18

Beitrag von wolgade »

Ach du Scheiße! (sorry)

Ich gebe zu, ich hab das nicht geglaubt, was PauleFoul da geschrieben hat. Das wollte ich doch mal sehen! Hab ich jetzt, war auch ganz einfach, da der Switch, der Dbox und Eisfair miteinander verbindet, direkt unter der Dbox steht. Auch die Netzwerk-LED des Eisfair ist ganz gut zu beobachten. Um es kurz zu machen, exakt das was PauleFoul beschreibt:

1. Wiedergabe wird gestartet, Bildschirm ist noch dunkel, hektisches Geblinke.

2. Wiedergabe geht los. Keine Netzwerktätigkeit für eine ganze Weile.

3. Netzwerktätigkeit setzt irgendwann ein. Heftigkeit korrespondiert mit der Videodatenrate, die ich dank meiner NFS-Optimierungssessions mittlerweile ganz gut aus dem Bildinhalt abschätzen kann.

4. Wenn man die Datei bis zum bitteren Ende spielt, enden Wiedergabe und Netzwerktätigkeit gleichzeitig.

Ja, haben wir denn alle Tomaten auf den Augen gehabt? Da optimier ich mein Netzwerk wie ein Besessener, hab den Switch direkt unter der Dbox stehe und krieg das nicht mit. Das ist meines Wissens der erste Bug in Neutrino mit eigener Kontroll-LED.

Vielleicht sollte man die sehr interessante Erkenntnis noch mal in einen anderen Thread schreiben. Auf den dreizehn Seiten hier geht die unter.

Ach so, ja: Dank an PauleFoul. Hätte jeder längst merken müssen, hat aber keiner getan.

Wieso habe ich das Gefühl, daß mich mein Switch angrinst?
rolano
Erleuchteter
Erleuchteter
Beiträge: 601
Registriert: Montag 14. März 2005, 08:49

Beitrag von rolano »

PauleFoul hat geschrieben:Hab mal aus Petgun es Teststreifen einen 22MB Stück rausgeschnitten
(....) Aus dem Speicher heraus wird der
Teststreifen auf jedenfall ohne den kleinsten Fehler/Ruckler abgespielt.
petgun hat geschrieben: (....) volle Kanne Netzwerktransfer bis der Buffer wieder voll ist....Film laeuft immer weiter...BufferLow Marke wird wieder unterschritten und das Spiel beginnt erneut. Der Netzwerktransfer muesste bei richtigem Bufferhandling so sein wie bei udrec...iss er aber nicht...spiegelt live die Datenrate wieder...shit, dass mir das nicht vorher aufgefallen ist
....und jetzt bin ich vollkommen irritiert......(auch vor dem Hintergrund von gmo18 es sehr vielversprechender Theorie) - warum wird der Teststreifen aus dem RAM sauber gespielt? :gruebel: Bisher war ja einhelliger Tenor, dass - ein vernünftiges Netzwerk vorausgesetzt - eben dieses NICHT für das Problem verantwortlich/mitverantwortlich ist.....
wolgade hat geschrieben:Ach du Scheiße! (sorry)

(........)

Ach so, ja: Dank an PauleFoul. Hätte jeder längst merken müssen, hat aber keiner getan.
Wieso habe ich das Gefühl, daß mich mein Switch angrinst?
....womit Du meine Gedanken auf den Punkt gebracht hast - ich habe eine (allerdings recht dürftige) Entschuldigung: Switch und NAS sind so im Wohnzimmer verbaut, dass man sie nicht sieht.......und würde ich sie sehen, hätte ichs auch nicht gemerkt...... :evil:
Also da biete ich mich doch gleich mal als Betatester an...
.... ich auch (ich kann allerdings keine Images selber bauen...)
petgun
Tuxboxer
Tuxboxer
Beiträge: 5001
Registriert: Montag 11. November 2002, 15:26

Beitrag von petgun »

...warum wird der Teststreifen aus dem RAM sauber gespielt?
mein Teststreifen ist ungeeignet und kann imo auch nicht fehlerfrei aus dem Ram abgespielt werden...der Womble Mpeg Video Wizard scheint bei *.ts Ausgabe nicht Movieplayer kompatibel zu muxen wenn die Audiospur >192kbps ist.
rolano
Erleuchteter
Erleuchteter
Beiträge: 601
Registriert: Montag 14. März 2005, 08:49

Beitrag von rolano »

petgun hat geschrieben:
...warum wird der Teststreifen aus dem RAM sauber gespielt?
mein Teststreifen ist ungeeignet und kann imo auch nicht fehlerfrei aus dem Ram abgespielt werden...der Womble Mpeg Video Wizard scheint bei *.ts Ausgabe nicht Movieplayer kompatibel zu muxen wenn die Audiospur >192kbps ist.
...tja, das dachte ich auch - paule hat aber berichtet, dass er ein Teil aus DEINEM "Womble-Schnipsel" fehlerfrei abgespielt hat....und eben das irritiert mich (nach wie vor :gruebel: ). Das "bereinigte" Testfile ist ja ohnehin kein Problem....