some points that stand out in that log to me are lines like
141013157: 1976: Database: CThumbnailsDatabase::AddThumbnail: Finish (1891 ms)
141013157: 1976: General: CThumbnailCacheInfo::CreateThumbnail: Finish (3875 ms)
141013157: 1976: Database: Thumbnail Thread (D:\BDMV\index.bdmv): Finish (3875 ms)
2383906: 1304: Database: CThumbnailsDatabase::AddThumbnail: Finish (1922 ms)
2383906: 1304: General: CThumbnailCacheInfo::CreateThumbnail: Finish (3016 ms)
2383906: 1304: Database: Thumbnail Thread (D:\BDMV\index.bdmv): Finish (3016 ms)
I don't know if these are blocking operations though. Are those times (at the end of the line) cumulative or represent individual operations?
Thumbnail generation while browsing is, unfortunately, a blocking operation, so it explains your hang in that particular instance.
The AddThumbnail line seems long, but I'm not sure off the top of my head how long that whole process should take. By the way, lines that have a total time in parenthesis are typically the result of an entire "process" and are cumulative. The three lines you posted from each log are each cumulative with each other (they're in the same thread), meaning that those second two lines (3016 ms in the second example) are referencing the same process from two different perspectives, and were received/recorded less than 1 ms apart, which is why it shows the same 3016 ms twice). That's good. It would be bad if there was a jump between those two numbers.
So, the AddThumbnail part might be worth checking (I can look at the whole log later, and compare to one of mine, I don't have time right now), but it is almost certainly okay.
Generally, however, the fact that it takes 3-seconds to complete generating the thumbnail on the D: drive is expected, if not necessarily good behavior.
When you browse in MC it has to generate thumbnails in order to show them in the view, if it doesn't already have a thumbnail in the cache. This is blocking because it is required for UI display (the main UI thread needs the thumbs before it can proceed). It is per-file, so it doesn't hang while it builds thumbs for an entire view, but it does hang while it actually generates a single file (converting
that item in the displayed list from a "placeholder image thumb" to the actual thumbnail). So, when you browse most views, it uses the cache first and these all display instantly, and then as you scroll it background generates thumbs and adds them to the cache for each individual item on screen, swapping them out one at a time.
That "UI replace" function is blocking. I also explain this process
fairly well here in "layman's terms". I think it is pretty well optimized. It does "feel like" to me that there is maybe an opportunity here to do the UI replace after the thumbnail generation is finished, so then it would just be a display of an already-background-generated thumb. But, honestly, Matt is good at this stuff, and probably has it optimized that way and as much as is possible. I'm not sure of the technical details, but I'd be willing to bet the blocking is
actually the OS blocking on disk access while the thumbnail is built, and that MC itself has "no choice" but to wait. Not sure.
The problem in your example instance, of course, is that the file is on an optical disc (and not an online disk part of the Library), so it can't really have the thumbnail pre-generated. As I said, I suspect the problem is OS-level and they can't do much here. I'm not sure. This isn't an issue if your Thumbnails are all basically pre-generated, and usually isn't a big issue (because the process is fast, and the actual generation happens in a background thread) with "online" disks. But in this case, you're spinning up and reading an optical disk (and BluRay structures are hard-and-slow to read anyway) so that is expected to be slow.
It would be nice if you could just prevent it from displaying Thumbs entirely for optical discs, since performance there is always going to be junky. It would probably be hard or impossible to distinguish between them though, especially when going through a driver like AnyDVD.
I don't think any of this is related to your other problems at all, though. You've just found a particular instance where MC does typically hang for a little bit. Your "regular" thumbs aren't an issue here when browsing non-optical disc related Views:
Processing
Thumbnails built: 100% (13450 of 13460)The crash that happens when you stopped video playback and switched to Music playback "smells like" one of these options:
* an Audio device driver problem
* Problems with the settings in Options > Audio
* video driver problems
* something broken in MC's video playback or audio playback engine, relating to switching between stream types.
Or some combination of the above. As I said, though, I didn't have time to really dig into your logs (please leave them all up for a while if possible).
Author
Topic: Library entries deleted for no known reason (+ unexplained hangs/crashes) in v20 (Read 3099 times)