03-21-2019, 08:15 AM
Geoff,
Last modified timestamps for songs are preserved after performing a restore. On Android, MobileSheetsPro tries to also set the last modified timestamps of files to what is stored in the database but this is not guaranteed to work on every device. I have no control over this - it's an OS file thing. On Windows 10, I have no ability to control the last modified timestamp - Microsoft does not allow it to be changed. If the file timestamp changes, then when you load a song, it will scan for changes, which can result in the song updating the last modified timestamp for itself as well.
You can certainly replace the database file from one in the backup, but the same problem may occur - if the last modified timestamp for a file in the database does not match the last modified timestamp on the actual file system, the song will scan for changes and the last modified timestamp will be changed as a result of this. I'm not sure I have a good answer for this. I think what I will have to do is make the logic used when scanning for changes more intelligent. If no change occurs to the song, then I won't update the last modified timestamp. One thing I could do to make this logic a lot faster is to add a crc calculation field to the files table in the database. I could then just calculate a CRC on the new version of the file, and if it matches the old version then I know nothing has changed. Until that is implemented though, I'll have to check to make sure the file type matches, the number of pages matches, and the size of each page matches.
Mike
Last modified timestamps for songs are preserved after performing a restore. On Android, MobileSheetsPro tries to also set the last modified timestamps of files to what is stored in the database but this is not guaranteed to work on every device. I have no control over this - it's an OS file thing. On Windows 10, I have no ability to control the last modified timestamp - Microsoft does not allow it to be changed. If the file timestamp changes, then when you load a song, it will scan for changes, which can result in the song updating the last modified timestamp for itself as well.
You can certainly replace the database file from one in the backup, but the same problem may occur - if the last modified timestamp for a file in the database does not match the last modified timestamp on the actual file system, the song will scan for changes and the last modified timestamp will be changed as a result of this. I'm not sure I have a good answer for this. I think what I will have to do is make the logic used when scanning for changes more intelligent. If no change occurs to the song, then I won't update the last modified timestamp. One thing I could do to make this logic a lot faster is to add a crc calculation field to the files table in the database. I could then just calculate a CRC on the new version of the file, and if it matches the old version then I know nothing has changed. Until that is implemented though, I'll have to check to make sure the file type matches, the number of pages matches, and the size of each page matches.
Mike