So I looked at the code, and if you just replace the file on the file system, it will not update the page order. There are a couple of reasons why this is so:
1) I no longer have access to the previous version of the file, so I don't know if the full range of pages was being used (I don't save that information currently).
2) If you had a page order of 1-3 in a 5 page file, and that was intentional, and then you update to a 6 page file, you probably don't want the application resetting your page order just because an extra page was added to the file
The only time I will update the page order is if the previous page order references a page greater than the maximum page of the new file. In that case, I have to reset the page order because it's invalid at that point. So if you want the page order to be correctly updated when swapping in a new version of a file where the number of pages has changed, you'll have to use the swap file feature. The other option would be for me to start adding additional information in the database about the properties of the file such as the maximum number of pages so that I can access this information even if the file no longer exists. I'm not opposed to that, but the problem is if I add that field to the database, I then need to populate it, which is only possible by opening every single file in the library. I'm not sure I want to do that as part of the database upgrade phase, as some people have huge libraries and that could take a long time. That means I would have to populate it the next time a song is loaded and I detect that information about the file is missing in the database. If you replaced files you hadn't loaded recently, then I wouldn't be able to properly handle those. This new database field also would only make sense for PDFs, as text/chord pro files have dynamic content with no fixed number of pages and image files are always just one page.
Kind regards,
Mike
1) I no longer have access to the previous version of the file, so I don't know if the full range of pages was being used (I don't save that information currently).
2) If you had a page order of 1-3 in a 5 page file, and that was intentional, and then you update to a 6 page file, you probably don't want the application resetting your page order just because an extra page was added to the file
The only time I will update the page order is if the previous page order references a page greater than the maximum page of the new file. In that case, I have to reset the page order because it's invalid at that point. So if you want the page order to be correctly updated when swapping in a new version of a file where the number of pages has changed, you'll have to use the swap file feature. The other option would be for me to start adding additional information in the database about the properties of the file such as the maximum number of pages so that I can access this information even if the file no longer exists. I'm not opposed to that, but the problem is if I add that field to the database, I then need to populate it, which is only possible by opening every single file in the library. I'm not sure I want to do that as part of the database upgrade phase, as some people have huge libraries and that could take a long time. That means I would have to populate it the next time a song is loaded and I detect that information about the file is missing in the database. If you replaced files you hadn't loaded recently, then I wouldn't be able to properly handle those. This new database field also would only make sense for PDFs, as text/chord pro files have dynamic content with no fixed number of pages and image files are always just one page.
Kind regards,
Mike