I just upgraded from .492 to .510, so will let you know how that goes.
The most solid fact is, the lockup happened all the time in .497 and .504, but seemingly never in .492.
Step-by-step, more or less:
Use a fairly large library -- the one I'm working with has 60 thousand tracks.
MC is set to store tags in files (MP3 with a few FLAC).
Open a view with at least a dozen or more tracks -- I've had the problem with a single CD rip of 15 tracks, but also in Recently Ripped with 8 CDs ripped (100 tracks) and also a view with hundreds or thousands of tracks.
Decide to check the tracks and update some tags...
Play a bit of a track (as a reminder of what it is).
Then edit that track's tags, using either the Tag dialog OR in-place editing.
Change various tags, including several that control views, such as Keywords, Genre, and sometimes Name and Artist (I don't use or even look at Album Artist) and various custom tags.
Usually (but not always) the track is still playing while I'm changing its tags. The changes appear instantly in the database.
At the bottom, MC often displays the normal message that it will finish the update when the playing track is stopped, and 90% -95% of the time, it does.
Go to the next track in the view, and repeat the process -- play a bit, change some tags, move to the next track.
Eventually - after 5 to 25 tracks, MC locks up. It's sudden, no warning, nothing odd, it just freezes. The cursor/pointer disappears. Nothing responds. No MC dialogs or messages, except at the bottom of the screen is the same "waiting to update" message, but this time it just gets stuck. The player can't be clicked so the track can't be closed. If I let the playing track finish, it goes into a 1 second loop. The only recovery is to use Task Manager to kill MC.
Restarting MC, the recent tag changes are NOT there. At least the past two or three track tag changes are lost, and OFTEN, the last database change is 5 or 10 tracks behind the track that was being edited when it froze. So, if MC was waiting for a track to finish, it did so quite a while before -- since I'd played 5 or 10 other tracks since then.
It doesn't seem to be a media file problem. Once MC is restarted, I can retag the same tracks without a problem.
Wild speculation...
Maybe whatever "stop" signal MC gets, to wait until a playing track ends, is sometimes wrong, and the tag saver and player get into a deadly embrace over the file.
Maybe MC is waiting for the wrong file to be released/closed.
Or maybe something about tag updating is so slow (rebuilding a view index?) that the update process times-out or goes into outer space.
Maybe the player doesn't always or promptly fully release/close a music file (caching?).
Maybe custom fields/tags are misbehaving -- I use several.
Since it's random but only happens after at least a handful of tracks are played+tagged, maybe it's a queue or stack or cache or array problem, where MC gets confused about which open file it is waiting for vs. updating.
Something changed after .492...
Author
Topic: More on tagging-while-playing lockup (Read 5658 times)