Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[MusicHawk]

Here's an odd problem, but it has been happening to me regularly for several weeks across several versions (from the mid .490s to .520).

I've ripped some tracks, which MC puts in my temp CD rip folder while I listen, tag, get them ready to move to their permanent location.

Often enough to be annoying -- every couple of CDs I'm ripping -- something happens and one database record gets disconnected from the physical file. MC suddenly pops up a dialog that the track is in use or not found or something.

But the track is actually still right where it was. In fact, it's right where the database record's filename path shows it. But MC suddenly says "file not found" in the status bar.

This ONLY happens to a file I was tagging (or changing tag text).

MC is set to update the file with all tag changes. I'm 99% sure it's a timing issue with this process -- something about how quickly I click on/off the database record vs. MC's effort to write something to the file. ZAP -- the file gets disconnected from the database record.

It's odd the only database problem is to the filename; I don't see loss or corruption of tags in the database, just a disconnect of the db-to-file connection.

As a test, I switched my temp CD rip folder from one drive to another. No help.

I found a way to reconnect the file, which I hope is a clue to the cause of the problem: I have a file manager (xplorer2) that lets me copy the exact path of the file, exact case, no chance of a typo. I locate the file in the temp rips folder, copy its path, then paste it into MC's filename field, and TA-DA, the database usually gets reconnected with the file. But it's a pain to do.

Workaround #2: If that doesn't work, I locate the file in the temp rips folder. Drag the file back into the database, then delete the old database record and tag the new one. This is an even-bigger pain.

With several prior versions I was having trouble with MC locking/crashing during tagging. Good new, that hasn't happened with .520, but this problem still exists. They seem related, somehow.

I'm trying to avoid the problem by being S-L-O-W to click on on/off tracks I'm tagging. But that, coupled with the "new" convoluted behavior of Keyword and multi-artist fields, is making for an even slower process.

I hope this info is helpful.

[ADDiCT]

I've made a new post in the "Media Center 12.0.520" thread describing a very similar effect. I think this is a bug, and a rather serious one, too.

[MusicHawk]

The problem keeps happening, and I've discovered odd MC 12.0.520 behavior that, if accurate, is scary:

I wanted to update some tags in a song that has long-existed in my library, and I had recently played without problem.

Tags I changed: Artist, Artists (custom field), Genre, Keywords. Also, I removed cover art that was incorrect.

Suddenly, while saving these changes, MC reported that the file was missing! (MC is set to store tags in files.)

I noticed the database record's filename had been CHANGED to a new path. HOWEVER, I did NOT invoke Rename/Move, and the file was NOT actually renamed/moved. Somehow, MC decided to change the database record's file path, but without actually changing the file, it immediately got "lost"!

There's logic to the new path. It reflects where the file might have been moved IF I had invoked Rename/Move HALFWAY through tagging, because my file path is an expression that uses some of the tags I changed. But the "new" path is only partially correct. It includes the new value of one of the tags I changed, but only part of the value of another tag I changed. I believe this indicates that after I started to change these fields, the file path got mysteriously updated mid-change, so my subsequent changes triggered the "can't find file" error. At no point during tagging did I click Rename/Move. In fact, I never invoked it for this track because the error popped up first.

Of course, once a file gets disconnected from the database record, nothing more can be done because tags can't be saved to the file and file properties can't be restored to the tag. They no longer are connected. I repaired the record by locating the physical file -- still at the original location -- then copying the real location back into the database record. But why did the database's file/path get changed yet the file itself wasn't?

Key question: Did I inadvertenly click Rename/Move? I don't think so. Two proofs: I was working only in the Tags action window, and didn't touch any MC library actions except for clicking Remove Cover Art -- one click, and it got removed. IF I had somehow also clicked Rename/Move, why didn't the new file location reflect my expression for naming it? Instead, the changed path reflected only partial tag changes, as if Rename/Move was clicked mid-way through changing the tag values, which it wasn't (unless there's a mysterious hot-key I don't know about). And, since this problem has happened MANY times recently (about 1 out of 30 tracks tagged while ripping about 100 CDs), and almost none of them had any "wrong" cover art to remove, I didn't go anywhere near Library actions until well after all tagging was completed. (My normal practice is to rip to a temp location, then tag/fix everything, then after careful review, click Rename/Move as the final step.)

More oddity: Every time MC told me this file could not be found, it also started listing other "lost" files -- one dialog after another, as I click "No". The files were those that became "not found" yesterday when I ripped 300 tracks and had this problem about 10 times. But I fixed those, so why was MC still complaining, and why do it while reporting a problem with a particular track, the only track I'm tagging? I'm NOT clicking on any of these "lost" files. But when I click on ANOTHER "lost" file, I get the error message about one of yesterday's "lost" tracks. What's with that??

By the way, "normal" behavior when I click a track that is disconnected from the database is that MC plays another random track instead. This is odd, and makes me think the track is misnamed until I realize what's happening. It takes some time to determine what is actually playing vs. the clicked track.

One thing to note: In my Rename/Move expression, one data item is a multi-value field. MC converts the semi-colons to underscores, but otherwise seems happy to use this field. But could the nature of this field trigger the problem? Just in case, I changed the Rename expression to use a single-value field.

Can I get this mysterious behavior to repeat via experiments? Not so far. I change tags and add/remove cover art, and watch the file path and it doesn't update unless I click Rename/Move. But it definitely did change, many times, so I can only report this as a mystery....

[hit_ny]

Are you aware of how to find missing files ?

Should take about 5-10mins for a 80k files sized library. It checks that every database record matches the corresponding one in the filesystem.

That smartlist will turn up unlinked files in the whole database, i always run it at regular intervals to make sure everything is where MC thinks it is.

Ideally, it should return nothing

[MusicHawk]

how to find missing files

I wasn't, thanks!

I built a smartlist and it found lots of "missing" files, but only five related to the current problem. I had discovered the five yesterday, and replaced them by dragging the files back in, creating new database records, so what the smartlist found was the damaged records I'd left behind. So it was helpful to find and delete these.

The many others were from a problem a few weeks ago, when on connecting an iPod for sync, MC suddenly decided to import its files. I stopped the process, and deleted the temp folder/files, but didn't notice and delete the corresponding database records, until now.

So, I haven't been overlooking files that get disconnected due the current problem, because each time, the "can't find" error is an instant show-stopper.

[Matt]

Thanks for the detailed report.  I think I see the issue.

Filenames can be stored as references to other fields for efficiency.  It looks like the mechanism to fork references on a tag change could fail in a rare case when there had just been a lot of other database activity.

Look for a fix soon.