elementary
Add support for loading/saving m3u playlists
Fixes https://github.com/elementary/music/issues/515 And a 11 years old bug: https://bugs.launchpad.net/elementaryos/+bug/1308876
Ctrl+S allows saving the playlist, but i am not sure how to expose it in the UI. I included it so half the support isnt in Needs Design Hell.
the implementation skip extended M3U flags. Meaning Extm3u playlists will still work. URL will be skipped, so the coverage is alas not complete
when looping through the files and upon finding a m3u file in the list, Application.loop_through_files just call the support method that knows how to read m3u, and replace it with an array of all the files in it it is then up to playback to check what in there actually exists
Saving M3U pretty much just loops through the queue to put it all in a file.
In my testing, I saved a playlist from Music but it failed to open. I am going to look into it more because I am not sure if the issue is how it is saving or how it is loading.
Hmmm.... It worked in my testing. I will test more cases/see if i can get issues
@ryonakano i would leave exposing in the UI saving a playlist to another PR? it may be better in its own discussion rather than block the whole backend code alltogether
testing m3u a few days before ready to review
Potentially an issue down the line, but files opened from drag&Drop have correct URI While those opened via portal get something prefixed as "file:///run/user/1000/doc/13138d8d"
both work for loading/saving playlists just the same. It is just awkward, and im not sure it would work the same with other audio players ? (Amberol cant open m3u at all so theres that)
My access to a PC will be very limited in the coming weeks, i will not be able to take care of this for a couple weeks
Vague thought but once this is merged, technically we could bin the whole "save/restore queue in dconf" and simply save/load from a m3u file in the data folder
That would avoid two separate code blocks for the same thing (less moving parts), and skip dumping shit of dubious length in dconf
maybe also not relying on dconf but straight up loading a file could also speed up recovery.
Saving the playlist only on app closing (or DE session disconnecting if the apps are allowed grace time) would also reduce disk writes and cpu usage
@danirabbit this has now conflicts because of the new QueueView branch being merged, despite sitting ready since months. I will not resolve it. It is up to you if you want this.
It feels like another slap in the face.
@teamcons apologies. I hadn't kept up with this since when I was last reviewing it you had said you didn't have time to work on it and another reviewer had taken over since.
I think regardless this shouldn't be in a part of the UI. So resolving my next review comment would also be avoiding conflicts anyways
@teamcons apologies. I hadn't kept up with this since when I was last reviewing it you had said you didn't have time to work on it and another reviewer had taken over since.
I think regardless this shouldn't be in a part of the UI. So resolving my next review comment would also be avoiding conflicts anyways
you couldve flagged this last summer, about 5 month ago. And if i do it, another random PR will go in at any point in the months of waiting and the whole discussion will begin anew
Im gonna spend the time on apps where it isnt pointless
@teamcons My notifications are extremely full. I reviewed Leonhard's branch because it was a very easy review to do and it happened to be in my notifications when I had a free moment. It's nothing personal against you, just a matter of circumstance. I'm sorry that you feel demotivated, but I fear the expectations you've placed on me to prioritize reviewing your branches are not something I can live up to.