I added some folders to the MusicBox directory and created m3u playlists for them.
After a rescan (“mopidy local scan” and “service mopdiy run local scan” executed), the individual files were picked up (“Found 67 tracks…”). However, the playlists did not appear in the web UI.
2015-03-22 10:30:03,079 - INFO Found 610 files in media_dir.
2015-03-22 10:30:03,167 - INFO Checking 517 tracks from library.
2015-03-22 10:30:08,099 - INFO New MPD connection from [::ffff:127.0.0.1]:4$
2015-03-22 10:30:10,154 - INFO Removing 0 missing tracks.
2015-03-22 10:30:10,454 - INFO Found 67 tracks which need to be updated.
2015-03-22 10:30:10,468 - INFO Scanning...
I tried refreshing the browser in various ways (F5 / shift F5 / restart browser) but the new playlists wouldn’t show up.
The 67 tracks found during rescan are the actual mp3 files. There is no mention of the playlists, however.
Subsequent rescans did not pick up anything new.
They only appeared after executing “service mopidy restart”.
This time, the log is pretty clear:
2015-03-22 11:06:56,686 - INFO Loaded 24 local playlists from /music
2015-03-22 11:06:56,718 - INFO Loaded 584 local tracks using sqlite
2015-03-22 11:06:56,986 - INFO Starting Mopidy core
So, I assume this is a bug in the local rescan feature. It recognizes the correct amout of files (610) but does not do anything else than adding the mp3 files to the library. In case you’re wondering, the missing 2 files are two JPGs that are somewhere in the music folders.
The local scan only affects the music files, not the playlists. There’s no index/library of the playlists like there is for the music. To make this more obvious, M3U playlists handling was moved out of Mopidy-Local and into a new Mopidy-M3U extension a few days ago. This split will be there in the upcoming Mopidy 1.0 release.
In Mopidy-M3U’s current implementation, M3U playlists are loaded from disk on startup and then cached in memory. When a frontend calls the core.playlists.refresh() method, the cache is updated. I’m guessing that nobody called the refresh() method in your case, so you had to restart Mopidy to see the new playlists. For example, as far as I can see, the MPD frontend never use core.playlists.refresh(). Feel free to open an issue on Mopidy about Mopidy-M3U’s somewhat stupid caching. I’d like to see Mopidy-M3U get some improvements in the near future and become a good extension in its own right, and not just be a dark corner of Mopidy-Local.
I don’t know if the caching of M3Us is really that “stupid”. Scanning the file system for new/updated playlist files is a potentially expensive operation, and caching is probably desirable for other playlist providers (Spotify), too.
So I’d say it’s a shortcoming of the client/mpd frontend if it doesn’t provide a means to refresh.
Unfortunately, MusicBox does not have any means of refreshing the library from the web interface right now.
A rescan is of course a possibly expensive operation and I did not suggest to have a background scanning option. But manually triggering a “rescan” should IMO include all types of files that are relevant just as it is done on service start. Spotify playlists are probably not cached as files anywhere, right? So maybe it would be possible to offer a command to trigger a rescan of all physical files (that are relevant to active extensions). That way a user does not have to triggere separate commands for all different extensions.
core.playlists.refresh() affects all playlists, from all extensions providing playlists. No need to handle “physical files” (whatever that means) specially.