Ich glaube es liegt an einigen zu großen Covern . Ich bearbeite die MP3´s immer mit iTunes und seit meinem neuen Mac mit Musik . Ich suche dann mit Safari die Cover und wenn ich was finde ziehe ich es einfach herein . Habe da bisher immer so > 600x600 genommen . Das scheint mich jetzt zu treffen, mit 600x600 scheint es zu gehen. Ich werde die nächsten Tage mal alle Cover mit max. 600x600 einfügen und mit >128kbps testen . Mal sehen was passiert . Gebe dann Bescheid .
OK, das könnte der Grund sein. Meine Cover sind meist 150*150px.
Schau mal wie die Dateigröße von „/.cover“…
Hallo,
ich habe gerade auch auf die aktuelle Version upgedatet und ebenfalls die Probleme festgestellt.
Bei mir sind die Hörspiele aufgesplittet in mehrere Dateien und Pro Folge ein Ordner. Die Wartezeit zwischen den Tracks lag bei 3-4 Sekunden. Zudem sind die ersten 10 Sekunden immer doppelt abgespielt wurden.
Dank dem Hinweis die Funktion auskommentiert und nun funktioniert es zufriedenstellend.
Bei den problematischen Hörspielen ist das Coverbild 640x640 und ca. 164kb groß.
Gruß Frank
Ei ei, das ist ja gar nicht schön!
Es sind ja zwei Probleme, lange Wartezeit + Aussetzer beim Start der Wiedergabe. Ich könnte mir vorstellen das kopieren des Bildes in „/.cover“ sorgt für die Verzögerung. Und das servieren über den Webserver dannn die Aussetzer. @FrankP kannst Du das einmal eingrenzen? Also Abspeichern des Bildes drinlassen, dafür die Webhandlermethode rausnehmen? Sind dann noch Aussetzer da? Diese Zeile in Web.cpp auskommentieren:
wServer.on("/cover", HTTP_GET, handleCoverImageRequest);
Ich habe meine ganzen Audiodateien mal durchgeklickt und kann das Problem jetzt auch reproduzieren. Es tritt mit größeren Albumbildern auf. Das ist dann einfach zuviel für den Prozessor!
Komisch das es niemanden bisher aufgefallen war…
Erste Abhilfe: Die Aussetzer bei Audio-Wiedergabe liegen anscheinend bei zuviel CPU-Zeit für den Webserver wenn er das Bild ausliefert, da kommt der Audio-Task ins Stottern. Ich habe jetzt diese Zeile in Web.cpp hinzugefügt:
AsyncWebServerResponse *response = request->beginResponse(
mimeType,
imageSize,
[coverFile](uint8_t *buffer, size_t maxLen, size_t total) -> size_t {
File file = coverFile; // local copy of file pointer
int bytes = file.read(buffer, maxLen);
// close file at the end
if (!file.available()) {
file.close();
Log_Println("cover image serving finished, close file", LOGLEVEL_DEBUG);
}
vTaskDelay(portTICK_RATE_MS * 50u); // ++ Diese Zeile einfüggen +++
return max(0, bytes); // return 0 even when no bytes were loaded
}
);
Also einen vTaskDelay(portTICK_RATE_MS * 50u); hinzufügen.
Die Aktualisierung des Album-Covers wird dadurch zwar etwas langsamer aber dafür spielt Audio ohne Unterbrechungen ab. Man könnte jetzt der Wartezeit noch etwas rumspielen (so 10-50 ms?)
Problem 2: Verzögerung durch langsames Kopieren des Bildes aus der MP3 Datei. Hmm, evt. das Kopieren ganz vermeiden, nur Datei, Position und Länge zwischenspeichern und später im Web-Task die Daten direkt aus der MP3 ausliefern?
Würde mich freuen wenn Ihr den Workaround einmal bei Euch testet.
Ich teste das morgen mal. Konnte das Problem hier mitunter auch nachvollziehen, allerdings war es nicht so ausgeprägt. Waren wohl die Bilder klein, so genau konnte ich das, mangels Zeit, leider nicht analysieren. Danke für deine Arbeit, @tueddy!
Der Task für die TCP-Kommunikation läuft übrigens immer auf irgendeinem der beiden Cores, man kann den aber auch an einen der Cores binden. Das System wird dadurch zuverlässiger.
Man müsste folgenden Präprozessor-Anweisung in die platformio.ini einfügen. Den Core müsste man dann entsprechend wählen.
-DCONFIG_ASYNC_TCP_RUNNING_CORE=1
Aktuell sind ja alle Tasks fest definiert, nur der TCP- und damit der Async-Webserver-Task nicht.
Man könnte zumindest mal testen, ob es einen Performance-Unterschied beim Aufrufen der Seite macht.
Ich habe meine Musik von z.T. 256-320kbps auf 160 kbps reduziert und alle Cover auf 300x300 geändert.
Dei Qualität ist ok und der Fehler tritt nicht mehr auf .
Hallo @compactflash, vielen Dank für die Rückmeldung!
Ich werde das soweit noch ändern das die Verzögerung beim Abspielen und die Aussetzer bei großen Coverbildern nicht mehr auftreten…
1 „Gefällt mir“
Vielen Dank für Eure Rückmeldungen/Bugreports!
Ich habe jetzt auf das Abspeichern des Albumcover vollständig verzichtet und merke mir nur Datei, Position & Größe. Erst wenn das Bild über die Web-UI angefordert wird werden die MP3 zum Lesen geöffnet. Damit sollte die lange Pause beim Abspielen erledigt sein und so schnell funktionieren wie bisher. Die SD-Karte wird auch nicht länger unnötig beschrieben.
Das Stottern in der Audioausgabe wenn gerade das Albumcover geladen wird habe ich durch ein vTaskDelay(portTICK_RATE_MS * 50u) abstellen können. Damit bekommt der Audiotask mehr CPU-Zeit.
Bei Wiedergabe über Webradio wird jetzt auch ein entsprechendes Dummy-Icon angezeigt.
Wer möchte kann das hier schonmal testen, Feedback willkommen!
1 „Gefällt mir“
Die Idee nur die Position und Größe zu speichern finde ich genial!
Zwei Ideen dazu:
- Den Dateinamen haben wir doch schon in der Playlist, oder denke ich falsch?:
File coverFile = gFSystem.open(*(gPlayProperties.playlist + gPlayProperties.currentTrackNumber), FILE_READ);
- Es fehlt ein Stück vom Cover:
size_t imageSize = gPlayProperties.coverFileSize - coverFile.position() + gPlayProperties.coverFilePos;
@Christian bin erst jetzt dazu gekommen mir Deinen Fork genauer anzuschauen:
Da hast Du ja eine super Struktur & ganz feine Sachen eingebaut 
Die Übernahme in den ESPuino-master als Ganzes wird wohl schwierig, habe mir daher erstmal Deine Verbesserungsvorschläge & die Web-Upload Fortschrittsanzeige geschnappt und einen PR erzeugt:
1 „Gefällt mir“
Die SD Karte meines Sohn’s hat sich mittlerweile gefüllt (ca. 1000 Dateien in 120 Ordnern), da konnte ich auch Verzögerung bein Laden der WebUI nachvollziehen und um ca. 0.5Sek beschleuingen, Download-Möglichkeit @compactflash von z.B. Backup.txt auch gute Idee:
1 „Gefällt mir“
Ja, mit jedem PR den Du für die HTML-Seite machst wird es schwieriger 
Aber ist ja gut, wenn Du so ein paar Funktionen übernimmst.
Vielleicht magst Du hier auch einmal schauen:
Ich hab’ das überprüft, das stimmt. Es wird aktuell nicht angezeigt, dass mehrere Dateien ausgewählt sind. In meinem Fork ist die Dateiauswahl noch einmal etwas anders implementiert - dort steht dann die Anzahl der ausgewählten Dateien.
Also den Upload mehrerer Dateien gleichzeitig habe ich noch nie probiert, wusste ger nicht das es möglich ist. Werde das mal testen…
Das Problem mit „not OK“ <> 0 liegt aber wohl an SD-Karte + SPI Anbindung. Mit SD_MMC hatte ich noch nie einen fehlerhaften Upload.
@Christian die Visualisierung einer Mehrfachauswahl ist ja die eine Sache aber wie funktioniert der Mehrfach-Upload im HTML/Javascript? Kannst Du das näher erklären oder hier mal einen Screenshot des Controls zeigen?
Du kriegst ja ein Fenster von deinem Browser angezeigt vor dem Upload. Da wählst du einfach mehrere Dateien aus.
Habe jetzt mal Mehrfach-Upload getestet & das funktioniert ganz hervorragend, bei allen [nok]=0 (SD_MMC).
Auch die Fortschrittsanzeige passt.
Im Auswahlfeld steht allerdings nur die erste Datei, das kann man sicher noch verbessern. Mal schauen wann ich dazu komme…
Kann ich nun auch mit SD_MMC bestätigen.
Läuft sauber. Die Sekunden passen bei mir nicht, aber der Rest schon (für die aktuelle Datei). Alle ausgwählten Dateien wäre zwar schön, aber so ist es auch schon sehr gut brauchbar.
Auch sind alle [nok]=0
@biologist , @Christian , @tueddy, besten Dank.
2 „Gefällt mir“
Ich habe mal ein wenig mit Ordner-upload rumprobiert. Lässt sich tatsächlich sehr einfach umsetzen. Wer es sich mal anschauen möchte, hier hab ich einen commit: directory upload · SZenglein/ESPuino@b6d8952 · GitHub
Finde es eigentlich ziemlich praktisch, da man so den Upload seiner ganzen Ordnerstruktur viel komfortabler erledigen kann.
„webkitdirectory“ in html ist leider kein Standard, wird aber von allen gängigen Browsern unterstützt.
3 „Gefällt mir“