Posts: 1,231
Threads: 194
Joined: May 2015
Reputation:
13
Now we have Song IDs, will these also be used to identify songs during library sync operations?
Johan
johanvromans.nl — hetgeluidvanseptember.nl — mojore.nl -- howsagoin.nl
Samsung Galaxy Note S7FE (T733) 12.4", Android 13.0, AirTurn Duo & Digit (Gigs).
Samsung Galaxy Note S4 (T830) 10.5", Android 10.0 (maintenance and backup).
Samsung A3 (A320FL), Android 8.0.0 (emergency).
Posts: 13,363
Threads: 301
Joined: Apr 2012
Reputation:
235
I hadn't planned on that, since none of the logic currently references that song ID field. I suppose if it would be useful to people I could add an option to match on the song ID instead of the title, or I could make that the default behavior if people agree that that makes sense. It would match first on song ID, and then fall back to title if there is no match. A matching database ID is searched for in the case that multiple matches are found.
Thanks,
Mike
Posts: 1,231
Threads: 194
Joined: May 2015
Reputation:
13
It seems a natural purpose for the Song ID to me...
Johan
johanvromans.nl — hetgeluidvanseptember.nl — mojore.nl -- howsagoin.nl
Samsung Galaxy Note S7FE (T733) 12.4", Android 13.0, AirTurn Duo & Digit (Gigs).
Samsung Galaxy Note S4 (T830) 10.5", Android 10.0 (maintenance and backup).
Samsung A3 (A320FL), Android 8.0.0 (emergency).
Posts: 13,363
Threads: 301
Joined: Apr 2012
Reputation:
235
I've modified the matching logic in the library sync to match on song ID if possible, and if no match is found, it falls back to title.
I really don't want to add logic to enforce a unique song ID. There are scenarios where you may want to have multiple songs with the same song ID. For example, a master device may want to load two different versions of a song, but on the connected slave device, you always want it to load one specific version regardless of what the master is loading. So the master should be allowed to assign the same song ID to multiple songs if desired. I also don't really think auto-generating song IDs for every song would be that useful in practice either. If you did this on two different tablets, there is no guarantee that the song IDs would match up, and it's actually dangerous if they dont, as now all of the songs would be matched up incorrectly.
The database itself already has a primary key on the song table which is used for certain kinds of matching (like with the library sync). This ID is rarely useful when comparing two different libraries, but with the library sync functionality, it's a useful check as the two libraries may be mostly identical. So the song table ID is used to distinguish the correct match when dealing with multiple songs whose title matches, or in the case where no song title match is found (i.e. a song was renamed) but a matching song exists in the library (the creation date is also compared in this instance to ensure it really is a match).
If you performed renames of songs and MobileSheetsPro couldn't match those songs up correctly during a sync, it means your two databases don't match. In that case, you really need to back up the library on one device using Settings->Backup and Restore->Backup Library, then restore that library on the other device (effectively wiping out the library and replacing it). If you do this, then the two libraries will match up perfectly even after renaming songs. It also ensures songs that are created from that point forward will have the same ID in the song table assuming you only add songs on one device at a time and sync in between changes.
Mike
Posts: 13,363
Threads: 301
Joined: Apr 2012
Reputation:
235
I also have a number of really important bug fixes coming in the next release, especially when synchronizing using Google Drive or OneDrive. So hopefully it works for you as is, but if not, I'm finishing up the changes in the update and will be releasing it as soon as possible (most likely tomorrow or Sunday).
Mike