GNOME Bugzilla – Bug 750642
CONTAINER_MAX_TRACKS in plugins/grilo/rb-grilo-source.c seems artificially low
Last modified: 2018-05-24 18:31:34 UTC
I just started playing with dnla in rhythmbox and it works fine except that CONTAINER_MAX_TRACKS seems artificially low. HEg if I open a playlist it downloads 1000 tracks. I can play and do whatever with those 1000 and wasn't blocked by ui. However, there was a button at the bottom right that said I could download another 1000. For large playlists, you might have to click this button multiple times and you need to do this each time you open the playlist. I am currently using the following locally: Index: rhythmbox-3.1/plugins/grilo/rb-grilo-source.c =================================================================== --- rhythmbox-3.1.orig/plugins/grilo/rb-grilo-source.c +++ rhythmbox-3.1/plugins/grilo/rb-grilo-source.c @@ -51,7 +51,7 @@ /* maximum number of tracks to fetch before stopping and * requiring the user to ask for more. */ -#define CONTAINER_MAX_TRACKS 1000 +#define CONTAINER_MAX_TRACKS 15000 /* number of items to fetch at once */ #define CONTAINER_FETCH_SIZE 50 and it seems to work with only the lightest testing. I don't know what the best number to use is-- I choose one that was large enough for my needs (ie, the user experience is the same for me when when using dnla or daap in my current environment (I've not hit this issue when connecting to a daap server; haven't looked to see what the daap plugin is doing)). Do note the number is exposed in the ui, so choosing a multiple of 1000, 5000 or 10000 seems best.
-- 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/rhythmbox/issues/1411.