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
@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.
Aktuell verwende ich Arduino 2. Hatte das Problem aber (fast) genauso mit Arduino 1 vorher. Ich bilde mir ein es sind unterschiedliche Lieder an denen es reproduzierbar ist, hab das aber nicht durch downgraden verifiziert ob das wirklich so ist. Da ich LPCD + MQTT nutze, kann ich Arduino1 nicht nutzen weil ich da vom „Ruckel-Bug“ (anderer thread) betroffen bin. Arduino 2 funktioniert bis auf dieses letzte Problem hier rock solid.
Hab das Problem mit beiden Varianten. Sowohl mit Einzel-Uploads als auch mit Mehrdatei-Uploads. Immer die gleichen Dateien, egal ob einzeln oder im Batch hochgeladen.
Ja, 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 .
Ich konnte den Web-Upload-Fehler jetzt nachstellen:
Lade ich eine einzelne MP3 hoch ist Alles OK
Wähle ich mind. zwei Dateien oder einen ganzen Ordner sind die hochgeladenen SD-Dateien defekt
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.
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…