06-08-2018, 01:29 AM
It's only not a lot of additional work if I don't try to resolve file deltas between the two. If I just copy the database over from one device, and then copy every file over without worrying about whether it actually needs to be copied over, and I update the file paths using similar logic to a library restore (although I'd have to support the path mappings), then the logic doesn't get complicated. If I instead try to do comparisons of every file on one tablet with files on the other tablet (accounting for differences in paths) in order to avoid doing unnecessary copying, then things get more complicated. The same is true if I have to figure out which files are no longer needed after the sync completes to ensure orphan files aren't left behind. One option would be to perform a clean library first, but that can take awhile on Windows 10 (it's not too bad on Android). So the question is, if I try to support that kind of library replacement, how smart do you want it to be about handling files on each device? That will dictate how much work is involved and when I can support it.
As far as identifying identical songs on multiple devices, assigning uuids isn't really sufficient either. Two users with separate libraries may import the same file off Dropbox let's say, then add their own annotations and other fields. If they merge their libraries, my logic should handle the fact that they both created the same song (assuming they used the same title), and merge it. If a UUID was assigned, each device would have assigned a different UUID, so the two songs wouldn't be considered the same. Using something like a UUID only works in the case where you have devices with identical databases, in which case I can just use the ID column of the songs table as that's unique and would be identical. I'm actually already using the song ID if multiple matching songs are found with the same title and files and the device databases happen to match, so I think I've already handled that case. I don't think I can make the assumption that users who use this feature can be expected to have synchronized the libraries on the devices at some point beforehand using a library backup/restore. This is why I think, in the case that libraries are being merged with very different databases, that it's acceptable to prompt the user to pick the correct song (and perhaps use index as the default selection). This will encourage people who want to use this feature to not have songs with identical titles and files in their library, or for them to use a library backup/restore first to avoid conflicts.
One possible way to handle this issue would be to add a new song number field that has to be unique. Users could then assign the same numbers to songs in different libraries, and the merge could use that as the basis. This would need to be a new option in the merge, perhaps called "Match songs using number". This would require a lot of work for users to have to go through and assign numbers to all their songs though, so I'm not sure that's a great answer either.
Thanks for the feedback,
Mike
As far as identifying identical songs on multiple devices, assigning uuids isn't really sufficient either. Two users with separate libraries may import the same file off Dropbox let's say, then add their own annotations and other fields. If they merge their libraries, my logic should handle the fact that they both created the same song (assuming they used the same title), and merge it. If a UUID was assigned, each device would have assigned a different UUID, so the two songs wouldn't be considered the same. Using something like a UUID only works in the case where you have devices with identical databases, in which case I can just use the ID column of the songs table as that's unique and would be identical. I'm actually already using the song ID if multiple matching songs are found with the same title and files and the device databases happen to match, so I think I've already handled that case. I don't think I can make the assumption that users who use this feature can be expected to have synchronized the libraries on the devices at some point beforehand using a library backup/restore. This is why I think, in the case that libraries are being merged with very different databases, that it's acceptable to prompt the user to pick the correct song (and perhaps use index as the default selection). This will encourage people who want to use this feature to not have songs with identical titles and files in their library, or for them to use a library backup/restore first to avoid conflicts.
One possible way to handle this issue would be to add a new song number field that has to be unique. Users could then assign the same numbers to songs in different libraries, and the merge could use that as the basis. This would need to be a new option in the merge, perhaps called "Match songs using number". This would require a lot of work for users to have to go through and assign numbers to all their songs though, so I'm not sure that's a great answer either.
Thanks for the feedback,
Mike