Größerer Buffer beim Movieplayer

Beitrag von **teddy278** » Montag 13. Februar 2006, 09:59

Hallo.

petgun hat geschrieben:...na dann iss ja alles klar...viel Erfolg fuer dein eigenes Kaemmerleinprojekt...hoeher/schneller/weiter/geheim/vaporware/closet-sourceÂ©...Du bist mein Held!

Vielleicht hast Du mich mißverstanden: Ich wollte mich nicht als jemand aufspielen, der alles besser kann als der Rest der Welt. Das kann ich ja gerade nicht, sonst hätte ich mir meinen Feature Request gespart und allen gezeigt wie's geht.

Daß Anfragen oft erst nach vehementer Verteidigung durch denjenigen, der sie vorschlägt, überhaupt als Möglichkeit akzeptiert werden, ist aber sicher nicht nur mir aufgefallen. Ich persönlich finde das schade, aber es ist Sache der Devs, wie sie mit externem Input umgehen, und ich möchte ihnen da auch keinerlei Vorwurf machen. Es ist ihr Projekt.

Paradebeispiel ist für mich immer noch der Aufnahmebuffer - ewig abgewiesen, weil's angeblich nichts bringt, untermalt mit unendlichen Beispielen, und am Ende wird's umgesetzt und rennt wie Sau.

Bye,
Christian

Beitrag von **Barf** » Montag 13. Februar 2006, 10:26

CVS-Code auschecken. Die Ziele

Code: Alles auswählen

#define RINGBUFFERSIZE 348*188*10

in movieplayer.cpp ändern. (Auch ohne umfassende Programmiererfahrung machbar.) Kompilieren. Testen.Ergebnisse posten.

Was ist damit so schwierig?

Beitrag von **petgun** » Montag 13. Februar 2006, 10:55

teddy278 hat geschrieben:Paradebeispiel ist für mich immer noch der Aufnahmebuffer - ewig abgewiesen, weil's angeblich nichts bringt, untermalt mit unendlichen Beispielen, und am Ende wird's umgesetzt und rennt wie Sau.

ja, ein mir gut bekanntes 'Paradebeispiel'. Es ist aber auch ein Paradebeispiel dafuer, dass User-Requests funktionieren wenn man ueberzeugend genug ist...uU. braucht man sehr viel Geduld und auch ein dickes Fell...so schnell wuerde ich an Deiner Stelle jedenfalls nicht resignieren ;-)

--
Ever try. Ever fail. No matter.
Try again. Fail again. Fail better.

Beitrag von **teddy278** » Montag 13. Februar 2006, 10:58

Hallo.

Barf hat geschrieben:Was ist damit so schwierig?

Im Prinzip nichts, aber... der Aufwand erscheint mir für eine kleine Änderung mit zweifelhaftem Ergebnis recht groß, wenn man sonst nichts in dem Bereich gemacht hat. Nach dieser Diskussion habe ich die Befürchtung, daß es nicht bei der kleinen Änderung bleibt... Wenn eh alles schon mal auf der Platte liegt, finde ich sicher noch was, wo ich irgendwas dran drehen könnte. Ich kenne mich.

Und schon ist wieder eine Woche rum und meine Freundin siezt mich beim Abschied. Nee, für's Fernsehen muß eine Out-of-the-Box-Lösung her, sonst bastel ich mich noch tot.

Bye,
Christian

Beitrag von **Tommy** » Montag 13. Februar 2006, 11:01

Barf hat geschrieben:CVS-Code auschecken. Die Ziele
Code: Alles auswählen
#define RINGBUFFERSIZE 348*188*10
in movieplayer.cpp ändern. (Auch ohne umfassende Programmiererfahrung machbar.) Kompilieren. Testen.Ergebnisse posten.

Was ist damit so schwierig?

Das ist doch mal ein Wort

Habs gefunden unter http://cvs.tuxbox-cvs.sourceforge.net/c ... &view=auto wenn jemand reinschauen will. Welche Werte machen da Sinn bzw sind unkritisch. Wofür genau stehen die Werte? Ich kann das heute abend versuchen zu ändern und ein squashfs zum testen bauen.

Beitrag von **petgun** » Montag 13. Februar 2006, 11:07

...naja, wenn Dir schon eine Woche 'basteln' und ein wenig diskutieren zuviel ist und Du der Meinung bist: 'für's Fernsehen muß eine Out-of-the-Box-Lösung her', dann bist Du hier wirklich flasch und schaust Dich wirklich besser nach einem out of the box DVB-C Festplattenreceiver um, der Deinen Erwartungen entspricht.

Beitrag von **teddy278** » Montag 13. Februar 2006, 11:08

Hallo.

Tommy hat geschrieben:Ich kann das heute abend versuchen zu ändern und ein squashfs zum testen bauen.

Klingt gut... Habe zwar die Rücksendung meines NAS schon angeleiert und liebäugele mit einem Topfield, aber noch habe ich es ja nicht zurückgeschickt.

Bye,
Christian

Beitrag von **Tommy** » Montag 13. Februar 2006, 11:14

Bitte versteht mich nicht falsch aber ich will nichts verändern was mir nachher um die Ohren fliegt. Solange ich nicht weis wofür die Werte im einzelnen stehen fasse ich nix an. Ich kenne mich mit C nicht aus und schon gar nicht mit dem source des MP. Wenn mir einer sagt "ändere die Zeile in...." kann ich das machen aber ohne Gewähr. Interessant wäre es allmal da ich 64MBRam in allen Boxen habe ob man den RB "Megagroß" machen kann (just for testing)

Beitrag von **teddy278** » Montag 13. Februar 2006, 11:18

Hallo.

petgun hat geschrieben:eine Woche 'basteln' und ein wenig diskutieren

Auch wenn ich mit dem Diskutieren erst kürzlich angefangen habe: Basteln tue ich schon länger. Ich habe versucht, meine dbox über WLAN mit verschiedenen Access Points / Adaptern an den PC anzubinden (Reinfall - eh klar), ich habe mit SFU herumexperimentiert (mit und ohne WLAN, wobei es ohne WLAN lief aber nicht praktikabel war), ich habe meine Linkstation mal drangehängt (fatal), ein Powerbook habe ich auch mal versucht als "Server" einzusetzen, und jetzt kämpfe ich mit dem Claxan-NAS (das - nebenbei bemerkt - äußerst leistungsschwach zu sein scheint). Irgendwas hakt immer.

Wenn mir jetzt ein Entwickler sagt, daß mein aktuelles Problem nicht gelöst werden kann, dann gebe ich halt irgendwann auf. Wobei ich den oben angesprochenen Test sicher noch mitnehme... Ein bissel neugierig ist man ja schon. Habe da auch eine sehr schöne Testaufnahme - permanent so 2-3 MBit, und irgendwann rauscht ein Zug durch's Bild. Das anschließende Interview ist dann nicht mehr lippensynchron.

Mein Ziel ist eine feierabendkompatible Lösung, was nicht heißt, daß der Rest mich nicht interessiert.

Ich muß weg.

Bye,
Christian

Beitrag von **Barf** » Montag 13. Februar 2006, 11:41

teddy278 hat geschrieben: Wenn mir jetzt ein Entwickler sagt, daß mein aktuelles Problem nicht gelöst werden kann, dann gebe ich halt irgendwann auf.

Das Feine mit freier Software, oder wie mann oft jetzt sage "Open Source", ist dass mann sich damit nicht abfinden muss. Einfach selbst testen! Vgl. Microsoftproduke. Kann mann dann sagen, "mit meine Werte geht es 48% besser" hat mann völlig andere Argumente, als durch "nörgeln".

TEAM = Toll: Einen Anderen Macht's

Beitrag von **petgun** » Montag 13. Februar 2006, 11:45

teddy278 hat geschrieben:Habe da auch eine sehr schöne Testaufnahme - permanent so 2-3 MBit, und irgendwann rauscht ein Zug durch's Bild. Das anschließende Interview ist dann nicht mehr lippensynchron.

..naja, warum man dann glaubt, dass ein vergroesserter Ringbuffer dieses 'Problem' loesen soll, kann ich auch mit viel Phantasie nicht nachvollziehen....mit Deiner 'schoenen Testaufnahme' hast Du einen leichten Vorgeschmack auf die gleichen Probleme wie ich sie hier versucht habe grafisch verstaendlich darzustellen...nur bei einer 'etwas' hoeheren Datenrate.

Tip: Schreiben Sie eine Mail/PN an Herrn 'gagga' vielleicht nuetzt das ja was....es kann aber sein dass Sie gesagt bekommen, dass er es vorzieht bei einem anderen Projekt (wo es weniger undankbare, staendig noergelnde unzufriedene User gibt) seine Faehigkeiten unter Beweis zu stellen...

Beitrag von **petb** » Montag 13. Februar 2006, 12:25

Tommy hat geschrieben:Bitte versteht mich nicht falsch aber ich will nichts verändern was mir nachher um die Ohren fliegt. Solange ich nicht weis wofür die Werte im einzelnen stehen fasse ich nix an. Ich kenne mich mit C nicht aus und schon gar nicht mit dem source des MP. Wenn mir einer sagt "ändere die Zeile in...." kann ich das machen aber ohne Gewähr. Interessant wäre es allmal da ich 64MBRam in allen Boxen habe ob man den RB "Megagroß" machen kann (just for testing)

Sehe ich auch so.
Im Normalfall gibt man ja die Werte deshalb in solch einem Format an
weil es Potenzen von Basisgrößen sind oder ähnliches.

Einfach multipliziert sind es 654240 das deckt sich aber auch so schon nicht mit dem was der DEV mal sagte von wegen 1 MB Puffer sind bereits eingebaut.
Oder ist das schon ein höherer Wert ?

Steht die 10 z.B. für Paketsize des demuxxers oder die 188 dafür ?
Nicht das dann "ein nicht sinvolles vielfaches" nichts bringt ?
Oder ist das 348*188 eine Bildauflösung des Demuxxers und wird dann einfach 10fach gepuffert ?

Wie gesagt, ich würde da jetzt auch nichts ändern ohne zu wissen wie sich das zussammensetzt.
Kann mand das im Source nicht erkennen (Ich weis, ich hab gut reden

)
Bye
PetB

Beitrag von **teddy278** » Montag 13. Februar 2006, 12:29

Hallo.

Barf hat geschrieben:
teddy278 hat geschrieben: Wenn mir jetzt ein Entwickler sagt, daß mein aktuelles Problem nicht gelöst werden kann, dann gebe ich halt irgendwann auf.
Das Feine mit freier Software, oder wie mann oft jetzt sage "Open Source", ist dass mann sich damit nicht abfinden muss. Einfach selbst testen! Vgl. Microsoftproduke. Kann mann dann sagen, "mit meine Werte geht es 48% besser" hat mann völlig andere Argumente, als durch "nörgeln".

Wenn ich nörgele, dann höchstens an der lahmen dbox.

Mein "kann" war als "kann" gemeint, nicht als "will". Wobei ich auch für letzteres Verständnis habe bei einem Hobby-Projekt, allerdings würde ich dann nicht so schnell aufgeben.

Das mit dem "selbst testen" ist eine Frage der Ressourcen. Ich müßte mir den ganzen Kram runterladen, Compiler installieren, mich erstmal damit auseinandersetzen wie das überhaupt funktioniert... während das für einen Entwickler alles ganz einfach ist, erstens wegen der Übung, und zweitens weil die "Infrastruktur" schon steht. Mein Dank geht an Dich für die Idee und an Tommy, wenn er's implementiert und ich damit dann mal testen kann.

petgun hat geschrieben:
teddy278 hat geschrieben:Habe da auch eine sehr schöne Testaufnahme - permanent so 2-3 MBit, und irgendwann rauscht ein Zug durch's Bild. Das anschließende Interview ist dann nicht mehr lippensynchron.
..naja, warum man dann glaubt, dass ein vergroesserter Ringbuffer dieses 'Problem' loesen soll, kann ich auch mit viel Phantasie nicht nachvollziehen....mit Deiner 'schoenen Testaufnahme' hast Du einen leichten Vorgeschmack auf die gleichen Probleme wie ich sie hier versucht habe grafisch verstaendlich darzustellen...nur bei einer 'etwas' niedrigeren Datenrate.

Ich dachte, das wäre nach meinem Ausgangsposting klar:

Bitrate 2-3 MBit -> alles wunderbar, dbox hat sogar noch Zeit, den Puffer aufzufüllen.

Zug rauscht durchs Bild -> Bitrate geht über die Fähigkeiten der Netzanbindung -> dbox ist auf Puffer angewiesen.

Wenn das Problem in der Breite der Netzanbindung liegt, wird es durch einen größeren Puffer gelöst und das von Dir angesprochene Problem bei der Resynchronisation tritt gar nicht erst auf. Wenn's an der Verbindung CPU -> Demuxxer liegt, wird das Problem nicht dadurch gelöst.

Diese Testaufnahme stammt übrigens nicht von Premiere, sondern vom SWR, wo man anscheinend ebenfalls zeitweise die Bitraten "etwas" hochdreht.

petgun hat geschrieben:undankbare, staendig noergelnde unzufriedene User

Gibt es einen Grund für Deine Beleidigungen oder meintest Du nicht mich?

Bye,
Christian

Beitrag von **petgun** » Montag 13. Februar 2006, 12:44

teddy278 hat geschrieben:
petgun hat geschrieben:undankbare, staendig noergelnde unzufriedene User
Gibt es einen Grund für Deine Beleidigungen oder meintest Du nicht mich?

..man oh mann..ich will hier keinen beleidigen...der gesamte 'Tip:....' ist lediglich ein Ausdruck meines Frustes bezogen auf den Movieplayer mit samt seinem Entwickler und dessen Wassertraegern unter den Usern und Entwicklern...da beisse ich mir schon laenger die Zaehne dran aus....imo eins der wenigen Teile hier die absolut keine Kritik vertragen koennen. Ich haette die vermutliche Aussage aus dem 'Tip' auch quoten koennen...kann man hier irgendwo im Forum nachlesen...die war von gagga an mich gerichtet und sollte die Begruendung fuer seinen damaligen Abgang hier gewesen sein...iss doch eine nette Legende die immer wieder gerne genommen wird, oder?

Ich wuensche Dir/Euch jedenfalls viel Erfolg auf dem Weg zu einem neuen/fehlerbereinigten Movieplayer.

Beitrag von **Papst** » Montag 13. Februar 2006, 14:55

@Barf
Könnte es nicht auch dieser Buffer sein?:

Code: Alles auswählen

.
.
.
//===========================
//== PlayFile Thread Stuff ==
//===========================
#define PF_BUF_SIZE   (800*188)
.
.
.

Steht ein bisschen weiter unten.

Beitrag von **teddy278** » Montag 13. Februar 2006, 15:19

Hallo,

ich bin auch gerade dabei, mich mal etwas in das Programm einzulesen...

Soweit ich sehe, wird der "Ringbuffer" nur beim Abspielen eines Streams verwendet. Bei mp_PlayFileThread greift offenbar PF_BUF_SIZE, und davon bei .TS auch nur 1/4. Was vielleicht auch ganz gut ist: Wenn ich das mit meinen arg begrenzten

C-Kenntnissen richtig lese, wird stets ein Block in der Größe von PF_BUF_SIZE / 4 gelesen und dann gleich wieder weggeschrieben. Ohne zusätzlichen Puffer.

EDIT: Oh, habe doch noch einen Buffer entdeckt.

Wußte doch, warum ich mich da eigentlich nicht reinwursteln wollte.

Bye,
Christian

digi_casi · Beitrag von **digi_casi** » Montag 13. Februar 2006, 15:20

ich denke, dass die hardware der dbox einfach zu schwach ist. selbst die dreambox mit wesentlich staerkere hardware hat bei hohen datenraten muehe...

Beitrag von **petgun** » Montag 13. Februar 2006, 15:27

digi_casi hat geschrieben:ich denke, dass die hardware der dbox einfach zu schwach ist. selbst die dreambox mit wesentlich staerkere hardware hat bei hohen datenraten muehe...

...imo flasch. Im normalen TV-Betrieb gibt es ja auch keine Aussetzer/Bildhaenger/Tonstoerungen und an der zu hohen Datenrate liegt es in meinem Beispiel und imo auch bei teddy278 nicht...und die CPU-Auslastung habe ich auch schon laengere Zeit waehrend abspielen mit dem Movieplayer beobachet...daran liegt es mit Sicherheit nicht. Vielleicht zu niedrige Prioritaaet des Neutrino-Task (mit Movieplayer)...weiss ich nicht...glaube ich aber nicht...da stimmt einfach was nicht beim Handling der Audio-Streams.

Beitrag von **teddy278** » Montag 13. Februar 2006, 16:22

Hallo.

petgun hat geschrieben:da stimmt einfach was nicht beim Handling der Audio-Streams.

Du immer mit Deinen Audio-Streams.

Soweit ich sehe passiert da während des Abspielens nicht allzuviel mit den Daten zwischen

Code: Alles auswählen

rd	= read(ctx->inFd, ctx->dvrBuf, rSize);

und

Code: Alles auswählen

write(ctx->dvr, ctx->dvrBuf, rd);

Das Problem, das ich zu sehen glaube ist, daß der Buffer nur im selben Maß gefüllt wird, in dem er auch wieder ausgeleert wird, und das auch nur zu einem Bruchteil von PF_BUF_SIZE. Einzig bei einer Resynchronisation wird die doppelte Menge gelesen. Nach dem Lesen wird stets komplett geschrieben, bevor der nächste Block gelesen wird. Stream halt.

Bye,
Christian

Beitrag von **gmo18t** » Montag 13. Februar 2006, 16:52

teddy278 hat geschrieben: ... Soweit ich sehe passiert da während des Abspielens nicht allzuviel mit den Daten zwischen
Code: Alles auswählen
rd	= read(ctx->inFd, ctx->dvrBuf, rSize);
und
Code: Alles auswählen
write(ctx->dvr, ctx->dvrBuf, rd);

Also nicht viel Möglichkeiten, um fette Bugs zu verstecken

Das Problem, das ich zu sehen glaube ist, daß der Buffer nur im selben Maß gefüllt wird, in dem er auch wieder ausgeleert wird, und das auch nur zu einem Bruchteil von PF_BUF_SIZE. Einzig bei einer Resynchronisation wird die doppelte Menge gelesen. Nach dem Lesen wird stets komplett geschrieben, bevor der nächste Block gelesen wird. Stream halt.

ja der dvrBuf, in den mit "write" geschrieben wird, ist tatsächlich um Einiges größer als die Häppchen, die gelesen werden.
Aber hast du auch schonmal an "nonblocking write" gedacht, denn genau das ist hier der Fall !
D.h. der write()-call kommt sofort zurück und es kann schon wieder der nächste Happen gelesen werden

Also bei "geeigneten" Bitraten wird der Puffer (dvrBuf) somit schön aufgefüllt (auch mit kleineren Häppchen).
Wenn er dann mal voll sein sollte dann "blockt" write() solange bis wieder Platz ist.

Wäre nicht weiter schlimm, wenn folgende entscheidende Frage beantwortet wäre:
Wieviel Platz wird im Treiber "verputzt" bis "Platz vorhanden" gemeldet wird, also der write()-Aufruf zurückkehrt ?
Etwa der ganze Puffer ??? (das wäre dann ein Ruckelgrund).

Nun da keine Möglichkeit gegeben ist, den freien Platz im Puffer zu überprüfen,
kann man auch das read/write-Handling nicht adequat implementieren,
um solch eine mißliche Situation zu vermeiden

- GMo -

Beitrag von **petgun** » Montag 13. Februar 2006, 16:56

teddy278 hat geschrieben:Das Problem, das ich zu sehen glaube ist, daß der Buffer nur im selben Maß gefüllt wird, in dem er auch wieder ausgeleert wird, und das auch nur zu einem Bruchteil von PF_BUF_SIZE...

..dann eben ein genereller Fehler beim Bufferhandling...aber nix ko-maessiges von wegen zu hoher Datenrate/CPU zu schwach/????

@gmo18t
..und Du siehst keine Moeglichkeit temp. ein paar Zeilen Debug-Code einzubauen um dieses Bufferhandling zu ueberpruefen/transparent zu machen/evt. Fehler zu entdecken?

Ich wuensche Dir und allen die der Ehrgeiz gepackt hat, wirklich viel Erfolg bei der Suche und bin sehr gespannt wie das hier ausgeht.

Beitrag von **teddy278** » Montag 13. Februar 2006, 17:17

Hallo.

gmo18t hat geschrieben:Also nicht viel Möglichkeiten, um fette Bugs zu verstecken

Bei meinen C-Kenntnissen schon.

gmo18t hat geschrieben:ja der dvrBuf, in den mit "write" geschrieben wird, ist tatsächlich um Einiges größer als die Häppchen, die gelesen werden.

OK - wieviel MB sind es denn?

Es ginge mir ja um einen üppigen Puffer, um Spitzen abzufangen wenn der NIC nicht nachkommt. Meine Vermutung ist, daß dvrBuf nicht allzu großzügig bemessen ist (und sich nicht unbedingt leicht vergrößern läßt, insbesondere im Hinblick auf Boxen mit geringem Arbeitsspeicher).

gmo18t hat geschrieben:Wäre nicht weiter schlimm, wenn folgende entscheidende Frage beantwortet wäre:
Wieviel Platz wird im Treiber "verputzt" bis "Platz vorhanden" gemeldet wird, also der write()-Aufruf zurückkehrt ?
Etwa der ganze Puffer ??? (das wäre dann ein Ruckelgrund).

Es würde ja schon "reichen", wenn write() zwar sofort zurückkehrt wenn wieder etwas Platz ist, dann aber weiterhin eine anspruchsvolle Szene kommt, die dvrBuf schneller leersaugt als von read() nachgeladen werden kann.

gmo18t hat geschrieben:Nun da keine Möglichkeit gegeben ist, den freien Platz im Puffer zu überprüfen,
kann man auch das read/write-Handling nicht adequat implementieren,
um solch eine mißliche Situation zu vermeiden

Wie wär's wenn man read und write in unterschiedliche Threads legt?

Read liest fröhlich vor sich hin, solange Platz im (vorgelagerten, neu zu schaffenden) Buffer ist, und write schreibt so schnell es halt geht die Daten weg, wenn noch welche im Buffer liegen. Wenn write dann warten muß, bis dvrBuf wieder leer ist stört's nicht weiter. Multithreading müßte die dbox doch unterstützen, wenn ich den Text richtig interpretiere?

Bye,
Christian

Beitrag von **just_me** » Montag 13. Februar 2006, 17:24

teddy278 hat geschrieben:
gmo18t hat geschrieben:Nun da keine Möglichkeit gegeben ist, den freien Platz im Puffer zu überprüfen,
kann man auch das read/write-Handling nicht adequat implementieren,
um solch eine mißliche Situation zu vermeiden
Wie wär's wenn man read und write in unterschiedliche Threads legt? Read liest fröhlich vor sich hin, solange Platz im (vorgelagerten, neu zu schaffenden) Buffer ist, und write schreibt so schnell es halt geht die Daten weg, wenn noch welche im Buffer liegen. Wenn write dann warten muß, bis dvrBuf wieder leer ist stört's nicht weiter. Multithreading müßte die dbox doch unterstützen, wenn ich den Text richtig interpretiere?

Müssen nicht unbedingt verschiedene Threads sein: 'select' tuts u.U. auch. Oder fcntl mit O_NONBLOCK.

Beitrag von **petgun** » Montag 13. Februar 2006, 17:27

teddy278 hat geschrieben:Du immer mit Deinen Audio-Streams.

...was wuerdest Du sagen wenn so ein ruckelnder Stream, neu aufbereitet _ohne_ Audio-Stream nicht mehr ruckeln wuerde? Kannst Du leicht selbst testen....ich werde das heute Abend mit dem meinem hier verwendeten Testfile machen und das Ergebnis hier posten.

Schoener Tag heute...ich bin froh dass die heilige Kuh 'Movieplayer' endlich gestorben ist und Fehler bei der Implementierung/Konzept zumindest in Erwaegung gezogen werden.

--
Le Roi est mort, vive le Roi!
Der König ist tot, es lebe der König!

Beitrag von **teddy278** » Montag 13. Februar 2006, 17:47

Hallo.

just_me hat geschrieben:Müssen nicht unbedingt verschiedene Threads sein: 'select' tuts u.U. auch. Oder fcntl mit O_NONBLOCK.

Und weil Du sowas weißt und ich nicht bin ich auch der Meinung, daß ich zur Implementierung eines Buffers ungeeignet bin. Ist einfach nicht meine Welt...

petgun hat geschrieben:Schoener Tag heute...ich bin froh dass die heilige Kuh 'Movieplayer' endlich gestorben ist und Fehler bei der Implementierung/Konzept zumindest in Erwaegung gezogen werden.

Wenn es so ist, wie ich es mir denke, würde ich nicht unbedingt von einem "Fehler" sprechen. Es gibt halt noch was zu verbessern... wo gibt es das nicht?

Bye,
Christian