02-09-2025, 06:17 AM
If you populate the song ID field and share a .mss file, if that .mss file is imported on another device, a setlist will be constructed to match, and every song will default by trying to match on song ID first. If users populated that field without understanding the consequences, their setlist would appear to have random songs in it that don't match the titles from the other tablet. That's what I'm worried about with users misusing that field just as a piece of metadata. This applies to .msf files too - the wrong song could be updated if a .msf file is imported and song ID was populated on both devices without realizing the implications. This also applies to the library synchronization feature (I recently had to help unravel sync issues for a user because of this). So this costs me time with customer support.
I do have plans to add code to force song IDs to be unique, as I do agree that it is problematic otherwise. I also want to split the song ID field up, and have two different fields: song ID, and synchronization ID. The former would be just for display purposes, and I could make it an open text field so that users can enter anything (like the custom field). The synchronization ID would be for matching purposes, and would be hidden by default to prevent accidental use. The only thing I have to decide on is how to handle entries that users have already added. I could just duplicate the same value to each field so I don't break libraries that are utilizing song ID correctly, but this wouldn't fix the libraries of the users who didn't use it correctly.
As far as formatting, it turns out I can set a flag to have indented output, so I just switched that on - thanks. I'll have to consider new song ID filtering options when I rework the filters.
I'll make the change for the duplicate setlist detection if the option to create was selected instead of update, and we will see if anyone complains about the change in behavior.
Mike
I do have plans to add code to force song IDs to be unique, as I do agree that it is problematic otherwise. I also want to split the song ID field up, and have two different fields: song ID, and synchronization ID. The former would be just for display purposes, and I could make it an open text field so that users can enter anything (like the custom field). The synchronization ID would be for matching purposes, and would be hidden by default to prevent accidental use. The only thing I have to decide on is how to handle entries that users have already added. I could just duplicate the same value to each field so I don't break libraries that are utilizing song ID correctly, but this wouldn't fix the libraries of the users who didn't use it correctly.
As far as formatting, it turns out I can set a flag to have indented output, so I just switched that on - thanks. I'll have to consider new song ID filtering options when I rework the filters.
I'll make the change for the duplicate setlist detection if the option to create was selected instead of update, and we will see if anyone complains about the change in behavior.
Mike