Große Hörbücher brauchen sehr lange um geladen zu werden

Ich baue derzeit grade meinen dritten espuino mit sd mmc und dem pn5180 und wundere mich wie ich das auswählen der titel ein wenig schneller machen kann. Wenn ich hingehe und zB ein Hörbuch mit 200 tracks wähle, wird ja so wie ich das verstanden habe eine Liste angelegt in der die Titel nicht mehr als Titel gespeichert werden (was ja recht groß wäre) sondern als numerische Zahl (1-200).
Leider dauert es dennoch teilweise 20 Sekunden bis der zuletzt gespielte track wieder läuft. Kann ich etwas tun um das zu beschleunigen?
Zb die Tracks umbennenen? Wenn ja wird das über den ID3 Tag gemacht oder den titel?

Danke!!!

Es ist so, dass zum Erstellen der Playlist der gesamte Inhalt von einem Verzeichnis angezeigt werden muss. Das ist ein Vorgang, der leider nicht fürchterlich schnell ist, ich wüsste jedoch auch nicht, wie ich ihn beschleunigen sollte. Da ist die Regel einfach: Je mehr Dateien ein Verzeichnis hat, desto länger dauert es.

Wenn du jetzt eine Playlist pausierst und befindest dich im Modus Hörspiel, dann wird die Stelle der Pause gespeichert. Dabei wird jedoch nicht der Dateiname gespeichert sondern die Nummer des Titels innerhalb der Playlist. Also sagen wir mal du hast 200 Titel und du drückst jetzt bei 16 Pause, dann speichert der ne 16 und innerhalb der 16 auch noch eine Position in Bytes.

Jetzt hörst du irgendwas Anderes und willst jetzt wieder in dein altes Hörspiel wieder einsteigen. Dann muss dennoch die Playlist wieder neu generiert werden. Einerseits, damit du weißt, was Titel 16 überhaupt ist. Und andererseits, weil du 17, 18, 19… ja auch hören willst. D.h. das Parsing ist genau das Gleiche, wie auch beim ersten Mal. Der Unterschied ist nur, dass der Startpunkt ein anderer ist.

TL;DR: Schneller wird es nur, wenn man wenige Titel nimmt. Ich habe für den Sohnemann mehrere Pipi-Langstrumpf-Folgen, die teilweise mehrere Stunden gehen. Die splitte ich (aus Faulheit) alle zehn Minuten. Das ist dann ok finde ich.

Hat das deine Frage beantwortet?

Wieviel Aufwand ist es zum Implementieren, dass die Playlist auf die SD-Karte geschrieben wird? Dann ist das nächste abspielen deutlich schneller. Als Nachteil wird sie nicht aktualisiert wenn der Benutzer neue Dateien hinzufügt. In diesem Fall ist aber auch die Abspielposition kaputt.
Wenn jetzt der Browser zum Upload der Datei genutzt wird, dann könnte auch dieser direkt die Playlist anpassen und korrigieren. Im Refactoring ist es ja gerade ein Thema. Vielleicht könnte man das dort mit berücksichtigen?

Diesen Ansatz hatten wir bereits.
Probleme:
a) Es ist ziemlich lästig, ne ganze SD zu parsen. Also das dauert ne ganze Weile, wenn da viel drauf ist. Ja, das macht man nicht dauernd. Aber du willst auch nicht minutenlang warten, wenn du mal eben ne neue Karten anlernen willst.
b) Wenn man die Daten komplett liefert, so dass man daraus einen JSTree macht, dann können das ziemlich viele Daten werden. Das graphisch aufzubauen war irgendwie nicht so performat. Holst du in der GUI ad hoc nur genau den Kram, den du brauchst, dann hat sich das als besser herausgestellt (hätte ich auch nicht erwartet aber es ist so).

Es hat sich dann gezeigt, dass es besser ist, den Verzeichnisinhalt dynamisch nachzuladen. Also wir hatten da vor einer Weile mal ein json-File, in dem der ganze Inhalt lag. Also genau Pre-Caching, wie du es dir vorstellst.

Also ich spreche jetzt nur für die GUI. Pre-Caching für die Playlist-Generierung hatten wir noch nicht. Das würde das Problem mit dem langsamen Parsen sicher beheben, ja. Aber ich denke skalieren würde das auch wieder nicht. Weil dann hast du ein großes JSON-File und wenn du das in ArduinoJson steckst, dann brauchst wieder Heap, den du ggf nicht hast.

Erstmal eine Verständnisfrage:
Es geht hier doch um das verzögerte Abspielen eines Hörspiels nach dem Auflegen einer Karte. Die WebUI ist an der Stelle nicht beteiligt?

Ich rede vom Rückgabewert von returnPlaylistFromSD(…). Wenn du diese Liste auf der SD-Karte hättest, kannst du schnell starten. Wenn sie nicht existiert, dann musst du sie erstellen wie bisher.
Das ist ja nur der Inhalt des Ordners und dieser verändert sich im Vergleich zu einer SD-Karte nicht so oft.

Und in der WebUI ist der Verzeichnisinhalt irgendwann ja auch vollständig da. Solange muss das Skript welches dann diese Playlist aktualisiert eben warten bevor sie diese aktualisieren kann. Wobei mir auffällt, dass ich über FTP nicht nachgedacht habe sondern nur den Upload über die UI.

Hat das deine Frage beantwortet?
Ja, danke!

Ja. Ich habe jetzt im Prinzip unpassenderweise die GUI ins Spiel gebracht, das hat mit dem Playlist-Generator erstmal nix zu tun. Aber das Problem ist ja das Gleiche: Du willst nicht so lange warten, bis der Verzeichnisinhalt ausgeparst ist. Also musst du es irgendwann mal komplett parsen, in einer Datei ablegen und dann, bei Bedarf, auslesen.

Für GUI hatten wir das Pre-Caching wie gesagt schon. Es war ok, aber dynamisch hat sich das als praktikabler erwiesen. Bei der Playlist-Generierung wird es ähnlich sein: Es löst ein Problem, aber wirft neue auf.

Was grundsätzlich denkbar wäre: Man legt so ein Caching-File pro Ordner an. Und zwar nicht als json, sondern einfach als csv. Weil das kann man ziemlich einfach ohne Overhead parsen und in eine Playlist stecken. So läuft aktuell die Playlist-Generierung auch schon. Nur mit dem Unterschied, dass die csv-Struktur im Speicher liegt.
Und es braucht eine Funktion, die durch die ganze SD-Karte durchiteriert und diese Files schreibt. Per Compile-Direktive kann der Benutzer steuern, ob er das gerne dynamisch oder pre-cached hätte. Oder alternativ/zusätzlich: Man schaut im Verzeichnis x nach, ob man eine solche Datei findet. Wenn ja, dann liest man sie aus. Wenn nein, dann macht man das dynamisch (wie jetzt) und schreibt zusätzlich eine solche Datei.

Wäre vermutlich machbar und würde auch skalieren denke ich. Aber das Generieren der Files kann recht lange dauern bei vielen Files.

Also ich denke da könnte ich mich mit anfreunden.

Parsen? Einfach als Block laden und die ‚;‘ durch ‚\0‘ ersetzen und damit die Pointer anpassen :innocent:

Der Punkt „alternativ/zusätzlich“ sollte alleine schon ausreichen um es zu implementieren. Dann spart man sich das Iterieren über die gesamte SD-Karte.

Es bleibt aber der Nachteil mit dem Aktualisieren.
*Wenn die SD-Karte entfernt und geändert wird, mussen die Playlisten händisch gelöscht werden
*In der WebUI kann die Playliste beim Upload der Datei automatisch angepasst werden
*Beim FTP sehe ich leider keine Möglichkeit eines Hooks, ansonsten kann man dort bei einer übertragenen Datei in dem Ordner die Playliste löschen. Dann wird sie beim Start wieder aktualisiert.

Wenn man dir bei der Umsetzung helfen kann, gib bitte Bescheid.

Natürlich Parsen. Aus dem CSV muss ein 2d-Array gebaut werden. Aber wie gesagt, ein CSV habe ich jetzt auch schon beim Auslesen des Verzeichnisinhalts. Alternativ käme hier dann halt die Option der Datei ins Spiel. Und ist die Datei nicht da, dann kann ich sie mit dem Inhalt, den ich eh als CSV im Speicher habe, einfach schreiben.

Also ja, ich denke der Aufwand ist nicht so groß. Klingt nach einem Plan :grin: