nicht zwangsläufig - siehe meinen Durchlauf. Die Datei mit *_org entspricht deiner Datei. Die mit Foobar ist meine mit VBR-Header-Fix. Die anderen habe ich unterschiedlich mit MP3-Diag bearbeitet. Fraglich ist, wenn ich ein x-beliebiges Album 10mal hochlade ob es dann auch auftritt.
Ich habe bei mir noch nicht so viele Dateien über webupload hochgeladen - somit kann ich darüber im Allgemeinen nicht viel zur Häufigkeit sagen
Das ist nett - danke 
So, ich muss erst mal ins Bett 
@joker, Danke für die ausfürhliche Analyse!
Chunk [not ok] als Ursache fällt raus, in Deinem Log werden alle Chunks übermittelt.
Die RSSI: -34 dBm sind ja stark, ist Deine Hütte irgendwie verstrahlt? Schlechte WLAN-Verbindung fällt also auch raus.
Die Upload-Raten sind aber unterirdisch. Normalerweise sollten es schon >300Kb/s sein. Ist das wirklich master mit Arduino 1.0.6? Kannst Du in der Weboberfläche unter Info sehen:
Frage nur weil da war ich letzte Woche auch im falschen Film…
Du lädst einen Ordner hoch? Hat sich mir aus dem Log nicht auf die Schnelle erschlossen.
ganz schön frech
Sagen wir es mal so…ich wohne in einem Altbaugebiet und habe 51 Wlans anliegen. Ob meine tolle LED-Lampe stört, dass weiß ich nicht. Vielleicht liegt das auch an meiner alten Fritzbox
Ich kann das ganze morgen mal auf Arbeit mitnehmen und da noch mal schauen.
Ja, ist richtig. Es müsste schon beides gehen. Liegt garantiert daran wie ich die Karte partitioniert hab. Braucht wahrscheinlich ein DOS compatibility flag und mein Linux hat das nicht drauf gemacht oder irgendwie sowas. Ist aber aktuell nicht tragisch, das bekomm ich schon hin, das ist hier offtopic da es ja bei Anderen mit korrekt partitionierten/formatierten Karten genau so auftritt. Für den Moment kopiere ich ausschließlich mit dem Webserver drauf.
[ 32302 ] Bytes [ok] 2277376 / [not ok] 0, Chunks: 556Ja, definitiv. Ich kann es mit den selben mp3 dateien immer wieder reproduzieren. In der Regel bekomme ich das geworkaroundet indem ich die Datei ein mal durch ffmpeg jage. Das verändert die Datei genug, dass es nicht mehr passiert. Ein mal hab ich es allerdings auch schon die andere Richtung geschafft. Eine Datei die vorher problemlos funktionierte, hatte nach dem re-codieren mit ffmpeg danach das Verhalten. Egal wie oft ich sie neu drauf lade.
Und: ich kann bestätigen, dass der patch in Audio.cpp von @Joe91 das auch bei mir erfolgreich workaroundet.
Und hier noch ein Exemplar mit dem ich es Reproduzieren kann, da hier ja nach Abwechslung gefragt wurde (wie lange man die letzten 10 Sekunden dieses Liedes im Loop aushält sei mal dahin gestellt :D):
testfile.zip (2,1 MB)
Ich habe leider privat gerade zu viel um die Ohren, weswegen ich MQTT noch nicht angegangen habe. Bin mir dessen jedoch bewusst, dass hier noch was offen ist - sorry.
Ansonsten Dank schon mal an alle für die emsige mp3-Analyse hier 
.
Überhaupt kein Thema. Das wollte ich damit nicht sagen. Wie gesagt, Arduino2 klappt wunderbar für mich, mit allem drum und dran.
Ich konnte den Web-Upload-Fehler jetzt nachstellen:
Der letzt Chunk der 1.Datei wird u.U. als erster Block in die 2.Datei geschrieben, damit sind dann beide Dateien defekt, Grund:
Wir erzeugen nur einen Ringpuffer an den die Chunks gesendet werden. Der Upload-Task (Consumer) liest die Daten und schreibt sie in die gerade geöffnete Datei. Das ist aber nicht (thread-)sicher, wir müssten pro Datei einen eigenen Task & Ringpuffer erzeugen, sonst kann ein Chunk in der falschen Datei landen.
Der Webserver stellt die Chunks beliebig bereit und nicht unbedingt seriell.
Der Bug schlummert schon sehr lange im Code und wirkt sich seit dem Web-UI-Multiselect aus.
Vielen Dank für’s tief graben!
Allerdings kommt es bei mir auch zu dem Fehler wenn ich die Datei alleine hoch lade (sowohl UI als auch FTP).
Aber vielleicht sind das ja verschiedene Probleme, die nur zufällig gleichzeitig auftreten…
Vielen Dank fürs weiter forschen, das deckt sich mit meinen Erfahrungen.
Ich habe das auch bei nur einer Datei gehabt. Ganz am Anfang hatte ich nur die Datei von @Joe91 hochgeladen und das Problem war da.
Bei meinem Reihentest wurden bei F Durchlauf 4 nur bei einer Datei Pakete verloren, die dann komischer Weise bei Durchlauf 5 verwendet hat.
Auch der Punkt, dass scheinbar nur bestimmte Dateien (und das reproduzierbar) betroffen sind.
Ich vermute, das ist ein weiteres Problem. Was laut den Aussagen durch die Änderungen von @Wolle behoben wurde.
Ja kann ich jetzt auch reproduzieren. Es scheint an der Dateigröße/Chunkgröße → Restwert zu liegen. Bei einem bestimmten Wert wird der letzte Chunk dann nicht mehr geschrieben.
Bugfix ist in Arbeit, ich stelle ihn dann hier zum Testen rein.
Wow, vielen Dank für’s graben und finden :). Ich habe versucht gehabt den Fehler zu reproduzieren, hatte aber nicht geklappt. Kannst du sagen, welchen Browser du für den Upload verwendest, dass er versucht mehrere Dateien parallel hochzuladen? Bei mir tut Firefox ganz zahm und sendet eine Datei nach dem Anderen.
In einem Upload sollte der Webserver die Chunks (für eine Datei) schon sequentiell bereit stellen. Zumindest sehe ich in dem Quellcode von AsyncWebserver keinen Grund, wieso die Daten von einem Multipart-Request out-of-order akommen würden (Multipart wird hier (WebRequest.cpp:394) gehandlelt und hier (WebRequest.cpp:369) gesammelt und in 1460 byte blöcken an den Handler, aka uns, übergebenen).
Damit müssen wir uns (zum Glück) nur darum kümmern, jedem Upload eine eigene Queue zuzuweisen und dann in die richtige die Daten hineinzustopfen.
Könnt Ihr den Bugfix einmal testen?
Die Methode explorerHandleFileStorageTask komplett gegen diese austauschen:
Die Routine stammt von @Christian , er hatte die für Arduino 2 überarbeitet und sie scheint die Dateien zuverlässig zu schreiben - auch den letzten Chunk.Ich habe jetzt nur noch das Timing für Arduino 1.0.6 angepasst, hier wird der Upload geringfügig langsamer. Das müsste man später wieder optimieren.
Wenn das soweit klappt ist nur noch die Frage ob für einen Mehrfach-Upload jeweils ein eigener Task notwendig ist. @laszloh Ich habe mit Safari auf MacOS getestet und auch dort scheint der Browser die Dateien nacheinander zu schicken, könnte sich dann erledigt haben.
Scheint zu klappen 
Habs zwar erst mit einer Datei probiert, aber sieht schon mal gut aus.
Alter Stand, ohne diesen Change. Reproduziert hier zuverlässig das Problem mit diesem Lied bei diesem Upload-Log:
[ 12419 ] DELETE: /Wenn du fröhlich bist.mp3 deleted
[ 12433 ] build filelist finished: 3 ms
[ 18460 ] Schreibe Datei: //Wenn du fröhlich bist.mp3
creating dir "/"
[ 25525 ] Datei geschrieben: //Wenn du fr�hlich bist.mp3 => 2277376 bytes in 7062 ms (322 kiB/s)
[ 25525 ] Bytes [ok] 2277376 / [not ok] 0, Chunks: 556
Mit diesem Change spielt die Box das Lied problemlos ab. Der dazugehörige Upload-Log:
[ 16389 ] DELETE: /Wenn du fröhlich bist.mp3 deleted
[ 16404 ] build filelist finished: 3 ms
[ 24044 ] Schreibe Datei: //Wenn du fröhlich bist.mp3
creating dir "/"
[ 30613 ] Datei geschrieben: //Wenn du fr�hlich bist.mp3 => 2277645 bytes in 6566 ms (346 kiB/s)
[ 30613 ] Bytes [ok] 2277645 / [not ok] 0, Chunks: 656
Ich habe jetzt die problematischen Dateien von @Joe91 und @mzanetti mehrmals hochgeladen.
Die Dateien wurden einzeln hochgeladen.
Das Ergebnis:
Ich habe nur die Methode explorerHandleFileStorageTask ausgetauscht, die Änderungen von @Wolle habe ich noch nicht eingecheckt.
Die übertragenen Dateien hatten auch nicht mehr das Abspielproblem. Ich vermute, das ist die Lösung. @tueddy danke für den schnellen fix.
„Bedankt“ für’s Testen!
Ich bereite dann mal einen PR auf dem neuen Dev-Branch vor…
Habe das gestern aufgenommen (allerdings selbst noch nicht getestet).
Danke an alle, die daran beteiligt waren .
Hilft das auch den Datenverlust bei SD_SPI zu beseitigen?
Ich kann es hier nicht testen aber vermute das SPI weiterhin die bekannten Fehlersymptome zeigen wird. Es gab ja [not OK] Chunks die nicht auf SD geschrieben wurden, das war bei SD-MMC aber nie der Fall.
Gibt es einen SPI Anwender der den Development-Branch testen kann? Dann wissen wir mehr…
SD und MRFC522 gemeinsam über einem SPI funktioniert. Habs gerade mit dem Dev-Branch und unserem Terstfile probiert. Sieht gut aus 
Das Problem fehlerhafter Web-Uploads besteht ja schon länger und ist bereits im DEV-Branch gelöst.
Habe das jetzt für den Master zurückportiert, damit keiner mehr fehlerhafte MP3-Dateien auf seiner SD-Karte bekommt. Durch einen Fehler meinerseits ist das bereits im offiziellen Master gelandet ohne voherige Review. Hoffe das passt soweit, gerne Rüclmeldung hier!
