GNOME Bugzilla – Bug 740985
rb_sync_state_make_track_uuid() should understand which fields are available on target
Last modified: 2018-05-24 18:25:26 UTC
In an IRC conversation about why RB re-sends existing (i.e. already on the device) tracks to an Android device "moch" said: > mtp kind of sucks, it loses a lot of the metadata that rb uses to match up > tracks in the sync process, so it ends up copying them over again and then points out where the matching is computed: https://git.gnome.org/browse/rhythmbox/tree/sources/sync/rb-sync-state.c#n102 which points to rb_sync_state_make_track_uuid (RhythmDBEntry *entry) which uses the following to create a hashable string: g_string_printf (str, "%s%s%s%s%lu%lu", rhythmdb_entry_get_string (entry, RHYTHMDB_PROP_TITLE), rhythmdb_entry_get_string (entry, RHYTHMDB_PROP_ARTIST), rhythmdb_entry_get_string (entry, RHYTHMDB_PROP_GENRE), rhythmdb_entry_get_string (entry, RHYTHMDB_PROP_ALBUM), rhythmdb_entry_get_ulong (entry, RHYTHMDB_PROP_TRACK_NUMBER), rhythmdb_entry_get_ulong (entry, RHYTHMDB_PROP_DISC_NUMBER)); So clearly one or more of these fields (likely GENRE and/or DISC_NUMBER) is not available with MTP. Could this function not be made sensitive to which fields are actually available on a remote device instead of assuming that all devices support all of those?
the problem is that this information is not available. mtp doesn't tell you it's not giving you all the metadata, it just doesn't give it to you.
I was thinking it would work more along the lines of RB understanding what a remote device is capable of telling it (and taking that into account when computing the track uuid) rather than the remote device telling it what it can tell it. Of course, the latter is ideal, to be sure, but not likely based in reality, at least where MTP is concerned. Would it be great if MTP could tell RB? But of course. But let's try at least to work with what we have instead of waiting for the perfect world, yes? In the mean-time perhaps we can work (better than we do now) with what we have and request that MTP be extended in the future to announce what it can tell us and then take advantage of that when it comes.
(In reply to comment #2) > In the mean-time perhaps we can work (better than we do now) with what we have > and request that MTP be extended in the future to announce what it can tell us > and then take advantage of that when it comes. I think it'll be pretty difficult to get microsoft to change the protocol to suit us.
(In reply to comment #3) > > I think it'll be pretty difficult to get microsoft to change the protocol to > suit us. Maybe. But that is why I said that getting the protocol extended would be in parallel to RB working better within it's known/existing limitations. But is the MTP spec actually an MS-only spec? The most prevelent spec references I could find were over at USB.org: Media Transfer Protocol v.1.1 Spec and MTP v.1.1 Adopters Agreement in http://www.usb.org/developers/docs/devclass_docs/MTPv1_1.zip I wonder which spec Android follows since they are probably the most prolific device implementation. In any case, if a RFE is not specifically to cover some niche area, (which I don't think such an RFE as this one would be) why assume it will be difficult to get it added? No harm in asking right?
In any case, bottom line is whether the spec is extended or not, the limitations of MTP are known, so why not try to work with them better?
I'm currently doing some small work on the mtp-sync and have the same problem: genre and disc number aren't on mtp files and can't be compared. Is there anything against just changing the function call to this?: g_string_printf (str, "%s%s%s%lu", rhythmdb_entry_get_string (entry, RHYTHMDB_PROP_TITLE), rhythmdb_entry_get_string (entry, RHYTHMDB_PROP_ARTIST), rhythmdb_entry_get_string (entry, RHYTHMDB_PROP_ALBUM), rhythmdb_entry_get_ulong (entry, RHYTHMDB_PROP_TRACK_NUMBER));
Created attachment 310256 [details] [review] sync: Remove disc number from uuid. Problem is that on MTP devices some files are recognized as different by the sync though they should be the same. This is because some files on disc store the disc number which isn't transferred by the MTP device. Removing the disc number from the uuid which is used to check for file equality solves this problem. Fixes
*** Bug 730021 has been marked as a duplicate of this bug. ***
I'm not interested in ruining things everywhere to suit mtp's limitations.
(In reply to Valentin Pratz from comment #7) > Created attachment 310256 [details] [review] [review] > sync: Remove disc number from uuid. Yes, this needs to be done only for the MTP case, not generally. (Without having looked at the source he says) maybe the comparison function needs to be specific to the protocol, or at least any protocol that wishes to override the general comparison function should be able to.
-- 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/1382.