Quoting some docs on the libgnome-desktop thumbnailer,
* #GnomeDesktopThumbnailFactory also handles failed thumbnails. If a
* thumbnailer can’t generate a thumbnail for a file (e.g. because the file is
* corrupt or because the right video codecs aren’t available), it returns a
* non-zero exit status. The thumbnail factory then writes an entry to
* <filename><envar>$XDG_CACHE_HOME</envar>/thumbnails/fail/
* gnome-thumbnail-factory/</filename> which is named after the hash of the
* input file URI (just like a successful cached thumbnail). For future queries
* for thumbnails for that file, #GnomeDesktopThumbnailFactory can immediately
* return an error after looking up the fail entry.
*
* If a file changes content, #GnomeDesktopThumbnailFactory will generate a new
* thumbnail because each cached image has associated metadata (stored as PNG
* tEXt keys) storing the full URI of the thumbnailed file (to check for hash
* collisions) and its last modification time at the point of thumbnailing. If
* the stored modification time doesn’t match the file’s current one, a new
* thumbnail is generated.
So, in your test scenario, I would expect the thumbnail to update after
adding metadata, since the modification time will have changed. Checking
here, I believe there is a bug.
mkdir test ; cd test
rm -rf ~/.cache/thumbnails/
# simulate a thumbnailing failure
sudo cp -v /usr/share/thumbnailers/{totem.thumbnailer,totem.thumbnailer.bkp}
sudo sed -i 's!^Exec=.*!Exec=false!' /usr/share/thumbnailers/totem.thumbnailer
ffmpeg -f lavfi -i "sine=f=440:d=5" \
-f lavfi -i "color=c=red:s=600x600" \
-map 0 -map 1 \
-c:a aac \
-c:v mjpeg \
-frames:v 1 \
-disposition:v:0 attached_pic \
test_with_cover.m4a
xdg-open .
# thumbnail failed, will not be shown
$ find ~/.cache/thumbnails/
/home/charles/.cache/thumbnails/
/home/charles/.cache/thumbnails/fail
/home/charles/.cache/thumbnails/fail/gnome-thumbnail-factory
/home/charles/.cache/thumbnails/fail/gnome-thumbnail-factory/94e17c2d132e88a2a4d2d86b4a20bb65.png
$ exiftool -v
/home/charles/.cache/thumbnails/fail/gnome-thumbnail-factory/94e17c2d132e88a2a4d2d86b4a20bb65.png
| grep -i mtime
[adding Thumb::MTime]
ThumbMTime = 1764842597
$ date -d @1764842597
Thu Dec 4 10:03:17 AM GMT 2025
# restore the thumbnailer
$ sudo cp -v /usr/share/thumbnailers/{totem.thumbnailer.bkp,totem.thumbnailer}
'/usr/share/thumbnailers/totem.thumbnailer.bkp' ->
'/usr/share/thumbnailers/totem.thumbnailer'
# refresh Nautilus in /test - since mtime + contents hasn't changed, wouldn't
expect a new thumbnailer
$ touch -m test_with_cover.m4a
$ stat --printf="%y\n%Y\n" test_with_cover.m4a
2025-12-04 10:06:47.064518519 +0000
1764842807
# BUG: Nautilus is not showing a thumbnail, even though mtime is newer than
failed path, it didn't retry the thumbnailer.
$ rm
/home/charles/.cache/thumbnails/fail/gnome-thumbnail-factory/94e17c2d132e88a2a4d2d86b4a20bb65.png
# Now the the thumbnail shows up.
I'll look at seeing why this happening and make a patch. Thank you for
the report.
** Changed in: nautilus (Ubuntu)
Assignee: (unassigned) => Charles (charles05)
** Changed in: nautilus (Ubuntu)
Status: Incomplete => In Progress
** Summary changed:
- Nautilus does not show embedded album art thumbnails for .m4a files
+ Failed thumbnails are not retried when mtime changes
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2111560
Title:
Failed thumbnails are not retried when mtime changes
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/2111560/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
