Once a picture capture date is adjusted, the paragraph it belongs to should change but it does not.
Definition of “paragraph”: In events or photo stream, the pictures are automatically inserted into paragraphs. For example, paragraph could be April 27, 2025.
Expected behavior
Once a picture capture date is adjusted, the paragraph it belongs to should change based on the new date
Steps required to reproduce
Adjust capture date of a picture by changing the year
When I reproduce this locally, the paragraphs do get adjusted, but it takes a few seconds, because, as it stands, the changes need to propagate through the file system, which includes a few time delays (metadata gets written → file system watcher detects the changed/added XMP sidecar → change gets synchronized into the library catalog → the photo stream view gets notified of the changed file → the list of files/paragraphs gets refreshed). These delays are in place in order to allow accumulating multiple changes in cases where many files change in a short amount of time, but in this case it adds up quite a bit more than it should and I will see whether I can quickly add the same shortcut mechanism here as the one used when using the rotate left/right functionality.
However, if in your case the paragraph actually never gets updated at all, then this may indicate an issue with the file system watcher. Is the library stored on a standard NTFS volume, or is there possibly anything special about the location? NTFS, VFAT and connected network shares all worked correctly in my tests.
it adds up quite a bit more than it should and I will see whether I can quickly add the same shortcut mechanism here as the one used when using the rotate left/right functionality.
Implemented for the next release, the refresh will then occur almost instantly.
Is the library stored on a standard NTFS volume, or is there possibly anything special about the location? NTFS, VFAT and connected network shares all worked correctly in my tests.
The library is stored in an external drive, the file system is exFAT.
Do you suggest to change it to NTFS?
exFAT should work fine, too. Have you observed/tested whether file system changes in general are being picked up by the application? For example, renaming or moving an image from within the file manager, while the corresponding library is loaded in Aspect at the same time, and then observing whether that is being reflected in Aspect after a few seconds.
If that part does work, I think everything should be fine with the next update. If not, this particular issue should still be fixed, but it would definitely cause other issues.
Have you observed/tested whether file system changes in general are being picked up by the application? For example, renaming or moving an image from within the file manager, while the corresponding library is loaded in Aspect at the same time, and then observing whether that is being reflected in Aspect after a few seconds.
Tested when the Aspect application was closed.
Move picture from <Library>/<year>/<Individual Photos>/<subfolders> to <Library>/<year>/<Individual Photos>
When I started the application, Aspect was able to find the new path.
(for clarity: the behavior described in my first post is still there)
Can you do the same test while Aspect is running and the library is loaded? A single file would be enough. What could possibly go wrong here is that the application isn’t getting notified properly as soon as the files got moved and thus the file scanning never gets triggered. However, a full scan is always done right after the library has been loaded, so the problem wouldn’t be visible in that case.
I’ll try to get out a release with the main fix included tomorrow.
Can you do the same test while Aspect is running and the library is loaded? A single file would be enough.
Tested successfully. I moved 1 file (.jpg and all related files) from <year>/<event>/<subfolder> to <year>/<event> while the app was running.
I’ve then opened the image in Aspect and also selected " Show in explorer" and everything worked fine.