GNOME Bugzilla – Bug 344616
refresh DAAP database if needed
Last modified: 2018-05-22 12:09:10 UTC
When I add music on the DAAP server side, I wish that the client be refreshed at some point to get the new tunes that have been put in. According to RB developers, banshee does it.
This could be implemented in the rightclick menu of the daap server.
We should be able to do this by polling the DAAP server. Requests to /update?session-id=x&revision-number=y return the new revision number. If it changes, we'd then update the whole song list. Apparently there's a way to get just the changes, but no one seems to know how it works.
Created attachment 102881 [details] [review] initial daap refresh patch
I have put together a small patch that should at least be a start on this. The patch adds a new state to DAAP connections called DAAP_REFRESH. The connection state is set to DAAP_REFRESH every x seconds by a timeout. If the version has changed then the state is set to DAAP_GET_REVISION_NUMBER (which should force an update), otherwise it is set to DAAP_DONE. Note: This is my first patch and I am not exactly experienced with C, so there are probably some serious problems. Any comments/suggestions would be much appreciated.
Created attachment 102883 [details] [review] fixes stupid mistake
Here is a new patch that removes the timeout when the share is disconnected. Also, I can confirm that it does refresh the daap share's main song list. There are some issues with refreshing any shared playlists, though.
Created attachment 102972 [details] [review] removes timeout on disconnect
Created attachment 102979 [details] [review] updates no longer hang with mt-daapd, more debugging output
Created attachment 103037 [details] [review] updated patch The patch no longer attempts to add a song to the database if already exists, which wasn't fatal but caused a lot of debug output. There is also a start on updating playlists. I am not sure of the best way to update the source playlist. It is done through a connection callback when it first connects to the share, but that signal is not fired again. Maybe we need to add a "refreshed" signal?
Created attachment 103285 [details] [review] updated patch Here is what should be close to the final version. It now updates DAAP playlists with new tracks.
Created attachment 103528 [details] [review] updated patch The new patch stores diff information for the playlists based on changes from the previous revision. This lets us add and remove tracks from the source without completely nuking it. Issues: mt-daapd does not incriment the revision number if songs are removed from the database or from a playlist. This could lead to non-existent songs in playlists or inaccurate playlists.
Created attachment 106345 [details] [review] updated patch Added a menu item to manually force a refresh
Created attachment 110004 [details] [review] updated to work with daap changes
Wondering if I should continue to maintain this patch or what? Is there any interest in it?
This patch seems interesting but I'm not using DAAP at all so I can't really review it :-/
Created attachment 122326 [details] [review] slightly updated, fixed, commented a bit too I've fixed a few cosmetic and other problems with this patch, and added some notes on things I don't think it does correctly. I haven't tested my version at all because rhythmbox's daap server doesn't maintain a revision number at all (it always says 5) and I'm too lazy to set up another server at the moment.
A few more things: - refresh_playlists_from_connection needs to remove playlists that have been deleted from the server - should use GSlice to allocate RBDAAPPlaylistDiff structures
Thanks you for the feedback. I am going to work on updating the patch with your comments over the next few days.
Thanks for your patience. I'll try to be quicker to review it next time around. I think I'd be happy to commit a patch that handled renamed and deleted playlists correctly, and we could deal with the other bits later. If you're at all interested in working on the changes in rhythmbox to make it report useful revision numbers to DAAP clients, I can probably write out a few thoughts on how that should work.
I just wanted to open a new bug report to suggest a new feature: rhythmbox should save the daap library in a local cache and read that cache by default instead of demanding the complete library, because large daap libraries take a lot of time to be loaded. But now that I read this bug report, it sounds as if it is already implemented and you wanted to have the option to update the local cache. If so, the cache doesn't work here. rhythmox can only remember the daap server's library within a rhythmbox session, but the next time I start rhythmbox, it is requesting the whole library again. I'm using the Ubuntu 8.10 package of rhythmbox. Or do I completely misunderstand the issue here?
There is no cache, and no one is attempting to add one.
*** Bug 614951 has been marked as a duplicate of this bug. ***
Reassigning to libdmapsharing since that's where most of the work would need to be done for this now.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/libdmapsharing/issues/1.