View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006474 | MMW v4 | Burning / Disc Handling | public | 2010-09-13 14:59 | 2010-11-14 17:06 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| OS Version | Windows 7 | ||||
| Product Version | 4.0 | ||||
| Target Version | 4.0 | Fixed in Version | 4.0 | ||
| Summary | 0006474: Regression: CD Insertion fails to import CD metadata | ||||
| Description | In build 1311, when a new CD is inserted, no metadata appears. When the user right clicks on the disk > Get Album info from freedb --> the Album information appears --> 3 seconds later it again disappears and is replaced with generic information (Track 01, Track 02, etc...) | ||||
| Tags | No tags attached. | ||||
| Attached Files | |||||
| Fixed in build | 1314 | ||||
|
|
Rusty, I cannot reproduce the issue. Is the tested CD part of library or not? The only case that is somehow similar is that if the CD is part of library and I right click the disc node or the disc node under My Computer and select > 'Get Album info from freedb' then it doesn't take effect at all. It takes effect a) if the CD isn't in library b) if the CD is part of library and I do the same action for Music->Location-> disc node Is this the case? Are you sure the regression you have found is only reproducible with build 1311 and not with 3.2.2.1299 ?? Because the only change in freedb handling seems to be issue 0006422 that was merged to 3.2.2 |
|
|
This happens for CDs that are _not_ part of the library. Here's a full description corresponding to the attached log: 0 Inserted CD and selected specific version of Pulp Fiction album --> Album metadata loaded into the tracklist --> a few seconds later it refreshed and the metadata disappeared 496 Clicked J: drive 573 J drive loaded with title 01, 02, etc. Over the next few minutes, the node refreshed every 0000025:0000030 seconds, showing no metadata each time. I tested with MM3.2 and it works correctly, so I suspect that this may be related to the manner in which MM4 saves its settings and how it interacts with cdplayer.ini on Windows 7 systems (note: both MM3 and MM4 were tested on the same Windows 7 system). |
|
|
I have just tested this in Win 7 and I still cannot reproduce the issue. It looks like issue 0006232, but that one was also fixed in 3.2.2 The metadata should be (unless you are running as admin) in C:\Windows\CDPlayer.ini, do you have the metadata there? If you are not running as admin then CDPlayer.ini should be located in the MediaMonkey app data folder. |
|
|
I've just verified that MM3 successfully saves and reads CD metadata to: C:\Users\Rusty\AppData\Local\VirtualStore\Windows\CDPlayer.ini I've also verified that MM4 does not save CD Metadata to that location, and that it doesn't attempt to read metadata from that location. Could the problem be related to the fact that MM4 stores config info to C:\Users\Rusty\AppData\Roaming\MediaMonkey... whereas MM3 stores it to C:\Users\Rusty\AppData\Local ? Would it make sense to update the debug build to log where it is trying to read/save CDPlayer.ini ? |
|
|
Rusty, on the FTP is MediaMonkey1.exe with a possible fix and added debug lines. Copy it to your 1312 directory and run the EXE. If it still fails then generate Debug log for me. Thanks! |
|
|
I tested with the custom build with 2 CDs (2nd CD test starts at ~ line 900 in the log). In both cases, the CD initially looked up correctly (as with the previous build) and after a few seconds, the CD Name changed to foreign(Chinese?)-looking characters. When I clicked the CD, all the metadata was replaced by Track01, Track02, etc. So the only difference from the previous build is that some funny foreign-looking characters replaced the origial CD name. Debug uploaded. |
|
|
Are you running as admin, I guess you are not? And MM badly recognized it and consideres you to have admin privileges and therefore it is trying to take C:\Windows\CDPlayer.ini but you are restricted to access the file? I have uploaded MediaMonkey2.exe, try the EXE, it should fix the issue. |
|
|
My machine is a Win7 machine (installed clean). I'm logged in on an account with admin rights, but MM isn't triggering an elevation dialog to allow a write to the C:/Windows directory. Strangely enough, MM3.1 does work, so I'm not sure what's going on. When I tested with mediamonkey2.exe, the worst aspects of the problem seem to be solved. i.e. when inserting a CD, the metadata now displays, however, the metadata doesn't seem to be saved to CDPlayer.ini -- if I re-insert the CD, it is looked up again. Where is this build saving the data to? Note: with MM 3.2 builds, the CDPlayer.ini file in C:\Users\Rusty\AppData\Local\VirtualStore\Windows is consistently updated. |
|
|
Strange, but I suspect it was just a test error. Test the MediaMonkey3.exe , it always reads/writes data to CDPlayer.ini located in the Local AppData directory (same as MM 3.2) |
|
|
I retested mediamonkey2.exe and found that MM was in fact saving the data, just not to the location that I expected; it was saving it to: C:\Users\Rusty\AppData\Roaming\MediaMonkey\CDPlayer.ini That's probably the correct location for the file, since that's the location for all other configuration data that isn't stored to the registry, so I would leave it as is (i.e. don't use the hardcoded path in mediamonkey3.exe), though you may want to confirm with Jiri. |
|
|
Ok, I left C:\Users\Rusty\AppData\Roaming\MediaMonkey\CDPlayer.ini as the location for MM4 CDPlayer.ini in order to be consistent with 0005040. C:\Windows\CDPlayer.ini is used only on Win XP and lower Win versions now. Fixed in build 1313. |
|
|
Tested in 1313 and the bug is not resolved--behavior is exactly as in prior builds. |
|
|
Strange, could you generate debug log? |
|
|
New debug log posted. Consists only of: 1) insert CD 2) wait until metadata is looked up and then erased 3) click cd node 4) close MediaMonkey |
|
|
Fixed in build 1314. |
|
|
Verified 1324 |
