Support for importing m3u and xspf playlists of local files

[mYnDstrEAm]

Split off from #1315: M3u and xspf import would be very useful...this way you could easily open your existing playlists. A way to export to m3u and xspf playlists would be useful too.

I still can't get Nuclear to play local files which is a/the basic functionality: #1008

But m3u/xspf playlist support would be what I'd need most after this works so I can just open playlists I created with another music app and Nuclear still seems to work for some other users.

---

Mainly concerning export / saving playlists as m3u files: I don't know if m3u can store paths to streams, that may be possible too. In any case you wouldn't need to store the particular stream but only the track file location. If you don't just import m3us but also allow saving/exporting to m3u files, it probably wouldn't be much of a problem if other music players can't play some of the tracks in the playlist (these tracks can or would display as faulty).

This would already be immensely useful if you could just import M3Us to start a new playlist which at first only has local tracks. You can then also add streams and save it as a playlist in another format.

Info about xspf playlists: these allow tree structured playlists, you need to save a playlist to xspf in VLC if you have folders in it.

[nukeop]

I still can't get Nuclear to play local files which is a/the basic functionality

Not really. This is primarily a streaming player. The local files are a bonus, which is a bit of a hindrance to be honest, since it requires a lot of maintenance, contains some of the most bothersome pieces of code in the entire program, requires recompiling native binaries, and the list goes on. All to create something that will never be as convenient as any actual Linux music player that's built for local files.

[mYnDstrEAm]

My main use-case for the app, and imo to some extent the point of it, is mixing local tracks with streaming tracks. Which other apps can do so? It's hugely useful and much needed.

For example you could get, at some point, recommended tracks mixed in based on local tracks. You can't do this with local-only or streaming-only apps. And if it finally worked it would be as convenient as these or better. Sure, it's probably difficult and I didn't know it was requiring a lot of maintenance and so on but it's more than worth it, maybe other devs could help (I think for that it would need to get better known and before that can happen the basic functionalities should work).

[a0kami]

Hey, I don't seem to be affected by #1008 so I looked into it, export is working..

Yet, local files are indeed causing a few issues:

• In some cases, even if your playlist was made from the local library, the "locality" of the tracks can be lost, and is then streamed rather than played locally.
• If the playlist track doesn't have a "locality", the playlist file export will have tracks with invalid uri (currently set to 'null'), but you seamed ok with that, although this could cause all the playlist tracks uri to slowly become invalid over multiple export/import processes and defeats the purpose.

Finally, the current json import process is the counterpart of the json export thus embedding useful track metadata whereas when importing from either m3u or xspf we have to decide how we add tracks, whether we create the entity from the ground-up or if we should look into local library. Anyway, I currently can import playlists but can't seem to achieve track "locality", so it streams whatever it finds based on the title/name.

Maybe I can pull it off, but I'll have to make some troubleshooting and write some tests, and eventually there will be some maintenance/refactor, whatever nukeop feels like what's best.

---

I don't know if m3u can store paths to streams

It seems to be specifically designed for streams, but definitely out of scope for now afaic.

Info about xspf playlists: these allow tree structured playlists, you need to save a playlist to xspf in VLC if you have folders in it.

Both m3u and xspf support relative and absolute paths but have different drawbacks. While absolute paths are easy to implement, allow for multiple directory files into the same playlist and the actual playlist file to be moved, they are not interoperable through different OSes. On the other hand, relative paths needs to be resolved from the yet to create playlist file's location, but is more suitable for "album"-like playlists (single directory) but should allow interoperability.

Both are useful but serve a different purpose, do you want to track files wherever on your computer, or do you want to sort and share specific directories ? I'm not sure yet how to decide or ask the user for either one though.

[nukeop]

I think there should already be some tests for adding local tracks to favorites and then playing them, which I'm pretty sure starts playing them from the disk if they're available. It all hinges on the existence of a flag in those saved tracks in favorites/playlists.