This is why thumbnails are not shown when I load a saved project, I presume. Or should I file a separate issue about that?

Yes and No. It would solve the issue on standard systems (respecting the fdo specs), but we would still need to also store them in the project files/directories (so we can move the thumbnails along with the project).

My understanding would rather be:
1) if there is no thumbnail, create it according to fdo (so nautilus and such benefit from it; and, inversely, you can get thumbnails for free from nautilus' thumbnailer/fdo-compliant apps)
2) if the project (.pptv) moves, thumbnails are unaffected since they come from the system anyway; the thumbnail is not stored with the project per se
3 if the .pptv is moved onto an altogether different computer, goto 1
4 if the media files moved, goto 1
5 if the thumbnails disappeared, goto 1

I think thumbnails are not important enough to be moved along with the project. They can be generated on demand on the working system, no?

That logic makes sense... except for one little thing ... You're not guaranteed that, if you move the project to another computer, that person has the plugins needed to decode/playback/support all the files.

If we move the thumbnails with the project then for the unsupported files we could:
* still show the sources used in the sources browser along with its metadata and thumbmail,
* still show in the timeline the sources using that file and instead of using the fully-decoded audio/video we could show a continuous video stream using that thumbnail (along with maybe a "missing file overlay").

This is something we want to have supported in the new design and is already supported in some pro editors as well as in AAF for example.

I'm not sure to understand the usefulness of showing thumbnails for a clip that the user can't playback because of lack of plugins or because the file is 404; I was thinking that, on the contrary, missing thumbnails might be a very obvious visual "indicator" to the user raise awareness of the problem? 

But I guess I see what you want to achieve. It might be more complicated for not much though, just a thought.

Regarding the freedesktop thumbnailing specification, it's dead and is implemented only by nautilus afaik. Besides, it's only for one-thumbnail-per-file cases. We can generate hundreds of thumbnails for the same file so i don't think it applies to pitivi.

Alessandro, argh.. that's bad :(

Aren't there any new specs for where to store thumbnails ? Or does every app do his own stuff ?

pvanhoof wrote something on his blog when he was working on the thumbnailer for hildon, but i don't think that a spec came out of that. 

http://live.gnome.org/ThumbnailerSpec seems to be about pvanhoof's work, seems to be edited often.

I finally have a fix for this is my "thumbnails-from-fdo" branch. It simply gets the thumbnails from the fdo thumbnails dir and does no thumbnail generation. From my understanding, it would make more sense for gst discoverer should be the one to do thumbnail generation (or totem's code to be upstreamed to gst).

Keep it open because of thumbnails generation. We should open a new bug about that in GStreamer for the discoverer to handle the thumbnail generation and make this one depend on the GStreamer one.

author Jean-François Fortin Tam <nekohayo@gmail.com>
 Fri, 30 Dec 2011 18:00:55 +0000 (13:00 -0500)

commit892319e0112add23881334cef2b196807ef78370

This task is open for anyone willing to attempt finishing it, so adding the gnome-love keyword.

Pitivi can use the gnome-desktop API to generate thumbnails. This is what nautilus uses internally. Note that the API is synchronous, we probably don't want to wait for the thumbnail before adding them to the media library. Nautilus has a worker thread and a queue, it updates the UI when the thumbnail is ready.

About the unsupported format, my personal opinion is that the discoverer should tell us if a file is not supported on the current system. UI whise I would put a specific icon to represent that. We could then consider a UI similar to what Totem is doing for missing plugins.

Currently, the gnome-desktop API uses the thumbnailers specified by desktop files in /usr/share/thumbnailers/. It contains on my side the Totem and Evince thumbnailer. I feel like we could provide a thumbnailer in GStreamer (which would deprecate the totem one). This way PiTiVi would not depend on Totem for that. But that is just an idea.

Obviously, for timeline thumbnails, we have no choice but to implement our own. This makes using gnome-desktop API a little redundant. If we where to have a gstreamer thumbnailer, we could depend on that to generate both the file thumbnail, and the one for the timeline. Those thumbnails seems very specific to PiTiVi, but not specific to a project, so I'd store them in .cache/pitivi/thumbnails imho. Generating them out of process is probably a good idea.

Got a bit sick of waiting for this to happen in gst discoverer bug #667203, so I did it in Pitivi for now. If 667203 finally happens, we'll need to open a new Pitivi bug.


commit 75c01e5f0d353092ab31488ca0d1d6c629ff2041
Author: Alexandru Băluț <alexandru.balut@gmail.com>
Date:   Fri Jan 3 17:45:17 2014 +0100

    medialibrary: Generate thumbnails in the background

commit bf95c041c774eacc877b94fb2e6a3d18c2436868
Author: Jean-François Fortin Tam <nekohayo@gmail.com>
Date:   Mon Dec 16 20:53:24 2013 -0500

    medialibrary: Automatically generate missing thumbnails
    
    Completes the solution for bug #432661