support playlist-files

[DJCrashdummy]

is it somehow possible to support playlist-files (for those who manage their music libraries mainly offline/local) like at least .m3u/.m3u8 (RFC 8216)? maybe additional .xspf and .pls wouldn't hurt either...

[paulijar]

Playlist files are not currently supported by the app but this would be a feasible idea for improvement. This is also related to #645 which would be one way to support playlist files.

[DJCrashdummy]

thanks for the reply and considering this enhancement!

well... this is somehow related (concerning the basic functionality) to #645, but to make it more clear, i'm taking about a m3u-file saved in a normal folder like the audio-files and it should also be as easy usable (just click and play) as the audio-files!
an optional simultaneous import into the database (or even via cron) is another feature. - if an import isn't done via cron (or optional), a setting to define the default behavior (just play | just import | both) may be useful...

[DJCrashdummy]

"Audio Player" seems to somehow support m3u and pls with some kind of a possibly additional workaround... maybe some code can be reused?
anyway, it does not really work at my testing instance (but it is likely that i messed something up with extensive testing prior trying this) and i also still want to keep using "Music" because i like its handling and GUI much more! 👍 - not to forget about having an ampache-backend is also quite nice. 😉

[paulijar]

Thanks for the tip. Just don't start holding your breath yet, there are lots of things I would like to do for the Music app and only limited amount of time to use on it. Hence, I will probably not start working on this one any time soon. On the other hand, there are occasionally other contributors, so maybe someone will pick this up :).

[DJCrashdummy]

yes, i don't dare to expect a sudden implementation, especially at FOSS projects which are maintained in spare time.
i only wanted to collect all even possibly useful information/hints at one place, as i was playing around with Audio Player a bit...

[greku]

Currently, I get the m3u files listed in the music app. I was wondering whether that is normal or not? They show up under "Artiste inconnu" which means "Unknown Artist" as shown below with just the name of the file without the extension (as album and title).
For me, there is no use to see it listed. Shouldn't the m3u file just be ignored by the music app.

[paulijar]

@greku That's not supposed to happen. But now this happens because Nextcloud 13 (and later?) associate the mime type audio/mpegurl to the .m3u files. Nextcloud 12 associated the generic mime type application/octet-stream on these files.

On the other hand, the scanning logic of the Music app searches and indexes all the files with mime type audio/*. So probably we should add a specific logic to filter out files of type audio/mpegurl while scanning the library.

I was first puzzled about why I hadn't seen this happen even though I'm using NC13 on my daily use and I do have some .m3u files within my music library folder. It turned out that the mimepart column in the oc_filecache table had not been automatically updated on these files when I had updated from NC12 to NC13. Hence, I had to upload new .m3u files to see this problem happen.

[greku]

@paulijar Not sure anymore how I updated my nextcloud installation. I updated quite recently, and I think previously existing m3u files are now listed in the music app (I don't think I updated them since).
I guess we would need to modify this line:

music/utility/scanner.php

Line 112 in 7780dbc

} elseif (Util::startsWith($mimetype, 'audio')) {

into: } elseif (Util::startsWith($mimetype, 'audio') && $mimetype!='audio/mpegurl') {

Is there a way to fix existing records in the db? Is it possible to include some script in next update that would find all the tracks with the mime audio/mpegurl and remove them using the deleteTracks from the trackbusinesslayer.php?

[paulijar]

@greku

I updated quite recently, and I think previously existing m3u files are now listed in the music app

Okay. I'm not using the most recent patch of 13.x so it's possible that the migration problem I faced has already been fixed. Or then the migration just randomly failed on my installation, who knows.

I guess we would need to modify this line:

music/utility/scanner.php

Line 112 in 7780dbc

} elseif (Util::startsWith($mimetype, 'audio')) {

into: } elseif (Util::startsWith($mimetype, 'audio') && $mimetype!='audio/mpegurl') {

Yes, but that's not enough. We need to modify also the following line, or otherwise the m3u files will be found again as "new unscanned files" each time the Music app is started:

music/utility/scanner.php

Line 400 in 7780dbc

return $folder->searchByMime('audio');

The built-in php function array_filter should do the trick there.

Is there a way to fix existing records in the db? Is it possible to include some script in next update that would find all the tracks with the mime audio/mpegurl and remove them using the deleteTracks from the trackbusinesslayer.php?

Yes, that's possible, but it will likely take a bit more effort. Care has to be taken that the operation will not become awfully heavy even on large installations (think about thousands of users and millions of files). This kind of repair steps are registered at

music/appinfo/info.xml

Line 32 in 2736c51

<repair-steps>

. There's currently a <pre-migration> step which takes care of database schema changes. What we are discussing here, should probably be an <install> step instead.

It should be rather easy to find the tracks to remove from the DB table oc_music_tracks since this table stores the mimetype of each track in string format.

[paulijar]

I opened a new issue for the problem reported by @greku as it's clearly distinct from the original feature request. Lets continue discussing the bug within the new issue.

[berkeleynerd]

Just want to add my support for import/export of playlists in standard m3u format. The thought of losing my playlists is always a bit frightening.

[dgedgedge]

Just want to add my support for import/export of playlists in standard m3u format. The thought of losing my playlists is always a bit frightening.

This would be great to provide for a longterm archive of the music collection, and in particular to the playlists.

[jlombs]

I added a bounty for this feature implementation--import/export of .m3u in particular, ideally with read/write to .m3u files in a subfolder within the music home directory for easy offline/local management as mentioned by the OP. This enables both peace-of-mind against playlist loss and the bonus ability to create 'fancier' intelligent playlists using other frameworks that can then just be ingested by Music and updated by the user as desired, removing the need for the Music app itself to have such capabilities built-in.

I'm happy to help pay for the time and effort toward the solution, since it's been a hold-up for me personally. Anyone else out there, feel free to add to the bounty if you'd like.

To contributors of Music: thanks for the work you do!

https://www.bountysource.com/issues/59958063-support-playlist-files

[berkeleynerd]

I've added to the bounty. The total is now $220.

[berkeleynerd]

Bounty now stands at $370.00USD. Recovered a bit from another expired bounty I was funding.

[paulijar]

That's a hefty bounty. I'll try to resolve this during this summer.

[paulijar]

The support for playlist files has now been released in the Music v0.16.0.

• Playlists can be exported in the m3u8 format
• Playlists can be imported from m3u8, m3u, and pls format files
  • The playlist files must contain relative paths to files in user's library for the importing to work
• Playlist files of types m3u8, m3u, and pls can be played directly within the Files app
  • Again, playlist files must define the included tracks using relative paths

[jlombs]

Outstanding, works like a charm. Thanks @paulijar !