feat: playlist management support

[huynhsontung]

Closes #110, closes #596

[huynhsontung]

@United600 Can you take a quick look at this PR and let me know what you think? I think the core functionality of the playlist system is complete. There are some outstanding UX polish items, such as raising a notification when a playlist is created or an item is added to an existing playlist via the context menu, but this PR is getting too big. I'm considering opening a new PR for UX polishes.

[United600]

Feature wise is in a good state.

Why was JSON chosen for the playlist save file format? I'm not a fan of it. We should adopt a format that works across all applications. In the absence of an official standard, the best approach is to use the most widely supported format, and currently that's .m3u8.
A XML-based format would be ideal, but I don't think XSPF or SMIL are as widely used/supported.

The save location should be more convenient/accessible, the main music library folder (plus some "Playlists" or similar named folder) should be the default destination.

[huynhsontung]

All good points. To give more context on this implementation:

• Why JSON and not M3U8? The Playlist object is a C# class, and saving and loading JSON are well supported. It is convenient to convert C# structures to JSON and back. I plan to give users the option to export and import playlists, so JSON becomes an easy choice. JSON is easy to handle and human-readable, allowing users to manipulate the playlist directly. I have not thought about M3U8 to be honest. It is a good idea to support something that other players can play out of the box. I assume there will be additional steps to convert from our internal C# structure to an M3U8 structure. We could add it as an extra export and import option.
• The playlist location. There should be a separation between internal app data and the user space. Moving data between these two layers should be an explicit action in the app: export and import. So the playlists will always be saved in the internal app storage as JSON (for now) and only saved into a user location when the user wishes to do so.

[United600]

It's probably easier (XML-based format would be preferable), but IMHO still the wrong choice. And if we use M3U we don't need internal app data and user space divide. And M3U, or other playlist interoperable formats, are just as human-readable as JSON.

I was surprised to learn that we don't support opening offline M3U files (we can parse IPTV URL files just fine). We might have broken it at some point, I just tested versions 0.12.0 to 0.14.X with no luck.

[United600]

Can confirm that we can correctly* parse M3U files, but only when using the "Open URL" button.

* Files without a full path will not play. To fix this, we'll need to append the path of the folder where the playlist file is located to each file.

[huynhsontung]

I think the separation between the internal app store and the user space is essential, regardless of our formatting choice. As a developer, I don't want users to handle the internal data the app depends on, nor do I want my app to operate on data from users' spaces. For now, internal data is stored in JSON and Protobuf, but I plan to switch to something more standard, like SQLite. Another benefit of this separation is that we can store more data in the internal storage, such as playlist ID, that we don't need to expose to the user and don't need to conform to the file format standard (in case of M3U).

[huynhsontung]

If we want to support

Can confirm that we can correctly* parse M3U files, but only when using the "Open URL" button.

* Files without a full path will not play. To fix this, we'll need to append the path of the folder where the playlist file is located to each file.

I guess it makes sense: VLC wouldn't know where to open these files with a relative path because it has no concept of the current directory where the playlist file is opened. We can make it work if we handle this case from the Screenbox side. But that's something for another PR.

[United600]

I think the separation between the internal app store and the user space is essential, regardless of our formatting choice. As a developer, I don't want users to handle the internal data the app depends on, nor do I want my app to operate on data from users' spaces. For now, internal data is stored in JSON and Protobuf, but I plan to switch to something more standard, like SQLite. Another benefit of this separation is that we can store more data in the internal storage, such as playlist ID, that we don't need to expose to the user and don't need to conform to the file format standard (in case of M3U).

I can concede on the separation, but not on the format. I don't see a reason to handle intermediate formats when we can use interoperable playlist formats directly.

I quite like how Media Player manages and creates playlists, and should be the gold standard.

Gravacao.2026-02-11.141135.mp4

Even allows external editing 🥹:

Gravacao.2026-02-11.141701.mp4

Our opening behavior isn't really consistent:

Gravacao.2026-02-11.142402.mp4

Gravacao.2026-02-11.142604.mp4

[huynhsontung]

Okay that live external editing is pretty neat. I've never noticed it could do that. Right now there is no way to 'export' a playlist so the underlying storage format is not as important. Then the features to be implemented for the playlist system are:

• Import and export as m3u8
• Option to convert the current play queue into a playlist
• Notifications for playlist events (creation, deletion, name changes)
• Thumbnail collage for playlist

Since the core functions of the playlist system are done (saving, loading and playing from a playlist). I think we should still push ahead with the system as-is and implement other features after the initial release and maybe early feedback.

[United600]

Since the core functions of the playlist system are done (saving, loading and playing from a playlist). I think we should still push ahead with the system as-is and implement other features after the initial release and maybe early feedback.

Sure, in my view, this will increase the technical debt, though the core functionality is solid.
I'm not fond of the icon, and the UI could use some refinement, but that can be addressed later.

[huynhsontung]

The icons will need some of your touch. I'm running out of system icons.