Hallihallo,
wie viele .mp3 bzw. Ordner + Unterordner kann ich eigentlich einer einzelnen RFID Karte zuordnen?
Ich möchte nicht für jede Hörbuch CD einer Art eine eigene Karte anlegen und hätte zum Beispiel folgenden Ordner welcher wiederum aus einigen Sortieren Unterordnern besteht:
Ich hätte halt gerne, dass über eine RFID Karte die Reihenfolge logisch durchgegangen wird.
Das ist aktuell nicht vorgesehen.
Das Einzige, was so ein bisschen in die Richtung geht, ist der Playmode RANDOM_SUBDIRECTORY_OF_DIRECTORY.
Oh, wie müsste ich denn dann die MP3s anordnen? Geht denn zumindest ein Unterordner pro CD oder müssen wirklich alle 1995 .mp3 in einem Ordner liegen?
Ein Ordner da sind alle Conni Ordner (pro CD ein Ordner) drin…
Einer weniger wie bei dir
dann sollte das von @biologist laufen, den Sammel Ordner dann als Ziel von der Karte nehmen
Danke, das ist ja schnell erledigt! 
Und die hohe Anzahl der .mp3 für eine einzelne Karte ist kein Problem?
Was ist denn das maximum?
Das hängt vom freien Heap-Speicher und der Länge der Namen ab. In meiner bisherigen Implementierung wurde ja immer der ganze Pfad in jedem Titel mitgespeichert - das macht es natürlich nicht einfacher. @laszloh wollte das umstellen (ist das eigentlich schon aktiv?), aber dennoch kann ich mir nicht vorstellen, dass das alles in den Heap passt.
Kann ich das selbst irgendwie testen? Wäre es so, dass der ESPuino sofort abstürzt wenn ich die Karte auflegen würde?
Du kannst auch die Änderungen von @laszloh noch testen. Das wäre dann win-win, da diese auch noch weiter getesten werden müssen.
Meine Idee war das mit dem Modus RANDOM_SUBDIRECTORY_OF_DIRECTORY zu machen,
dann sollte ja nur immer ein Ordner in der Playlist landen, oder?
Also ein Stammordner ( Conni )
Dann daraunter pro Folge ein Ordner (Conni 1, Conni 2, …)
Dann dem Stammordner im Modus RANDOM_SUBDIRECTORY_OF_DIRECTORY zuweisen.
Dann sollte doch immer eine Folge von Conni kommen (eine zufällige) kann auch zweimal nacheinader die gleiche sein…
Ja / ja (oder es kommt eine Exception)
Nein, die jetzige Version in der dev speichert weiterhin den ganzen Pfad ab (ist ja auch nur ein Umstieg auf std::vector + char*).
In der feature/playlist-class ist es aktuell auch nicht drin, da habe ich nur eine sehr einfache Variante implementiert. Eine Speicherung über base-path + relative Dateinamen ist aber möglich, muss nur geschrieben werden.
Zu Speicherauslastung:
Aktuell können wir mit Rund 50 Zeichen pro mp3 rechnen (wenn die Ordner /Connie/Connie 01/Conne 001 irgendwas igendwas.mp3 heißen). Damit kommen wir auf 100kB an notwendigen Speicher. Ohne PSRAM geht sich das nicht aus, damit sollten wir aber keine großen Probleme haben (Stichwort custom allocators für std::string & std::vector). currentTrack ist uint16_t → bis 65535 Einträgen in der Playlist sind wir save :D.
Spätestens bei der playlist-class haben wir mit 32bit meeeehr als genug (noch nicht so viel, dass wir alle Atome des Universums zählen könnten, aber genug 
)
Mit relativem Pfad reduziert sich das um ~32kB. Wenn die Ordner natürlich längere Namen haben, erhöht sich der Speicherbedarf und -Gewinn bei relativen Pfaden entsprechen.
Beim Testen am Besten mit USB dran sein und VScode den seriellen Monitoren damit wir ein Stack Trace bekommen. Ansonsten ist die Suche sehr mühsam.
Ein neuer Playmodus wie AUDIOBOOK_SUBDIRECTORIES_OF_DIRECTORY wäre vielleicht als Feature sinnvoll.
Die Verwendung von relativen Pfaden gibt es auch schon als Punkt 9 auf der gewünschte Freature Liste
