View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0008221 | MMW v4 | Burning / Disc Handling | public | 2011-08-09 22:03 | 2011-08-17 02:48 |
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 | 0008221: CDs not playable as CD metadata disappears (regression) | ||||
Description | In build 1415, when a CD is inserted, MediaMonkey looks up the metadata via Freedb and creates a node for the CD, BUT: i) The CD node that is created upon insertion disappears after a few seconds ii) When navigation to the CD via the My Computer node, all CD metadata has disappeared See: http://screencast.com/t/NFCAOAuc | ||||
Tags | No tags attached. | ||||
Attached Files | |||||
Fixed in build | 1417 | ||||
|
I cannot reproduce the issue and the log do not show much. I noticed you are using the portable version, does this issue appear with the standard version too? I guess that previous builds work for you, could you test build 1414, 1413, ... to see when this regression was introduced. |
|
Confirmed--the problem was introduced in 1415. |
|
Fixed in build 1417 (reverted changes from 0008159) |
|
Confirmed that reverting 0008159 fixes this issue. Note: In testing this, though, I noticed that each time the user leaves the CD node, the contents of the CD are 'lost'. i.e. even though MM persists the name of the CD in the tree, upon clicking the CD node, the contents of the tree are empty and must be looked up again. MM4 has behaved this way for quite some time, but it makes me wonder whether that issue is somehow related to the fact that bug 0008221 is triggered by 0008159 (i.e. if that issue was solved, then perhaps 0008221 wouldn't occur in response to 0008159). |
|
Yes, if you click CD node again (or refresh by using F5) then the CD content (TOC and CD text) is read again until the CD is in the library. It has always worked this way and I doesn't see a reason to change this. There doesn't seem to be any advantage or need to apply 0008159 so reverting this was reasonable. |
|
Verified 1419 (No regression regarding 0008071) |