View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0007624 | MMW v4 | Player | public | 2011-04-04 18:53 | 2011-05-14 02:23 |
| Reporter | rusty | Assigned To | |||
| Priority | immediate | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 4.0 | ||||
| Target Version | 4.0 | Fixed in Version | 4.0 | ||
| Summary | 0007624: Problems viewing / selecting / playing video files with image tags (wmv/mp4) on a network | ||||
| Description | Video files (esp > 1GB) in MP4 or WMV format are causing several problems in MM on a network environment (the issue was fixed for other formats in bug 7540): 1) Selecting the Video node takes ~15 seconds before tracks display due processing of some of the tracks that is occuring, if the first video file is an MP4 or WMV file. 2) Selecting certain files (even in details view) causes focus to get locked on the tracks for ~15 seconds. e.g. in Details view, press down, down, down, etc. when focus rests on MP4 or WMV files, UI locks for 15s. Moreover, when this occurs, clicking another track causes UI artifacts (Title bar appears, player expands to the area below the Start Menu bar) to appear: http://www.screencast.com/users/rustymonkey/folders/Jing/media/e6343e16-4c48-43ad-bc60-feb7d71053a7 This is most easily reproducible by selecting a large MP4/WMV file and then immediately clicking another file while 'processing' of the file's image tag is occurring. 3) When files such as those described above (large MP4) they often play with the UI 'stuck' in the corrupted state described above. Attempts to halt playback or to play other files when MM is in this state often fail as well. Note: Part of the problem here is that when MM attempts to play a particular file and gets stuck, the UI doesn't show that MM is still attempting to play that file so that user has no idea what is going on. I wonder whether a failing attempt to play a file should display that file with an hourglass in the Video Player window. --- In all 3 cases, this problem can be solved by disabling the Art&Details window, as the problem is caused by MM looking up the image tag. Possible solutions: 1) Have the display of the tracklist processed prior to display of the Art & Details Window to solve issue 1. 2) Have processing of the image tag calculated in a separate thread. This solves all three issues, but will result in the Art & Details window not displaying an image tag for ~20s -- not really ideal (bug 0004053). 3) Have MM cache image tags as thumbnails so that they can be displayed as quickly as other formats. For this to work, image tags would have to be kept perfectly in sync with image thumbnails during scanning and tagging operations. | ||||
| Tags | No tags attached. | ||||
| Attached Files | |||||
| Fixed in build | 1368 | ||||
|
|
Upon further examination (see attached log) it seems that these large files are processed for an extended period of time and if the user clicks another movie (or another portion of the UI such as the stop button) after attempting playback and while this 'processing' occurs, then the UI corruption occurs. |
|
|
I see it is a network file, could you test it with the same file placed on local disk? |
|
|
The problem doesn't occur for local files. Re-assigning to Jiri for evaluation with Ludek/Petr since it's not a video playback issue as originally thought. |
|
|
It seems that solution 3) makes most sense - cached album art would be shown whenever available. I think that we should switch from the current logic: a. On track change, load album art from its tags and show it. To a new logic: a. On track change, try to show album art from cache. b. Start a thread that will also try to load AA from the file and show it as soon as its available. Note that b. might seem to duplicate a., but it's there in order to show the real AA from file in cases when the cache is for whatever reason unsynced, or when user needs higher resolution Album Art window than resolution of images in cache is. |
|
|
Cover loading in thread implemented in 1362 |
|
|
Verified UI responsiveness in 1367 but I left it as resolved until we confirm that it does not made regression described in Ticket AYA-469317 |
|
|
I was able to reproduce the issue in Ticket AYA-469317, somehow it only happens with the Glided skin. I wonder if it's because the art and details tabs are using the system default ones? I can't reproduce in non-skinned, however. These are steps to repro in Glided skin: 1. Bring up some tracks with hi-res album art 2. Begin playback of these tracks, "Now Playing" tab selected 3. Use the next/previous buttons in the player to go between some tracks. You should notice the smaller cache file loaded first, then the hi-res takes it's place. Every once in awhile, you'll see the blurry cache file reappear while the track plays. |
|
|
This issue is covered by 4053 |
|
|
Verified 1374 |
