thumbnail mode + FFD show = always using FFDshow even when just reading a thumbnail that was already generated in Dopus.
I use FFDshow for .flv and other video filetypes to generate a thumbnail but it seems that Dopus needs FFDshow to read just the thumbnail which I thought would be a static image.
Video thumbnails are generated using video codecs. Video files don't (generally) have an explicit thumbnail static image inside of them (that would be nice!) so to make a thumbnail of them you have to decode some of the video and grab one of the frames.
If FFDShow has set itself as the codec for some of those files then that's what Opus will use to decode them.
That part is fine leo but I see FFDshow when I enter a folder that already has the thumbnails generated. Shouldn't Dopus just grab the already generated thumbnail from the thumbnail folder?
It runs really slow if I enter a folder I was already in 2 hours before.
I think FFDShow will still be used to get things like the video dimensions (width x height) as they are not cached like the thumbnails are.
Getting those is usually very fast but maybe a "badly" encoded file could cause FFDShow (or another decoder) to spent a lot of time searching for them?
It sucks when you have a folder with small clips from a digital camera and it constantly hits 100% cpu, Dopus really needs to improve the thumbnail generating and read back process.
I've seen the same problem with digital camera movies and it's due to the way the movies are written and the way the video codecs process those things and, I suspect, nothing that Opus can do much about.
My camera writes .MOV files which, unlike most .MOV files, seem to make FFDShow and the MP4Splitter (or whatever else is involved in decoding them) take ages on each file, despite their small sizes. Yet other files work fine. Opus doesn't know anything about MOV files; it just asks DirectShow to get it the data and the rest is up tot he OS, the codecs and the splitters.
Since these problems only occur with certain files combined with certain codecs it's safe to say the problem is in the files & codecs and not Opus.
It would be nice if video thumbnails worked as well as picture thumbnails did, they never seem to hang or spike the CPU to 100%.
If only there was a way to manually stop the thumbnail generation for certain folders after they have already had thumbnails created.
It would be also nice if you could generate thumbnails when you're asleep and then have it off the next day and only read the thumbnails that it created the night before.
Picture thumbnails don't involve video codecs. That's why they don't hang or spike the CPU to 100%.
If you want to complain about that, send some sample files to whoever writes the codecs. They're the ones who can fix it.
Some stuff about changes to the thumbnail caching/generation code has been suggested to GPSoftware after some of your previous posts. I thought some of it made sense and wrote it up into a suggestion for you. Note that you are about the only person who ever mentions it though. 