Feature request: Custom Playlists

[pabera]

I have searched the issues and code a little bit to figure out if custom playlists are supported at the moment (not Spotify). With custom playlists, I mean that the user can 1) create a playlist, 2) assign any audio file to it (from different folders), 3) assign the playlist to an RFID card and 4) play the playlist (including shuffle etc).

Some old issues (#126) suggest that it exists but browsing the code, I only found a handful occurrences so I am sure it's currently not a concept for Phoniebox. Have you guys planned something like this?

Otherwise, I might have a look into it.

---

On a different note ... I wonder what the differences are between Latest_Folder_Played and Latest_Playlist_Played. I haven't been able to figure this out. Am I right with Latest_Folder_Played being a relict that's obsolete?

https://github.com/MiczFlor/RPi-Jukebox-RFID/blob/6915db203ad8aa36d665001fde0ab96845cc852b/scripts/rfid_trigger_play.sh#L336-L337

[MiczFlor]

Hi @pabera that's a nice feature to have. And I had the idea at one point to add a second button to the local files when you browse the folders that allows "add to playlist". It would then need to have a second UI where you can "clear playlist", and remove single files from playlist. Changing the order would also be nice. Or - back to the hope page of the web app - "add all files from folder to custom playlist". It's not rocket science, requires one playlist file that's "custom". But it's a bit of work. Regarding the last-folder last-playlist conundrum. I can not answer for sure. Have to check the code again. I added this at some point when I added the possibility to play content recursively. In this case, the playlist name is different from the folder, because the folder path contains "/". Not sure if this is still an issue right now.

[pabera]

Thanks for your answers and explanations. I did not check the code with regards to recursive playlists which could indeed be handled differently. In the end, it doesn't really matter - I just wanted to confirm whether the concept of a "playlist" already exist.

I see two options to implement this feature:

1) Use text files to store the individual lists as you suggested. Straight forward and simple to implement, I agree. I see one issue with this though: If users update their folder structure of music files and audiobooks (deleting, renaming, reorganizing), updating the playlists will be difficult.

I therefore suggest another approach, which potentially allows even more features down the line.

2) Introduce a database where all files are listed in a flat way (similar to iTunes library). In the same database, files could be organised in playlists. In fact it's a refactor, the Phoniebox would only play playlists instead of real folders (or recursive folders). Additional benefits could be things like play count (or other statistics), ratings or search (interesting for greater libraries). I know some of this goes way beyond the "simple kids radio" approach, I am most interested in simple playlists and some dynamic playlists like the "Top Ten" or "Newly Added" :-)

The Pi has enough resources to run a database. I am suggesting a MongoDB (or another NoSQL DB) as it is the perfect fit for a document store. You can keep it up to date by either introducing a file event listener or a manual library update that runs one a user performs it after uploading new music.

I am aware of the changes this requires. But I wanted to drop this here. Maybe you guys have even more ideas how to benefit from a DB or maybe this is a bad idea .. let me know your thoughts

[MiczFlor]

Hi @pabera the scale of what a raspberry pi phoniebox would hold in local files, my thoughts are: introducing a database is not necessary and will only complicate the ongoing development, i.e. upgrades might then also involve changing the database structure. For the time being, I will hold on to my belief. And possibly change it when I see it should make that step that you suggest.

[pabera]

For the time being, I will hold on to my belief

I understand your concern. I will fork the project and give it a try.

... upgrades might then also involve changing the database structure.

The benefit of a NoSQL database is that it does not not have a structure.

[MiczFlor]

I was just about to suggest NoSQL as a good middle ground :) Often others see things, I am not quite seeing yet. in other words: I am looking forward to your work. All the best Micz

[s-martin]

@pabera implemented in future3, we could close this. :)

[pabera]

I think my original use case was not supporting m3u, but instead Playlist Management in the UI. If we see it from this perspective, we could make this a future3 request.