I can think of plenty of cases where everyone in a band imports the files for the week off Dropbox and sets up their libraries. Maybe one user is in charge of setting things up for the week and then syncs to the other tablets. If one of the other users jumps the gun and imports the file to practice it beforehand, the library sync shouldn't treat that as a completely different song from the one the band leader created. If you disagree with that, then you've basically said that the library sync feature only makes sense for users with identical databases, otherwise it can't be used. As far as replacing the file with a different one, the current merge logic tries to find matching files, but if it can't, it makes due with matching titles and considers the songs the same.
Whether the user enters a custom number or a UUID (which would be pretty clunky as those are typically 16 characters long), the end result is the same. This puts a lot of burden on users with large libraries, and would be tedious for users to manage. I'm not sure how often this really matters - are we trying to solve a problem that is going to be extremely likely with most users libraries, or is it more of a fringe case? While I can see libraries having multiple songs with the same names, I would expect most people have different files for those songs. If users are making copies of existing songs just to have different annotations, notes, etc, then that is the one situation where I won't have a good answer except prompting for a decision (and hopefully that will encourage users to uniquely name their songs to avoid further prompts/conflicts).
MSPs sync in a nutshell goes like this:
1) Server sends database, file path mappings and its storage directory path to client to start the merge.
2) Client sends same information and database to server and a list of all file sizes (so that server doesn't have to request this later when looking for differences)
3) Server iterates over every song in its library to see if a merge is necessary. To find a matching song, from the other library, title is compared first, then file second, and anything with a matching database id is preferred.
4) The merging of a song does the following:
a) Checks files for differences and if a difference is detected, either enqueues the file to be sent from the server at the end of the merge, or requests the file from the client right away
b) Checks file properties for differences (page order, text display settings, etc). Files must always be merged first because other things like the properties per page depends upon them being the same for each song
c) Metadata is checked next, which covers most of the data in the song (group assignments, links, bookmarks, scroll settings, duration, rating, cropping, rotation, etc)
d) After metadata, MIDI commands are synchronized
e) Next comes annotations
5) If a song doesn't exist on one of the devices the song is either added or deleted depending upon one-way vs two-way sync
6) Server now iterates over all client library songs, processing songs that weren't already encountered. These songs are added or removed depending upon the merge direction
7) Server notifies client that it's waiting for it to finish sending every requested file (the next step requires the client to be finished and ready)
8) When client is ready, the server writes all of the changes it has made to the databases. This persists all of the changes encountered during merging in both the local and client databases.
9) Next, groups are merged (it's important this happens at this step so that all metadata has been processed for individual songs). This typically just results in setlists being merged, as the other metadata should be the same
10) The updated database is sent from the server to the client, which closes its database and opens the new one
11) The server sends over the list of songs for the client to delete (if any were marked for deletion during the merge)
12) The server sends over all of the enqueued song/audio files. This happens late in the merge so that the client has all of the updated database fields from the server indicating where files should be placed and the correct songs to associate them with.
13) The server sends a notification to the client that it is done
14) When the client is done receiving files, it sends a notification to the server that the merge is complete
Is that basically what you wanted BRX? I should mention that the merge process checks literally every field the application supports when looking for differences, so there is a ton of code, but it all runs quickly as it's light-weight.
Mike
Whether the user enters a custom number or a UUID (which would be pretty clunky as those are typically 16 characters long), the end result is the same. This puts a lot of burden on users with large libraries, and would be tedious for users to manage. I'm not sure how often this really matters - are we trying to solve a problem that is going to be extremely likely with most users libraries, or is it more of a fringe case? While I can see libraries having multiple songs with the same names, I would expect most people have different files for those songs. If users are making copies of existing songs just to have different annotations, notes, etc, then that is the one situation where I won't have a good answer except prompting for a decision (and hopefully that will encourage users to uniquely name their songs to avoid further prompts/conflicts).
MSPs sync in a nutshell goes like this:
1) Server sends database, file path mappings and its storage directory path to client to start the merge.
2) Client sends same information and database to server and a list of all file sizes (so that server doesn't have to request this later when looking for differences)
3) Server iterates over every song in its library to see if a merge is necessary. To find a matching song, from the other library, title is compared first, then file second, and anything with a matching database id is preferred.
4) The merging of a song does the following:
a) Checks files for differences and if a difference is detected, either enqueues the file to be sent from the server at the end of the merge, or requests the file from the client right away
b) Checks file properties for differences (page order, text display settings, etc). Files must always be merged first because other things like the properties per page depends upon them being the same for each song
c) Metadata is checked next, which covers most of the data in the song (group assignments, links, bookmarks, scroll settings, duration, rating, cropping, rotation, etc)
d) After metadata, MIDI commands are synchronized
e) Next comes annotations
5) If a song doesn't exist on one of the devices the song is either added or deleted depending upon one-way vs two-way sync
6) Server now iterates over all client library songs, processing songs that weren't already encountered. These songs are added or removed depending upon the merge direction
7) Server notifies client that it's waiting for it to finish sending every requested file (the next step requires the client to be finished and ready)
8) When client is ready, the server writes all of the changes it has made to the databases. This persists all of the changes encountered during merging in both the local and client databases.
9) Next, groups are merged (it's important this happens at this step so that all metadata has been processed for individual songs). This typically just results in setlists being merged, as the other metadata should be the same
10) The updated database is sent from the server to the client, which closes its database and opens the new one
11) The server sends over the list of songs for the client to delete (if any were marked for deletion during the merge)
12) The server sends over all of the enqueued song/audio files. This happens late in the merge so that the client has all of the updated database fields from the server indicating where files should be placed and the correct songs to associate them with.
13) The server sends a notification to the client that it is done
14) When the client is done receiving files, it sends a notification to the server that the merge is complete
Is that basically what you wanted BRX? I should mention that the merge process checks literally every field the application supports when looking for differences, so there is a ton of code, but it all runs quickly as it's light-weight.
Mike