Describe the bug
PiGallery2 does not reliably regenerate an existing thumbnail when the underlying source image is modified or replaced but retains exactly the same filename/path.
The full-size image is updated correctly when opened, but the thumbnail and therefore folder/album cover can continue to show the old version indefinitely.
I first encountered this with a batch of older JPEG photographs from around 2011 that had incorrect orientation. After correcting the orientation of the original files in Windows, PiGallery2 displayed the corrected image when the photo was opened, but continued to display the old incorrectly oriented thumbnail.
I have tested this extensively.
Reproduction:
- Allow PiGallery2 to index a JPEG and create its thumbnail.
- Modify the original JPEG, for example rotate/correct its orientation.
- Save it using exactly the same filename and path.
- Run Indexing.
- Run Cover Filling.
Expected behavior:
PiGallery2 should detect that the source image has changed and regenerate the thumbnail.
Actual behavior:
The old thumbnail remains. Opening the actual photograph displays the newly modified/correctly oriented source image.
I have also tried the much more destructive sequence:
Gallery Reset -> Full Indexing -> Cover Filling
Despite completely rebuilding the gallery database, the stale thumbnail still remains.
This suggests that the generated thumbnail cache is independent of the gallery/index database and is not invalidated when the source file changes while its pathname remains the same.
I have also observed related stale-thumbnail behaviour when the underlying image is removed or replaced while the existing media path remains relevant to PiGallery2.
If the original photograph is simply deleted and its path no longer exists at all, PiGallery2 does remove it as expected.
The problem occurs when the same pathname continues to exist, for example when an image is replaced or modified in place. In that situation the old thumbnail can remain even though the image now stored at that path is different. Opening the photograph displays the current source image correctly, while the thumbnail can continue showing the previous version.
Reliable workaround
Changing the source filename or path reliably fixes the problem.
For example:
Some Street (1).jpg
changed to:
Some St (1).jpg
PiGallery2 then treats it as a new media item and generates a fresh thumbnail.
This strongly suggests that the cached thumbnail is tied to the pathname and is not being invalidated when the contents of the file at that path change.
Why the workaround is problematic
My gallery is a large, deeply structured archive:
- Approximately 22,894 photographs
- Approximately 7,575 folders
- Approximately 30.57 GB
File naming is meaningful.
I deliberately use filenames containing (1), together with alphabetical sorting, to control folder covers. I also use PiGallery2 ratings as a secondary method of controlling which photographs are selected as covers.
Many of my directory paths are already very long and close to practical Windows path-length limits. Arbitrarily changing filenames merely to force PiGallery2 to regenerate a thumbnail can therefore be difficult.
Sometimes I have had to abbreviate something such as:
Street -> St
simply to create a different pathname without making the already-long path any longer.
There are also cases where there is no convenient or sensible part of the filename that can be abbreviated.
Existing automated workaround
For another part of my archive, images are generated automatically from Microsoft Word directory entries.
When one of those Word documents changes, my automation deliberately creates the replacement image using a new numbered filename.
This behaviour was designed specifically after I discovered this PiGallery2 thumbnail issue.
Because the generated image has a new pathname, PiGallery2 creates a fresh thumbnail and the updated image appears correctly.
This works reliably, but it should not be necessary to change the pathname simply to make PiGallery2 recognise that the underlying source image has changed.
Photo/video (optional) that causes the bug
This does not appear to depend on one particular photograph. I have reproduced it with multiple JPEG files.
I can provide a simple before/after JPEG example if required.
Screenshots (optional)
I can provide screenshots showing:
- The stale thumbnail/folder cover
- The same photograph displaying correctly when opened full-size
- The Gallery Reset, Indexing and Cover Filling controls
Server logs (optional)
No obvious server error is displayed.
The modified source image itself is served correctly when opened, so the problem appears to be specifically with invalidation/regeneration of the cached thumbnail rather than access to the source photograph.
Environment
Server OS: Linux, PiGallery2 running in Docker on a UGREEN DXP6800 Pro NAS
Client OS: Windows 11
Browsers tested: Microsoft Edge and Google Chrome
Gallery size: approximately 22,894 photographs in 7,575 folders, approximately 30.57 GB
Used app version
Docker latest / stable 3.5.2
Edge build
Not yet tested.
This is a production Docker installation on a NAS with a large gallery, so I have not replaced the stable production container with the potentially unstable edge image.
The issue is consistently reproducible on the current stable latest image.
The public demo is not suitable for reproducing this particular issue because reproduction requires modifying or replacing the underlying source image while retaining exactly the same filesystem path.
Possible improvements
Any of the following would solve or significantly improve the problem:
- Automatically invalidate an existing thumbnail when the source file modification time, size or contents change.
- Add a Regenerate Thumbnail option for an individual photograph.
- Add a Regenerate Thumbnails option for a folder.
- Add a maintenance task to clear/rebuild the thumbnail cache separately from Gallery Reset.
- Remove stale cached thumbnails promptly when the corresponding source image is deleted.
Additional observation
Gallery Reset followed by Full Indexing and Cover Filling does not solve the problem.
The only consistently reliable method I have found is changing the source pathname.
Therefore this appears to be a thumbnail cache invalidation problem rather than simply an indexing/database refresh problem.
Even if this cannot be changed immediately, documenting the behaviour may help other users who encounter stale thumbnails and find that Gallery Reset, Indexing and Cover Filling do not correct them.
Describe the bug
PiGallery2 does not reliably regenerate an existing thumbnail when the underlying source image is modified or replaced but retains exactly the same filename/path.
The full-size image is updated correctly when opened, but the thumbnail and therefore folder/album cover can continue to show the old version indefinitely.
I first encountered this with a batch of older JPEG photographs from around 2011 that had incorrect orientation. After correcting the orientation of the original files in Windows, PiGallery2 displayed the corrected image when the photo was opened, but continued to display the old incorrectly oriented thumbnail.
I have tested this extensively.
Reproduction:
Expected behavior:
PiGallery2 should detect that the source image has changed and regenerate the thumbnail.
Actual behavior:
The old thumbnail remains. Opening the actual photograph displays the newly modified/correctly oriented source image.
I have also tried the much more destructive sequence:
Gallery Reset -> Full Indexing -> Cover Filling
Despite completely rebuilding the gallery database, the stale thumbnail still remains.
This suggests that the generated thumbnail cache is independent of the gallery/index database and is not invalidated when the source file changes while its pathname remains the same.
I have also observed related stale-thumbnail behaviour when the underlying image is removed or replaced while the existing media path remains relevant to PiGallery2.
If the original photograph is simply deleted and its path no longer exists at all, PiGallery2 does remove it as expected.
The problem occurs when the same pathname continues to exist, for example when an image is replaced or modified in place. In that situation the old thumbnail can remain even though the image now stored at that path is different. Opening the photograph displays the current source image correctly, while the thumbnail can continue showing the previous version.
Reliable workaround
Changing the source filename or path reliably fixes the problem.
For example:
Some Street (1).jpg
changed to:
Some St (1).jpg
PiGallery2 then treats it as a new media item and generates a fresh thumbnail.
This strongly suggests that the cached thumbnail is tied to the pathname and is not being invalidated when the contents of the file at that path change.
Why the workaround is problematic
My gallery is a large, deeply structured archive:
File naming is meaningful.
I deliberately use filenames containing (1), together with alphabetical sorting, to control folder covers. I also use PiGallery2 ratings as a secondary method of controlling which photographs are selected as covers.
Many of my directory paths are already very long and close to practical Windows path-length limits. Arbitrarily changing filenames merely to force PiGallery2 to regenerate a thumbnail can therefore be difficult.
Sometimes I have had to abbreviate something such as:
Street -> St
simply to create a different pathname without making the already-long path any longer.
There are also cases where there is no convenient or sensible part of the filename that can be abbreviated.
Existing automated workaround
For another part of my archive, images are generated automatically from Microsoft Word directory entries.
When one of those Word documents changes, my automation deliberately creates the replacement image using a new numbered filename.
This behaviour was designed specifically after I discovered this PiGallery2 thumbnail issue.
Because the generated image has a new pathname, PiGallery2 creates a fresh thumbnail and the updated image appears correctly.
This works reliably, but it should not be necessary to change the pathname simply to make PiGallery2 recognise that the underlying source image has changed.
Photo/video (optional) that causes the bug
This does not appear to depend on one particular photograph. I have reproduced it with multiple JPEG files.
I can provide a simple before/after JPEG example if required.
Screenshots (optional)
I can provide screenshots showing:
Server logs (optional)
No obvious server error is displayed.
The modified source image itself is served correctly when opened, so the problem appears to be specifically with invalidation/regeneration of the cached thumbnail rather than access to the source photograph.
Environment
Server OS: Linux, PiGallery2 running in Docker on a UGREEN DXP6800 Pro NAS
Client OS: Windows 11
Browsers tested: Microsoft Edge and Google Chrome
Gallery size: approximately 22,894 photographs in 7,575 folders, approximately 30.57 GB
Used app version
Docker latest / stable 3.5.2
Edge build
Not yet tested.
This is a production Docker installation on a NAS with a large gallery, so I have not replaced the stable production container with the potentially unstable edge image.
The issue is consistently reproducible on the current stable latest image.
The public demo is not suitable for reproducing this particular issue because reproduction requires modifying or replacing the underlying source image while retaining exactly the same filesystem path.
Possible improvements
Any of the following would solve or significantly improve the problem:
Additional observation
Gallery Reset followed by Full Indexing and Cover Filling does not solve the problem.
The only consistently reliable method I have found is changing the source pathname.
Therefore this appears to be a thumbnail cache invalidation problem rather than simply an indexing/database refresh problem.
Even if this cannot be changed immediately, documenting the behaviour may help other users who encounter stale thumbnails and find that Gallery Reset, Indexing and Cover Filling do not correct them.