Corrupted Artist Fields in Database (IDSong != song.ID)

[srlake]

Please see this thread for full problem description and screenshot:

http://www.mediamonkey.com/forum/viewto ... =1&t=45290

Environment is:
Windows 7 Business x64
AMD Phenom II X4 945 "Black" CPU
8GB RAM
Music Stored on 2TB NAS Device over Gigabit LAN
60,000 tracks in library
MM 3.2.0.1294

Have rebuilt library, take ~24 hours each time, same issues.

Ideas?

[srlake]

Same problem here:

http://www.mediamonkey.com/forum/viewto ... =7&t=44781

Appears to be a Win7 x64 bug. The above link has been around since November.

[srlake]

Bump:

MM Team: Any ideas? This seems like a fairly major issue here.

[Peke]

Optimization issue as MM tries to load all tracks (in most cases it needs fully copied file from NAS to PC RAM) to get all tag info. Imagine that on 60k tracks.

We are working on way to Improve that behavior.

[srlake]

I'm sorry but I don't see how this is an optimization issue?

This is not an issue with speed/optimization while building the database. It takes 24-36 hours to build the database on a clean system with 4x3.0Ghz and 8Gigs of RAM, so I'm assuming that it must be loading every track into "Memory".

The issue here is with core functionality. The database is completely corrupted. Most tracks are filed under incorrect artists, despite the fact that the artist name appears properly in MM. Due to this, I can't search by artist, sort by artist, use last.fm auto-DJ and many other features.

[Peke]

I here is what I left last night to work. I created new clean library and started to scan 10k+ of my tracks on Network PC. Do not know exactly how much time it took but I checked library and all is on its right place.

Now I tried to load one folder with WAV files (due wav file sizes, structure and that Tag Data is located on the end of file) and it took up to 5 sec per track which means that it scanned thru whole files (30-40MB each) to locate tag data, so you are also right like I found that whole file is transferred thru LAN. Not even looked at security issue where backup is created on Tag Updates (Tools -> Options -> Library -> Tags and playlists -> Update tags on edit properties) which doubles pressure on LAN bandwidth and low (in rare cases mid) range of single chip LAN Solutions.

Note: that MM is multi threaded and tries to access multiple files over LAN you get the picture. That is why I told it is optimization issue not core.

If you have any ideas/thoughts I'm all ears and that is something that we are look into seriously.

[srlake]

Hi,

Thanks for looking into that, however my problem still exists...

Did you try to reproduce this on Windows 7 x64? It seems that the issue has been happening only on this OS. It is possible that there is another requisite conditions to reproduce this as well (other software, certain MS update, etc, etc).

[srlake]

Any ideas?

MM Team? This seams like a major issue. I have found posts from at least three other people with the same issue.

[srlake]

Is the entire software development team on extended holidays? No replies here, and a support ticket was raised on the 6th, without response.

[Peke]

Sorry for not replying, and yes I use/test this on Win 7 x64.

[2uantuM]

Having this issue still too. I completely rebuilt my database and the problem went away for a while until I decided to add some new tracks. I got an error right after adding the songs that the files could not be found and it wanted me to relocate them. I hit cancel and all the songs were there with no visible problems. I then clicked under the band name on the left and I saw the same problem as the OP. This has been a problem for months. I really don't want to have to switch to songbird.

[2uantuM]

And for the record, I'm not using any plugins except the last.fm plugin.