When using file preview mode in konqueror within a folder with movies the system automatically generates snapshots with an app called "kffmpegthumbnailer" (10% into the movies). Say I'd like to create my own thumbnails for files that do not get a good representation automatically, where do I put these thumbnails?

Apparently Konqueror uses the folder "~/.thumbnails" as a cache storage. (if this is deleted, all thumbnail previews are regenerated). But when I try to supply my own thumbnail into this directory, it won't get used, instead a default one gets generated (even though the thumbnail type, size and name are identical).

How can I trick the cache functionality into using my own prepared samples instead of generating them. I would have thought there was a logical override, for example by supplying your own ".thumbnail" folder for files you'd like more control over, but this does not seem to be the case.

BTW, this is on a Fedora 12 system.

After browsing the KDE source code ("previewjob.cpp") it seems as if the handler is relying on meta-information embedded in the png thumbnail files. I see there are references to at least file name, size and modification time in there. That would certainly explain why the preview handler is overriding my own attempts to override the default behaviour.

Does anybody know exactly what information needs to be included in a thumbnail file so that the preview handler will load it without failing? Is there a good application for editing png meta information?

Ok, I think I'm getting a bit closer.

From the source code it seems as though the preview handler does the following checks to see if a cached thumbnail can be loaded:

- is there a .thumbnail folder
- is there a png-file in that folder with the correct name (an md5 hash of the path to the movie)
- does the png contain a chunk (metadata) containing the correct timestamp
- does the png contain a chunk with the full path to the movie

From experimenting with "ffmpegthumbnailer" I can create png's with these tags, but the entries do not appear exactly as when the KDE handler creates them. For example, KDE requires a full "file:///path/to/movie" string in the header. But when I try:

ffmpegthumbnailer -i file:///full/path/...

it complains about not being able to "stat" the file and thus leaves out the timestamp (which means that the KDE preview handler can't use it at all).

So ... I downloaded and modified the "ffmpegthumbnailer" source code. Two minor (hackish-ugly) changes were enough to create png files capable of fooling the KDE handler, so it was indeed down to the metainformation embedded in the png file.

This whole episode have left me pondering about two things:

- why include a feature like movie thumbnailing if there isn't a way to customize it?
- why have such a strong and obscure binary format dependency?

Both of these seem un-linux like to me. Wouldn't it be much easier just to rely on the thumbnail hashed name and official timestamp for verification. An small hook in the KDE code scanning for a local .thumbnail directory before the system cache would also be my preferred way of doing it. Maybe I'm missing something in the big picture.

Still hoping someone will chip in with a solution involving "vanilla" tools.