View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0008032 | MMW v4 | DB/FileMonitor | public | 2011-06-27 21:02 | 2011-07-08 22:01 |
| Reporter | rusty | Assigned To | |||
| Priority | high | Severity | feature | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 4.0 | ||||
| Target Version | 4.0 | Fixed in Version | 4.0 | ||
| Summary | 0008032: Performance: Loading of audio images should be as fast as Video thumbnails | ||||
| Description | In MM 4.0, image caching has been implemented for Videos, but not for audio files. The net effect is that for tracks stored to the network, it's faster to click through videos than for audio files since video images are cached, but audio images aren't (e.g. it takes .5 - 1s for artwork to appear for each audio file, but for video files, the artwork appears instantly). Image caching should be implemented for audio files as well. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1398 | ||||
| related to | 0008039 | closed | petr | Performance: Image loading in Art&Details window is slower than MM3 |
| related to | 0008054 | assigned | petr | Performance: improve speed of first-time loading of audio artwork |
| related to | 0008216 | closed | petr | Thumbnails are associated to tracks that have no Art |
| child of | 0008224 | new | petr | Performance: Music Artwork isn't cached |
|
|
After offline discussion it was implemented in 1398 |
|
|
This works really well once the images have been cached. However, the caching implementation makes MM almost impossible to use in AA view for the first time. i.e. Switch to AA view and scroll downwards -->Images slowly load for each file Scroll downwards further -->It is impossible to scroll down! The tracklist doesn't respond properly to the wheelmouse/scrollbar as the UI is locked until the images for the Albums currently in view have been loaded. What should happen is that: a) The images should be loaded in the background (even prior to them coming into view) in the same manner as Video Thumbnails are loaded independently of what the user is scrolling in the UI. b) The images should be loaded in a separate thread so that it doesn't interfere with UI activities. |
|
|
re a) this was implemented in early MM3 version but removed because of CPU usage even when user doesn't do anything (will enable it back for a next build) re b) covers are loaded in thread, but resizing to thumb size must be done in main thread (that's the reason why UL looks frozen) ... will try to do something with that |
|
|
a) shouldn't be an issue if the status bar indicates that thumbnails are being generated (as is the case for videos). That way users understand _why_ CPU utilization is higher temporarily. |
|
|
Note: performance issues were likely due to the temp file being stored to a USB key. |
|
|
Re-tagging as resolved. The only items to improve further are optimizations to improve first-time viewing of audio thumbnails (e.g. to load them in the background as with Videos, instead of upon first viewing them). |
|
|
a) Verified 1403 b) is now handled in 0008054 |
