Print

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

[MusicHawk]

Sorry to report the "silent" rename bug is still doing its mysterious thing.

Ripped a CD.
Listened to a track.
Renamed the Artist in the database
ZAP -- MC instantly lost the file.

I changed the Artist from "Walt Disney" to "Disneyland ride".

Suddently MC's mysterious half-way renaming unwanted action kicked in...

The Filename field now has this:
M:\Temp\CDrips\Disneyland ride - The Music of Disney - A Legacy in Song - Three\Disneyland ride - The Music of Disney - A Legacy in Song - Three - 27 - It's a Small World.mp3

The file's real name/location is this:
M:\Temp\CDrips\Walt Disney - The Music of Disney - A Legacy in Song - Three\Walt Disney - The Music of Disney - A Legacy in Song - Three - 27 - It's a Small World.mp3

Notice the Artist portion of both the FOLDER and FILE names were changed. But not by me!

The bug is that MC took my editing of the Artist field as an instruction to immediately change the Filename field, which should NOT happen unless I either edit the Filename field, or invoke Rename/Move. Worse, MC only changed the Filename FIELD, not the actual filename -- so the file gets disconnected from the database. See all the prior postings by me and others for .528 and earlier versions for details.

My folder and file expressions are listed in my .528 report on this bug.

[MusicHawk]

I believe it's a "show stopper" to have MC (still) silently and incorrectly change the Filename field, instantly disconnecting the database record from the physical file -- triggered just by editing the Name field. (It happened to me yesterday, twice, when ripping then tagging three CDs.)

It's a double-show-stopper because not only is the database's Filename changed to a value that does not match the physical file, it is likely well beyond the average user's ability to repair because (a) it requires knowing exactly what the Filename field WAS and (b) it seems resistent to manual editing.

And it's scary because there's no message or warning, UNLESS the user manually tries to then play or retag the file (AND store tags in files is set). If the user is already "done" with the file, it's forever lost to MC because playing it in a list will just skip over it.

Only an exact copy+paste of the physical full path seems to fix the database, and that is literally impossible unless the user (a) knows that to do, (b) can find the file, and (c) knows how to copy the full path+filename as pastable-text -- Windows Explorer requires a non-obvious technique (below).

Even though the trigger for this data-damaging behavior is apparently mysterious (because it only happens some of the time), it seems to have appeared just 10 or so point-releases ago, which should help narrow-down the suspect code.

Seems like a bug worth fixing...once and for all (users and future versions).


The non-obvious technique in Windows Explorer to copy a file's complete path+name (rather than normal Copy of the file's content):
1. Locate the file in Explorer
2. right-click, select Properties
3. highlight the path+filename that is displayed in Properties, including scrolling it to get it all -- there's no clue that this is selectable/scrollable text
4. Copy or Ctrl+C
5. Go to that damaged record in MC, go into the Filename field, then Paste or Ctrl+V

Usually that repairs the database-file disconnect. Until it gets broken again...

[JimH]

I believe it's a "show stopper" to have MC (still) silently and incorrectly change the Filename field, instantly disconnecting the database record from the physical file -- triggered just by editing the Name field. (It happened to me yesterday, twice, when ripping then tagging three CDs.)

I'm on your side, really.  But I'm also not certain this problem is ours.  I've watched your very patient and detailed reports closely, and Matt and I have talked several times.

Logs are the most useful.

[MusicHawk]

Well...

Dunno how it could be on my side. I'm a software developer with plenty of user-error battle scars, which is why I've been giving detailed reports of my MC config, and details of runtime behavior to contemplate in conjuction with the code's logic flow.

In yesterday's example, I edited the Name field and MC immediately changed the NAME portion of the Filename field. I provided the specific Filename text vs. physical file path to show what happened. I understand it's not clear how MC could do this, but I see no way *I* could do it.

The only thing I control is the naming expressions, which are these:

RIPPING
Folder: [Artist] - [Album]
File: [Artist] - [Album] - [track#] - [Name]

RENAME/MOVE
Folder: if( isequal([Rank],3,5),music,musicminor)\FixCase([Genre]\Mid([Artists],0,1),4)
File: FixCase(Mid([Artists],0,20) - [Name],4)

It's clear my Rename/Move expressions aren't being applied; that would result in a very different Filename/file name outcome.

HUNCH: Based on what get changed "silently" by MC -- just the Name portion of the Filename field -- it seems like the RIPPING File name expression gets REAPPLIED (sometimes) when the Name field is manually changed, because that's the only part of the Filename field text that gets changed.

CLUE 1: This happens in the Recently Ripped view. Can you see where in the code this might happen, given these specific conditions? Does MC perhaps think it's a change to a to-be-ripped track so it only changes the Filename FIELD rather than to the physical file? (Assuming that when track data is changed in the Get-Ready-To-Rip view the changes are applied to the database records but the physical still-on-CD track name isn't touched.)

CLUE 2: Sometimes (but not always) the affected track is playing or was just played (therefore still has an open handle). Since this possibly sets a "update database later" flag, maybe that sometimes branches to the wrong update code for the Filename field?

EXPERIMENT IDEA: Could a track's RIPPING File name be too long at times? I always rename files after tagging using Rename/Move, so I don't really care what the RIPPING File name expression is. The file is already isolated inside [Artist] - [Album] folder, and for me the folder and file name are just temporary until I finish tagging then Rename. So perhaps things would be more stable with a shorter File name expression, perhaps just [track#] - [Name]. I wonder about boundary behavior if MC literally uses Artist and Album and Name in a very long combination.  (Notice that My Rename expression uses just the first 20 characters of the Artist name, which can get really long, to create a "safer" File name length.)

I'll send another log when another file "disappears".

[Matt]

Well...

Dunno how it could be on my side. I'm a software developer with plenty of user-error battle scars, which is why I've been giving detailed reports of my MC config, and details of runtime behavior to contemplate in conjuction with the code's logic flow.

In yesterday's example, I edited the Name field and MC immediately changed the NAME portion of the Filename field. I provided the specific Filename text vs. physical file path to show what happened. I understand it's not clear how MC could do this, but I see no way *I* could do it.

The only thing I control is the naming expressions, which are these:

RIPPING
Folder: [Artist] - [Album]
File: [Artist] - [Album] - [track#] - [Name]

RENAME/MOVE
Folder: if( isequal([Rank],3,5),music,musicminor)\FixCase([Genre]\Mid([Artists],0,1),4)
File: FixCase(Mid([Artists],0,20) - [Name],4)

It's clear my Rename/Move expressions aren't being applied; that would result in a very different Filename/file name outcome.

HUNCH: Based on what get changed "silently" by MC -- just the Name portion of the Filename field -- it seems like the RIPPING File name expression gets REAPPLIED (sometimes) when the Name field is manually changed, because that's the only part of the Filename field text that gets changed.

CLUE 1: This happens in the Recently Ripped view. Can you see where in the code this might happen, given these specific conditions? Does MC perhaps think it's a change to a to-be-ripped track so it only changes the Filename FIELD rather than to the physical file? (Assuming that when track data is changed in the Get-Ready-To-Rip view the changes are applied to the database records but the physical still-on-CD track name isn't touched.)

CLUE 2: Sometimes (but not always) the affected track is playing or was just played (therefore still has an open handle). Since this possibly sets a "update database later" flag, maybe that sometimes branches to the wrong update code for the Filename field?

EXPERIMENT IDEA: Could a track's RIPPING File name be too long at times? I always rename files after tagging using Rename/Move, so I don't really care what the RIPPING File name expression is. The file is already isolated inside [Artist] - [Album] folder, and for me the folder and file name are just temporary until I finish tagging then Rename. So perhaps things would be more stable with a shorter File name expression, perhaps just [track#] - [Name]. I wonder about boundary behavior if MC literally uses Artist and Album and Name in a very long combination.  (Notice that My Rename expression uses just the first 20 characters of the Artist name, which can get really long, to create a "safer" File name length.)

I'll send another log when another file "disappears".

Are you ripping and tagging and moving the same files all at once?

Could you post the simplest step-by-step that can reproduce it?  For example, take ripping out of the equation.

Thanks.

[galahad1974]

It happened to me last night also, but i can't reproduce it.

its the only time I've ever seen that particular behavior, but when I renamed (changed the name field) a file from "highwaymen - dvd - hi quality" to "highwaymen" the file link also changed to  "g:\media\video\movies\highwaymen.avi" which doesn't exist.

How far back do the logs mc keeps go?  If its over 24 hours, i may have what you need.

[JimH]

Logs are kept for the current session and the previous one.

[MusicHawk]

The bug doesn't bit every time -- I haven't found a way to reliably reproduce it. But it happens with these steps:

1. Rip a CD
2a. In Recently Ripped view, tag the tracks I know without listening.
 -OR-
2b. Sometimes, briefly play a track to remind what it is, then tag it. The track might be playing or I might have just jumped to the next track in the list.

Usually step 2, either mode, has no problems.

But if I find the need to edit the Name field (usually because YADB had a typo), the bug can bite.

The bug only bites if I manually edit the Name field, and then, only sometimes, But... it sometimes happens WHILE I'm editing it. For instance, there might be two typos in the Name. I edit the first one and the bug hits, which I don't discover until I edit the second type -- still in the Name field -- and MC reports it can't find the file.

I'd like to say this bug hits ONLY when I've just played the track whos name I then edit, but there are times I haven't played the track, or not in many minutes.

Other ways to edit the Name field work reliably. For instance, sometimes YADB has Name and Artist values reversed so I use Move/Copy fields to swap them. This "edits" the Name field but there's never a problem.

While "all at once" isn't possible, I suppose I jump among the steps quite quickly. I'm a very fast typist, in case it's possible to get ahead of MC or myself... The main quick moves would be jumping between tracks, and jumping between playing and editing.

I don't Rename/Move until later, after all tracks are tagged and the tags reviewed (because my Folder and File expressions rely on some tags).

ALSO: I think the bug hits ONLY when editing the Name field in the view. I don't recall it ever happening while using the Tag edit window.

CLUE: What triggers the bug might be a mystery, but I think what it does is apply the RIPPING File name expression using the revised Name field value. I think this because I know of nowhere else in my MC config that this File name pattern is used, and I know of no way to apply it other than by MC using it while ripping. How else to explain what I reported yesterday, when MC changed only the [Name] portion of a long text string in the File name field just after I edited the text in the Name field -- and didn't rename the file itself?

[MusicHawk]

Galahad1974's experience is exactly mine (see example posted yesterday). But, I've tried and tried to reproduce it on-demand and can't. I hope it's not tied to something really obscure, like every 18th track edited, or Name values with hypens in them (tried that), or the price of oil.

[galahad1974]

No Luck, I didnt turn logging back on after re-installing last month. Sorry.....

[JimH]

What OS?

Where are your files stored?

[MusicHawk]

My MC is on an HP a1640n, Intel Viiv Core 2 Due Processor, 2GB RAM, Windows XP SP3.

MC is on the original C: drive, 250gb SATA with about 130gb free.

All music files and cover art are on a second internal M: drive, 750gb SATA with about 330gb free.

Norton Internet Security is installed but mostly disabled (darn hard to actually remove). And in case it's tempted to interfere, it's been told to ignore .mp3 files and the entire M: drive, among other exclusions. But, the fact that this exists is why, many posts ago, I wondered if there could be a timing issue, where MC thought it was writing to the database and/or disk but there was some buffering or intermediary. But even if that was the case (which would likely be a factor on many systems), the current bug doesn't involve writing to the music file at all, it's just MC updating a field value inappropriately.

[Matt]

For efficiency, the filename field can be stored as references to other fields, like name.

When you edit a field, the system forks the filename to remove the space-saving reference. 

It sounds like this isn't happening in one particular flow.  We'll take a hard look at the code.  Thanks for all the details.

[eba]

I have also had this problem.  In my case it was changing the name of a just imported, just downloaded video.  I'd downloaded several videos, and it happened with every one.
That was a few builds back tho, before 524 when something in this line was meant to have been fixed.

[JimH]

Norton Internet Security is installed but mostly disabled (darn hard to actually remove). And in case it's tempted to interfere, it's been told to ignore .mp3 files and the entire M: drive, among other exclusions.

Try reading the Weird Problems thread to see if any of the virus checker problems sound familiar.

MC also writes the library files and the registry, so your exclusions aren't enough, and the exclusion thing does not always work as expected.

Virus checkers cause a lot of problems.  Not necessarily this one, but you have to eliminate it.  Uninstalling is the only certain way.

[Matt]

We found a flow that could cause this issue.  It wouldn't be common, so let us know if it sounds familiar:

1) You change the filename of a file or rip a new file
2) You change no other filenames for a minute or two
3) You edit the name field of that same file

Could this be the issue?  It would only ever apply to a single file, and it would be the last one with a filename changed or created before a database save.

[MusicHawk]

Yes, this could be it. Here's how my actions match your steps:

1) You change the filename of a file or rip a new file

Yes, but in my case via ripping a new CD, not by me changing any filename manually. So the file names of the rip are determined by the naming expression specified in MC.

Except... Maybe I have also experienced it with a manual edit when I attempt to recover from the bug. When it hits and I try to fix the track by manually editing the Filename, often I can't. When I finish typing, MC will revert the File name value back to the prior "wrong" value -- perhaps because there wasn't enough time elapsed. When I do my "reliable" fix -- go to the drive, find the file and copy+paste the path+filename into the Filename field -- that requires a minute or two which might be enough time for MC to have written the pending change so it accepts my edit.

2) You change no other filenames for a minute or two

Yes, because I do nothing to filenames except at the end when I run Rename/Move. Otherwise,the only Filename changes are done by MC when it assigns names during ripping, or when the bug kicks in. The only manual Filename field editing I ever do is to try and recover from what the bug does.

In case it matters. I rarely finish a CD rip (so maybe 10 to 20 tracks) then immeidately start working with it. Sometimes I won't touch the tracks for hours or even a day, either because I continue to rip CDs so I have large batch to work with (efficient for my tagging process) or because I can be ripping while doing other things nearby, but then need to sit down and focus on MC to do all the tagging.

3) You edit the name field of that same file

Yes, this is what triggers the bug. The above explanation of steps and timing applies to many tracks as they accumulate in Recently Ripped, waiting for me to tag them, and there are three main reasons to then edit a Name field:

Often only one track needs its Name edited, usually to correct a typo.

OR, several or even all tracks on a ripped CD will need the Name edited because I don't like what YADB gave me, and I can do so without trouble. Typically I would do this quickly, blasting down the list, editing fast and moving to the next track -- and no bug.

OR, I edit most or all the track Name fields, but only ONE triggers the bug -- but I've long sensed that there's a timing element to the bug, that it only happens after a "pause" in my work (which is why I commented on my typing speed). It's almost like the bug happens after I think all the tracks are OK, so I've definitely paused for a minute or two or several, then I spot one bad Name, and edit it -- and I recall a dread that "I hope this doesn't trigger the bug" and sometimes, it does!

So yes, the pattern you describe does match my experience.

And while the bug can happen again in a ripping/tagging session, it's usually not for several minutes or after working through several more tracks or after ripping another CD.

[Alex B]

I can reproduce the problem. It happened with two of four CDs I ripped as a test.

1. Rip a CD.
2. Change the view to the "Recently ripped" smartlist.
3. Slow-double-click the name field of one of the files and change the tag.
4. The filename field inside the database changes. (The disk file is not renamed.)


Here is an example. I ripped a CD and changed the last track's Name field from "Dead By X'mas" to "Dead By Christmas".

A screenshot of "Recently Ripped":



A Screenshot of "Drives & Devices":



Here's the log: Log.zip

[Matt]

This will be fixed next build.

Note that if our theory is correct, it would only affect the last file in the list.

[MusicHawk]

>> last file in list

While hoping you've found and nailed the problem, I'm curious (if you can elaborate), which list do you mean? The entire Recently Ripped view, or a shorter internal list of pending db writes. Does this list have a fixed max length, and/or is writing it to the db time-based, or is the code looking for a pause in user activity, or when an array/buffer reaches a trigger point?? In other words, is there a specific sequence that would trigger the incorrect behavior, so we can test that it's banished?

[JimH]

Build 530 is available at the top of this board, and should fix this problem.

[MusicHawk]

Fingers crossed, THANK YOU!