Probleme mit mp3 Dateien

Das eine Datei beim Upload verstümmelt wird ist mir bisher noch nie aufgefallen. War auch noch nie Thema, außer jetzt bei der Sonne, Mond Sterne…mp3 Datei weiter oben im Thread, heißt dort musicfile.zip

Also es ist nicht 100% auszuschließen, dass es von SPI kommt. Wenn man ein File hochlädt, dann wird aus diesem Grund eine Statistik ausgegeben, wieviel Pakete erfolgreich übertragen wurden.
Da haben wir schon einiges an Zeit drin verbraten, aber bisher hat niemand rausgefunden, warum Dateien immer mal wieder (nicht immer) beim SPI-Transfer kaputtgehen. Der hört dann ab einem gewissen Punkt einfach auf, den Kram auf die SD zu schreiben und meldet das auch entsprechend zurück.

Hallo @Joe91,
ich bin der Meinug, dass die Datei auf der SD Karte von der Originaldatei in der Länge abweicht.
MP3 decode error -1 : INDATA_UNDERFLOW
weist darauf hin. Damit nicht die Endlosschleife wirkt, habe ich eine Abbruchbdingung eingebaut. Bei einem Dekoderfehler wird jetzt ein EOF gesendet.
Im Log sieht das dann so aus:

[ 159695 ]  info        : MP3 decode error -1 : INDATA_UNDERFLOW
[ 159695 ]  info        : audio file is corrupt --> send EOF
[ 159696 ]  info        : Closing audio file
1 „Gefällt mir“

Vielen Dank für den fix!!
Aber zurück zur Ursache. Irgendwas an der Datei sorgt ja dafür, dass sie zuverlässig falsch übertragen wird und etwas Inhalt verloren geht wenn der ESPuino das macht.
Wurde jetzt ja auch mehreren Systemen nachgestellt.
Dass mit dem direkt auf die SD schreiben ist ziemlich verrückt :smiley: .
Wenn der header „korrigiert“ wird klappt es ja wieder mit dem Webupload. FTP macht übrigens keinen Unterschied dabei…

Ich glaube nicht, dass es am SPI liegt. Verhält sich ja auch auf anderen Systemen so, dass bestimmte Dateien dieses Verhalten aufweisen…

Ich habe die ESPuino-mini 4Layer und die ist meines Wissen über SD_MMC angeschlossen. Bei mir ist der Fehler auch über den Webupload passiert. Daher würde ich SPI als Ursache auch ausschließen

Auch hier sd_mmc, bisher habe auch ich alle Dateien über das web interface hochgeladen und der Fehler tritt ziemlich häufig auf.

(Ich hab’s komischerweise noch nicht geschafft eine sd Karte so zu formatieren dass ich vom Rechner aus direkt was auf die Karte kopiere und der espuino das dann sieht… Der espuino scheint hier ausschließlich die Dateien zu sehen die mit dem web interface hochgeladen werden. FTP funktioniert hier auch gar nicht - aber das ist ein anderes Thema)

Der Bugfix funktioniert @Wolle !
Falls wir an der Ursache nicht weiterkommen, ist zumindest die Auswirkung behoben :wink:

Fehlerhafter Upload ist bislang nur für SD-Anbindung über SPI bekannt!
SD_MMC sollte fehlerfrei sein, scheint aber nach Euren Berichten nicht der Fall zu sein…

Ich habe seinerzeit den Webupload optimiert mit einen Ringpuffer, der möglichst große Chunks schreibt.
Am Ende des Uploads erscheint in der seriellen Ausgabe eine Meldung Bytes [ok] %zu / [not ok]
[not ok] muss natürlich 0 sein sonst ist die Datei fehlerhaft/unvollständig.

Der Upload wurde aber nicht abgebrochen?
Evt. können wir die Fehlerbehandlung verbessern ab hier?

So, ich kann diesen Song nicht mehr hören :slight_smile:

Das kann ich nicht bestätigen…ich bekomme immer die Gesamte Dateistruktur angezeigt

Es ist so wie @Wolle es beschrieben hat. Die Fehler entstehen scheinbar durch den Webupload.

Ich habe 6 Dateien einmal direkt auf die SD-Karte kopiert und einmal per Web.
Das Webinterface hat dies wie folgt Quittiert:

Wenn man die Dateien vergleicht kommt dies heraus (links ist per SD-Karte, links ist per Web):

Aber jetzt ist nur die erste Datei von dem Problem betroffen. Die VBR-Headerreparatur hat also doch keinen Einfluss.

Verrückt wird es jedoch, wenn man sich die Unterschiede einsieht.

  • Wie gesagt, von dem Zurückspringen ist nur die erste Datei betroffen, die 2. wird problemlos abgespielt und beendet
  • Bei der ersten Datei ist die Webübertragung um 549byte kleiner.
  • Bei der zweiten Datei ist die Webübertragung um 549byte größer.
  • Wenn man die Dateien auf Ascii-Ebene vergleicht, dann klemmt genau der Block von Datei 1 am Beginn der Datei 2

Wer es sich anschauen mag, hier die Dateien:
Test.zip (9,1 MB)

Man sieht auch im Terminal, dass er für die 2. Datei des Webuploads keine ID3-Infos findet (Wahrscheinlich weil die Datei nicht mehr mit ID3 beginnt)

[ 9149 ] RFID-Karte erkannt: (ISO-14443) ID: 04-5f-75-6a
[ 9152 ] RFID-Karte empfangen: 004095117106
[ 9185 ] Playlist-Generierung: cached
[ 9198 ] Freier Speicher: 86476
[ 9198 ] Anzahl gültiger Files/Webstreams: 6
[ 9198 ] Modus: Hoerspiel
[ 9207 ] Neue Playlist empfangen mit 6 Titel(n)
[ 9207 ] Free heap: : 87288
[ 9254 ] info : PSRAM found, inputBufferSize: 283615 bytes
[ 9254 ] info : buffers freed, free Heap: 87288 bytes
[ 9254 ] info : Reading file: „/Nochmal/Kapitel 10.2 Kapitel 11.1 Sonne Mond und Sterne (Wieso Weshalb Warum JUNIOR Folge 72)_1.mp3“
[ 9287 ] info : MP3Decoder has been initialized, free Heap: 63568 bytes
[ 9288 ] ‚/Nochmal/Kapitel 10.2 Kapitel 11.1 Sonne Mond und Sterne (Wieso Weshalb Warum JUNIOR Folge 72)_1.mp3‘ wird abgespielt (1 von 6)
[ 9317 ] info : Content-Length: 2408448
[ 9317 ] info : ID3 framesSize: 45
[ 9317 ] info : ID3 version: 2.4
[ 9339 ] info : ID3 normal frames
[ 9429 ] id3data : SettingsForEncoding: Lavf59.34.102
[ 9547 ] info : Audio-Length: 2408403
[ 9706 ] info : stream ready
[ 9708 ] info : syncword found at pos 0
[ 9717 ] info : Channels: 2
[ 9717 ] info : SampleRate: 48000
[ 9717 ] info : BitsPerSample: 16
[ 9717 ] info : BitRate: 64000
[ 9738 ] info : VBR recognized, audioFileDuration is estimated
[ 10046 ] Aktuelle Batteriespannung: 3.88 V
[ 10064 ] Aktuelle Batterieladung: 100.00 %
[ 31662 ] 30 Sekunden nach vorne gesprungen
[ 32043 ] info : stream ready
[ 34011 ] 30 Sekunden nach vorne gesprungen
[ 34389 ] info : stream ready
[ 36280 ] 30 Sekunden nach vorne gesprungen
[ 36663 ] info : stream ready
[ 36670 ] info : MP3 decode error -6 : INVALID_FRAMEHEADER
[ 36673 ] info : syncword found at pos 376
[ 36677 ] info : syncword found at pos 0
[ 36680 ] info : MP3 decode error -8 : INVALID_SCALEFACT
[ 36684 ] info : syncword found at pos 236
[ 36688 ] info : syncword found at pos 0
[ 36702 ] info : Channels: 2
[ 36702 ] info : SampleRate: 48000
[ 36702 ] info : BitsPerSample: 16
[ 36702 ] info : BitRate: 128000
[ 38782 ] 30 Sekunden nach vorne gesprungen
[ 39160 ] info : stream ready
[ 43891 ] ws[/ws][1] connect
[ 44138 ] no cover image for SD-card audio
[ 60003 ] RSSI: -56 dBm
[ 72316 ] Neue Lautstärke empfangen via Queue: 2
[ 73180 ] Neue Lautstärke empfangen via Queue: 1
[ 74013 ] Neue Lautstärke empfangen via Queue: 2
[ 74260 ] Neue Lautstärke empfangen via Queue: 3
[ 75291 ] Neue Lautstärke empfangen via Queue: 4
[ 75505 ] Neue Lautstärke empfangen via Queue: 5
[ 75771 ] Neue Lautstärke empfangen via Queue: 6
[ 87094 ] info : MP3 decode error -1 : INDATA_UNDERFLOW
[ 87098 ] info : syncword found at pos 93
[ 87101 ] info : syncword found at pos 0
[ 87104 ] info : MP3 decode error -6 : INVALID_FRAMEHEADER
[ 87106 ] info : syncword found at pos 176
[ 87111 ] info : syncword found at pos 0
[ 87116 ] info : MP3 decode error -6 : INVALID_FRAMEHEADER
[ 87122 ] info : syncword found at pos 93
[ 87126 ] info : syncword found at pos 0
[ 87130 ] info : MP3 decode error -6 : INVALID_FRAMEHEADER
[ 87136 ] info : syncword found at pos 1
[ 87141 ] info : syncword found at pos 0
[ 87145 ] info : MP3 decode error -8 : INVALID_SCALEFACT
[ 87151 ] info : syncword found at pos 213
[ 87155 ] info : syncword found at pos 0
[ 87168 ] info : Channels: 2
[ 87169 ] info : SampleRate: 48000
[ 87169 ] info : BitsPerSample: 16
[ 87169 ] info : BitRate: 224000
[ 101279 ] Kontroll-Kommando empfangen via Queue: 4
[ 101279 ] Schreibe ‚#/Nochmal#0#3#1‘ in NVS für RFID-Card-ID 004095117106 mit Abspielmodus 3 und letzter Track 1
[ 101283 ] #/Nochmal#0#3#1
[ 101287 ] Titel wird im Hörspielmodus von vorne gespielt.
[ 101290 ] Kommando: Nächster Titel
[ 101294 ] info : Closing audio file
[ 101308 ] info : buffers freed, free Heap: 85960 bytes
[ 101308 ] info : Reading file: „/Nochmal/Kapitel 10.2 Kapitel 11.1 Sonne Mond und Sterne (Wieso Weshalb Warum JUNIOR Folge 72)_2.mp3“
[ 101340 ] info : MP3Decoder has been initialized, free Heap: 62248 bytes
[ 101347 ] ‚/Nochmal/Kapitel 10.2 Kapitel 11.1 Sonne Mond und Sterne (Wieso Weshalb Warum JUNIOR Folge 72)_2.mp3‘ wird abgespielt (2 von 6)
[ 101370 ] info : Content-Length: 2411037
[ 101370 ] info : file has no mp3 tag, skip metadata
[ 101371 ] info : Audio-Length: 2411037
[ 101432 ] no cover image for SD-card audio
[ 101737 ] info : stream ready
[ 101740 ] info : syncword found at pos 69
[ 101744 ] info : syncword found at pos 0
[ 101764 ] info : MP3 decode error -6 : INVALID_FRAMEHEADER
[ 101767 ] info : syncword found at pos 1534
[ 101772 ] info : syncword found at pos 0
[ 101780 ] info : Channels: 2
[ 101780 ] info : SampleRate: 48000
[ 101780 ] info : BitsPerSample: 16
[ 101780 ] info : BitRate: 64000
[ 101801 ] info : VBR recognized, audioFileDuration is estimated
[ 120005 ] RSSI: -57 dBm
[ 127320 ] 30 Sekunden nach vorne gesprungen
[ 127701 ] info : stream ready
[ 129380 ] 30 Sekunden nach vorne gesprungen
[ 129756 ] info : stream ready
[ 131679 ] 30 Sekunden nach vorne gesprungen
[ 132063 ] info : stream ready
[ 132066 ] info : MP3 decode error -6 : INVALID_FRAMEHEADER
[ 132069 ] info : syncword found at pos 0
[ 132072 ] info : MP3 decode error -6 : INVALID_FRAMEHEADER
[ 132076 ] info : syncword found at pos 0
[ 132080 ] info : MP3 decode error -6 : INVALID_FRAMEHEADER
[ 132086 ] info : syncword found at pos 18
[ 132090 ] info : syncword found at pos 0
[ 132106 ] info : Channels: 2
[ 132106 ] info : SampleRate: 48000
[ 132106 ] info : BitsPerSample: 16
[ 132106 ] info : BitRate: 320000
[ 133731 ] 30 Sekunden nach vorne gesprungen
[ 134108 ] info : stream ready
[ 178468 ] info : Closing audio file
[ 178468 ] info : End of file „/Nochmal/Kapitel 10.2 Kapitel 11.1 Sonne Mond und Sterne (Wieso Weshalb Warum JUNIOR Folge 72)_2.mp3“
[ 178474 ] eof_mp3 : /Nochmal/Kapitel 10.2 Kapitel 11.1 Sonne Mond und Sterne (Wieso Weshalb Warum JUNIOR Folge 72)_2.mp3
[ 178485 ] Schreibe ‚#/Nochmal#0#3#2‘ in NVS für RFID-Card-ID 004095117106 mit Abspielmodus 3 und letzter Track 2
[ 178495 ] #/Nochmal#0#3#2
[ 178509 ] info : buffers freed, free Heap: 85944 bytes
[ 178509 ] info : Reading file: „/Nochmal/Kapitel 10.2 Kapitel 11.1 Sonne Mond und Sterne (Wieso Weshalb Warum JUNIOR Folge 72)_3.mp3“
[ 178539 ] info : MP3Decoder has been initialized, free Heap: 62228 bytes
[ 178546 ] ‚/Nochmal/Kapitel 10.2 Kapitel 11.1 Sonne Mond und Sterne (Wieso Weshalb Warum JUNIOR Folge 72)_3.mp3‘ wird abgespielt (3 von 6)
[ 178569 ] info : Content-Length: 2408997
[ 178569 ] info : ID3 framesSize: 45
[ 178570 ] info : ID3 version: 2.4
[ 178592 ] info : ID3 normal frames
[ 178678 ] id3data : SettingsForEncoding: Lavf59.34.102
[ 178798 ] info : Audio-Length: 2408952
[ 178815 ] no cover image for SD-card audio
[ 178965 ] info : stream ready
[ 178969 ] info : syncword found at pos 0
[ 178977 ] info : Channels: 2
[ 178977 ] info : SampleRate: 48000
[ 178977 ] info : BitsPerSample: 16
[ 178977 ] info : BitRate: 64000
[ 178998 ] info : VBR recognized, audioFileDuration is estimated

1 „Gefällt mir“

Rückfrage an @mzanetti , @joker , @Joe91 und alle die dies Problem haben:

  • Verwendet Ihr den aktuellen Master oder Arduino 2? Letztere Version ist experimentell & hat zumindest Probleme mit schwankenden Uploadraten und hier evt. auch Paketverlust

  • Macht Ihr einen Mehrdateiupload oder jeweils nur eine Datei zur Zeit?

  • Seht Ihr nach dem Upload in der seriellen Ausgabe etwas mit [nok] > 0? Das sind dann fehlerhafte Chunks. Dieser Log wurde ursprünglich für Probleme bei SPI eingebaut.

Die Dateien werden anscheinend fehlerhaft hochgeladen und liegen beschädigt auf der SD, da kann dann die Audio-Bibliothek auch nicht mehr viel retten außer nicht abzustürzen oder hängenzubleiben…

Ich habe auf jeden Fall schon gesehen das es keine Fehlerbehandlung gibt wenn Chunks [nok] = not OK sind. Aus meiner Sicht sollte dann die bereits (halb) geschriebene Datei gelöscht werden und ein Fehler genauso wie jetzt bei Timeout dem Anwender angezeigt werden.

Passiert auf Arduino 1 und 2.
Hatte sowohl mehrere Dateien über FTP aufgespielt als auch anschließend einzelnen die betroffenen Dateien nochmal ausgetauscht. Das hat alles kein Unterschied gemacht.
Ich würde so weit gehen zu behaupten, dass das auf jeden System mit den passenden Dateien reproduzierbar ist wenn man den fix von @Wolle wieder rückgängig macht.

Die spannende Sache daran finde ich, dass das Verhalten an der Datei haftet und nicht zufällig sondern reproduzierbar auftritt…

@joker ich kann dir morgen auch noch weitere Dateien mit diesem Problem besorgen. Das ist schon eine besonders heftige zum wiederholt anhören :smiley:

Geht das Schreiben auf die SD-Karte eventuell auf den Header und nicht auf die Roh-Datei?
Falls dort der Fehler liegt?

Der HTTP Datei-Upload wird vom verwendeten ESPAsyncWebserver behandelt und ist hier beschrieben.

Die Datei wird in Chunks gesendet, diese werden nach und nach in die SD-Datei geschrieben. Bei „final“ wird die Datei dann geschlossen. Den Upload-Code findet Ihr ab hier.

Aus Gründen der Upload-Performance wird ein eigener Schreib-Task erzeugt der über einen Ringpuffer die Chunks entgegennimmt und auf SD-Karte schreibt.

Wenn jetzt so ein Chunk fehlt ist die Datei unvollständig. Also hat jemand im Log dann [NOK] > 0?

Werde ich mir anschauen. Komme allerdings erst morgen Abend wieder an den PC. Wünsche euch eine gute Nacht zusammen!

Ich habe den master von vor 2 Wochen mit den Fix zu Multibutton und Shutdown-Animation.

Der Fehler ist sowohl bei Einzeldateien, als auch bei Ordnern aufgetreten.

Ich habe jetzt die Dateien 10 mal hochgeladen (10 mal nacheinander den Ordner Nochmal in einen neuen Testdurchlauf-Ordner gekippt)
Das Ergebnis:


Durchlauf 7,8 und 9 waren fehlerfrei

Die Fehlenden Daten aus Testdurchlauf 4 (letzte Datei) lad dann in der ersten Datei von 5

Die Terminalausgabe habe ich mal in eine Textdatei gepackt. [nok]>0 gibt es nicht - seltsamer Weise habe ich nur 59 [nok] - ich sehe gerade, irgendwie hat das Terminal gleich beim ersten Durchlauf zwischen Datei 1 und 2 daten verloren
Terminal.txt (33,7 KB)

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 :rofl:

So, ich muss erst mal ins Bett :slight_smile:

@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:

grafik

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.

grafik

ganz schön frech :slight_smile:
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.
  • Nope: [ 32302 ] Bytes [ok] 2277376 / [not ok] 0, Chunks: 556

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)