Neues Feature: Playlist aus lokaler .m3u-Datei

Was ist neu?

In der WebGUI gibt es nun bei der RFID-Zuweisung einen neuen Abspielmodus, der Liste (Dateien von SD und/oder Webstreams) aus lokaler .m3u-Datei heißt. Diesen kann man auswählen und in Verbindung mit einer .m3u-Datei einer RFID-Karte zuweisen. Diese .m3u-Datei muss sich lokal auf der SD-Karte befinden.

Wie muss die .m3u-Datei aufgebaut sein?

Einfach eine Liste aus URLs mit Webstreams und/oder Pfaden zu auf der SD-Karte gespeicherten Musikdateien. Jeder Webstream muss in einer neuen Zeile stehen. Auch jede Datei muss in einer neuen Zeile stehen (samt absolutem Pfad; z.B. /mp3/Kinder/bibi3.mp3). Am besten mal bei Wikipedia einen Blick auf einfache m3u-Dateien werfen. Wichtig: Ein Mischen von Webradio-Stationen und lokalen Dateien ist also möglich.

Kann ich auch nur lokale mp3s in der .m3u-Datei angeben?

Ja, das geht. Was jedoch nicht geht, das ist die Angabe von Verzeichnissen. Es können also immer nur einzelne Dateien angegeben werden, dieser können jedoch quer über die SD-Karte verteilt sein.

Wie springt man zwischen den Webstreams/Dateien hin und her?

Wie bisher bei Playlists mit mehreren Titeln: Mit vor bzw. zurück. Auch erster und letzter Titel funktionieren natürlich.

Wie kommt die .m3u-Datei auf die SD-Karte?

Wie üblich:

  • Direkt vom Computer auf die SD-Karte kopieren
  • Webtransfer
  • FTP
3 „Gefällt mir“

Noch verstehe ich den Modus nicht ganz.
Kann ich dann mit „vor“ und „zurück“ durch die einzelnen Webstreams springen?

Genau. Das ging vorher nicht, da konnte man immer nur einen Stream in der aktuellen Playlist haben. Bzw. anders gesagt: Man konnte einen m3u-Link zwar angeben, aber das wurde 1:1 an die Audiolib von @Wolle durchgereicht. Diese wählt davon dann den Ersten aus.

Ja, das stimmt. Die Audiolib kann nur Playlisten aus dem Web öffnen. Die Betreiber von Radiostationen geben häufig nur URL der Playlist bekannt. Wenn sich einmal die Stream-URL der Radiostation ändert braucht nur der Inhalt der Playlilist angepasst werden.
Eine typische Playist sieht so aus:

#EXTM3U
#EXTINF:-1,Bremen Eins
http://rb-bremeneins-live.cast.addradio.de/rb/bremeneins/live/mp3/128/stream.mp3

Lokale Playlisten muss man sich selber erstellen, das kann die Audiolib nicht.

Ich hätte dieses Feature schon früher programmieren sollen… feiere es total :slight_smile:
Im Home-Office habe ich nebenher ganz viel nen ESPuino laufen und habe, für verschiedene Webradios, bisher immer mehrere Karten gebraucht. Die lagen dann gerne mal an verschiedenen Ecken auf dem Tisch. Jetzt geht es einfach mittels Taste vor/zurück. Super Sache :+1:

2 „Gefällt mir“

Ich werde, vermutlich heute Abend, nochmal ein Update zu diesem Feature machen. Denn eigentlich gibt es keine Notwendigkeit, das .m3u-Feature nur mit Webstreams kompatibel zu machen. Ich habe es hier lokal bereits dahingehend geändert, dass man Webstreams und Files auch mischen kann in einem .m3u-File. Das eröffnet einem dann nämlich auch die Möglichkeit, Playlisten von lokalen Files zu erstellen, die nicht nur in einem Verzeichnis liegen. Das ist zwar etwas umständlich so ein File zu schreiben, aber gehen würde es zumindest. Glaube so ein Feature wurde hier von irgendwem auch mal gefordert, dass man möglichst mehrere Karten kombinieren kann. Hier ginge hier dann quasi indirekt.

Einschränkung: Lokal dürfen nur Dateien mit absoluten Pfaden angegeben werden. Aus kompletten Ordnern wird nicht automatisch eine Playlist generiert; dafür müsste man das Feature nochmal deutlich „aufbohren“.

Hinweis: Umlaute könnten hier allerdings zu Problemen führen, da ich nicht wissen kann, mit welchem Zeichensatz so ein .m3u-File hochgeladen wird. Besser keine benutzen :joy:

So, man kann jetzt auch gemischte .m3u-Dateien verwenden.
Habe auch sonst noch ein paar Sachen im Musikhandling leicht umgebaut. Bitte mal testen, ob euch, ggf. in anderen Modi, Fehler auffallen.

Am Wochenende hatten unsere Jungs ihre ESPuinos mit bei den Großeltern dabei → sie wurden ohne WLAN betrieben. Hierbei habe ich festgestellt, dass alle Tags die einer m3u Datei zugewiesen waren ohne WLAN einfach nicht abgespielt wurden. Stattdessen zeigte der Neopixel Ring nur kurz „rot“ an, als ob der jeweilige Tag nicht erkannt / zugewiesen wurde und es passierte sonst nichts weiter.

Alle anderen Tags, die direkt einer mp3 Datei oder einem Ordner zugewiesen sind wurden ohne Probleme abgespielt.
Sobald wir wieder zu Hause im bekannten WLAN waren funktionierte alles wieder wie erwartet und auch die „m3u Tags“ spielten das was sie sollen.

Ich finde die m3u Option unheimlich praktisch, da die Jungs viele Hörspiele in 2 Sprachen haben und ich so sehr komfortabel die beiden mp3 Files einem Tag zuweisen kann. Somit kann nämlich mit der „next“ Taste dasselbe Hörspiel dann einfach in einer anderen Sprache nochmal gespielt werden, ohne dass ich die Ordnerstruktur abändern muss :wink:

Tritt dieses Phänomen sonst noch bei jemand auf?

Guter Punkt, das ist ein Bug.

Ursprünglich hatte ich diesen Modus nur für Webradios implementiert, aber kurz danach auch für Dateien von SD erweitert. Aber wie man auch an meinem Kommentar sehen kann, habe ich die u.g. Sektion nicht überarbeitet. Und daher kam jetzt der Fehler bei dir heute.
Ergo: Die Einschränkung, dass WLAN verfügbar sein soll, muss da raus. Aber ich muss testen, ob ich noch was abfangen muss, wenn man über diesen Weg Webradio anfragt (gemischte Playlist z.B.) und dann aber kein WLAN verfügbar ist. Glaube aber nicht.

Danke für den Hinweis.

@onkelbobby: Habe den Bugfix soeben eingecheckt:

1 „Gefällt mir“