Refreshing tracks from library

[foobarth]

Hi,

if i read the code correctly, track database is only refreshed after a successful login at startup, but never again - until mopidy gets restarted. Is there any way to force such a refresh? Problem is if you add tracks from All Access via the Web Player, they never show up in Mopidy until you restart the daemon. As i tend to leave the box on for days without a reboot (Raspberry Pi), this kinda sucks :)

[hechtus]

I agree, but I don't know how to refresh on demand. I implemented the library refresh() function but as far as I know it is not called on user request.

[foobarth]

Too bad. Even mopidy-spotify does not implement this, at least not for library content. They refresh playlists at some triggers like adding, removing, etc... Maybe ask someone from the mopidy core team on how to implement refreshing of "cloud" content.

[foobarth]

Sorry for closing... :)

[adamcik]

Frontends can trigger http://docs.mopidy.com/en/latest/api/core/#mopidy.core.PlaylistsController.refresh which in turn will call http://docs.mopidy.com/en/latest/api/core/#mopidy.core.LibraryController.refresh For MPD this is connected to the update command, so if a client ask for an update there this code path will be triggered.

As for mopidy solving this, we could add a periodic call of refresh every x minutes, though I suspect that the requirements for this in various backends differ enough that having a one size fits all might be bad. An example of this would be a DB backed backend that doesn't keep anything in memory, where the whole concept of refreshing doesn't really make sense. Though for them we could just have the refresh call be a NOOP and my concerns might not be warranted.

[hechtus]

In general, I would not recommend a periodic call of refresh. In the past I was not able to trigger library.refresh() with an MPD client through "update database". Is it something new?

[hechtus]

I just tried to do "Updated Database" with gmpc and MPDroid. It seems that '''library.refresh()''' is not called, with both clients. I used the latest version of mopidy 0.18.1.

[ScottG489]

I noticed this issue also and a nice person on the mopidy IRC channel whipped this up for me. The playlist refresh seems to take significantly longer than the library refresh although this may just be because I have more songs in my playlist. This is obviously a temporary solution but perhaps it will offer some insight to help design something permanent.

Refresh library

curl -X POST -H Content-Type:application/json -d '{ "method": "core.library.refresh", "jsonrpc": "2.0", "params": { "uri": null }, "id": 1 }' http://localhost:6680/mopidy/rpc

Refresh playlists (this takes a few minutes)

curl -X POST -H Content-Type:application/json -d '{ "method": "core.playlists.refresh", "jsonrpc": "2.0", "params": { "uri_scheme": null }, "id": 1 }' http://localhost:6680/mopidy/rpc

[wilberking]

I'd like to understand what this is suppose to do:

Refresh library

curl -X POST -H Content-Type:application/json -d '{ "method": "core.library.refresh", "jsonrpc": "2.0", "params": { "uri": null }, "id": 1 }' http://localhost:6680/mopidy/rpc

Will this force all my albums, artists, song to be loaded? That's what seems to be taking a long time to occur right now with my Gmusic library. It seems that Playlists are there and persist; but selecting artists and albums take a while and are not cached.

[ScottG489]

If you add a song to your Google Play Music library, it won't be reflected in mopidy. Calling that will update it reflect the current state of your online library. It's possible that it does indeed need to be run every time and is not cached. However, I don't interact with my library very much and do so instead with my playlists so I might not have noticed. I never noticed any sort of caching though. Every time I started mopidy with this plugin enabled it seemed to take the same amount of time to start and when I was debugging it looked like it was pulling everything down in my playlists each time.

[jodal]

Regular background refreshing was implemented by @felixb in commits 9406ef7 and 008c8b1 over a year ago. It'll be part of the upcoming 1.0.0 release.