View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002609 | MMW v4 | Properties/Auto-Tools | public | 2006-08-24 00:19 | 2009-06-06 14:30 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | major | Reproducibility | sometimes |
| Status | resolved | Resolution | fixed | ||
| Fixed in Version | 3.1 | ||||
| Summary | 0002609: Tags Sometimes Fail to Update ( tag queue) | ||||
| Description | A couple of tag-related problems have been reported at: http://www.mediamonkey.com/forum/viewtopic.php?t=10911 http://www.mediamonkey.com/forum/viewtopic.php?t=11587 http://www.mediamonkey.com/forum/viewtopic.php?t=11716 The common factor seems to be that tagging occasionally fails when multiple tagging operations occur concurrently. I tested this out numerous times and was only able to trigger the error once, in a manner that might be different from that reported above: 1) Select the contents of an Album in the Locations node 2) Analyze volume for all tracks in the album 3) Auto-tag from Amazon while volume leveling is in progress -->One of the tracks in the album did not update with the year! I verified in the Album node as well--the Year did not get saved to one of the tracks. I'm not sure if this is the same bug or not because in my case, not even the Database was updated, whereas for most of the reports above, it seems that the DB was updated but the tag wasn't. | ||||
| Additional Information | http://www.mediamonkey.com/forum/viewtopic.php?t=22629 | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1200 | ||||
|
|
A simple way to reproduce: 1) Go to a tree node. 2) Select all tracks there and Analyze volume. 3) Go to another node and return to the node from step 1). 4) Change rating of some songs in the node. 5) When leveling is calculated, these songs lose their rating change. A fix for this is quite problematic, because we will have to make a 'pool' of all TSongListData structures in memory, and when a track info will be about to be read from DB, it will be first checked for existence in the 'pool'. The pool could be a hash table indexed by track ID or track Path, it has to be thread safe, etc. Although it's a little limiting, pool based on track ID seems to be better, it could be searched only from one place (when reading tracks from DB) and so the whole implementation could be much cleaner a safer. |
|
|
Similar repro steps to the above: http://www.mediamonkey.com/forum/viewtopic.php?p=107217#107217 |
|
|
Setting to 'urgent'. Since auto-analyze processes tracks in small batches, the likelihood of this occurring is minimal. |
|
|
The pool/queue should also account for the file monitor. i.e. if the file monitor detects a change in between tagging operations, the operation to update the DB should be placed at the appropriate spot in the queue to prevent a tagging operation from losing edits made externally to MM. http://www.mediamonkey.com/forum/viewtopic.php?f=6&t=40171 |
|
|
The original issue described here was fixed quite some time ago during 3.1 development. As for the last note, I don't think we can do much about it, as I described in the forum post. |
