[itsme]

Sometimes the (correct) "PageOrder" info is replaced unexpectedly by the full range of pages in the book. This might even happen on stage, in that case it can be very annoying.
The Albums tab shows correct PageOrder info
   
When I open the song editor a message pops up saying something like "changes are applied", but it disappears  too quickly to read it or to take a screenshot. In the the song editor both the preview and the shown PageOrder still seem to be correct.
   
Opening a song (without calling the song editor before) shows the same effect: it shows the first page of the book instead of the correct song. This is the case that is very confusing if it happens on stage!
   
Replacing the file with "Swap File" doesn't help.
Windows Explorer shows that the file had not been changed for a long time.
   
I manage the files myself. Song files are synchronized between Win10 devices by GoogleDrive, synchronized from GoogleDrive to Android devices via FolderSync Pro or copied manually. My main MSP database is on a Win10 device and copied manually to other Win10 or Android devices.
A possible cause could be that MSP's file change detection is mislead. Copying something to an Android device sets the file's timestamp to current date and time even if the file is unchanged. Thus the time stamp of a file is not a reliable information any more if the file was changed or not.
Anyway, even if a fakebook PDF has really been changed, destroying the PageOrder info as it happens here is the wrong way to go.
My workflow worked fine for a long time. The issue came up a wile ago.

[itsme]

I investigated some more.
On 2022-05-02 I exported a songlist of my Django Fakebook that showed tis issue for a number of songs. I fixed all PageOrder entries that showed up wrongly, a new songlist from 2022-05-11 seemed correct, proving that my fixes were there.
Now the issues are back again and affects many, if not all of my 36 fakebooks that I have in MSP.
The critical problem is, that the issue is not visible until a song is opened, either on the song screen or in the song editor.

[Zubersoft]

Do you have Settings->Other Settings->Reset Page Order if File Changes enabled? That would cause the page order reset you are seeing. I just want to check that first before we investigate further.

Mike

[itsme]

Thank you.
Yes, "Reset Page Order if File Changes" was set. Switching it OFF fixed the issue.
I was not aware of having it switched on. If ON is the default that's not a good idea. Default values of newly added settings should always preserve the previous behaviour.
I have to reset lost PageOrder entries manually to avoid losing the links to groups and setlists. Luckily there are not too many songs that are affected.
How does MSP detect if a file has been changed?

[Zubersoft]

Off is the default behavior. I'm guessing installing an update must have toggled it on. There is some weird kind of issue with Google's preference framework that can rarely cause settings to be changed as a result of installing an update. I've never been able to reproduce it myself and it's hard to determine how many users are impacted it. If you haven't made too many changes, you can go to Settings->Backup and Restore->Restore Automatic Database Backup and revert the library to an earlier version which would fix the page orders that were modified. I may consider looking into a different way to save application settings in the future as it seems crazy to me that settings can change like that. 

As far as detecting if a file has been changed, MobileSheets just looks at last modified timestamp of the file versus what has been saved in the database. If the two timestamps are different, that triggers the logic to scan for any changes in the file. 

Mike

[itsme]

My issue is fixed. Thanks for your support.
I exported a songlist containing PageOrder and sorted it by PageOrder. So it was easy to identify about 20 songs with wrong PageOrder. It was a piece of cake to copy correct PageOrder values from my original CSV files.
Knowing what goes on makes it easy to avoid that in future. I just have to take care that "Reset page order" is always OFF.

Anyway: as soon as files are copied between Android and Win10, no matter if this is done manually or by a sync tool, a changed time stamp is not a reliable info that a file has been changed. Calculating and storing a hash value might be a better criterion.
This is NOT a feature request. As stated above, I'm fine with the current state.

[Zubersoft]

Yes, I have an entry in my bug tracking system to start storing a hash value in the database to use for comparisons, so that's been on my mind and is certainly something I will change. This will also speed up certain features like the sync library feature as all of the hashes are calculated on the fly right now.

Thanks,
Mike