Print

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

[FenceFurniture]

I did a F&R this morning:
Find: Saxello
Replace with: Saxophone–Saxello

and it gives me
Saxophone–Saxophone–Saxophone–Saxophone–Saxophone–Saxophone–Saxello
but the repeats of "Saxophone–" vary between 3 and 8 or 9 times!

I first noticed this (actually DIDN'T notice it for some time.....) a few months ago when I was changing
Name Surname
to
Name Surname(G)

because I needed to differentiate between two people of the same name.
That was giving me

Name Surname(G)(G)
Name Surname(G)(G)(G)
Name Surname(G)(G)(G)(G)
Name Surname(G)(G)(G)(G)(G)
Name Surname(G)(G)(G)(G)(G)(G)
Name Surname(G)(G)(G)(G)(G)(G)(G)
Name Surname(G)(G)(G)(G)(G)(G)(G)(G)
Name Surname(G)(G)(G)(G)(G)(G)(G)(G)(G)
Name Surname(G)(G)(G)(G)(G)(G)(G)(G)(G)(G)
Name Surname(G)(G)(G)(G)(G)(G)(G)(G)(G)(G)(G)

and so on depending on how many occurrences of the name ther were.

The other day I got the equivalent of
Name Surname((((((((G))))))))

Has anyone seen this happen, or can offer a clue?

[wer]

I've used search and replace hundreds of times, if not thousands.  I have never seen it make a mistake that was not my own error.

For example, if a field contains:
A Simple Song: Part A.

and you do a find and replace on "A"->"1" you will get results you perhaps didn't expect.

Why don't you post a video showing exactly what you do, and showing how MC recursively butchers your field?

I can see silliness like this happening if you select a whole bunch of files, and then do a F&R on a relational field that they all share. And that also would be human error.  But who would do anything like that?

[FenceFurniture]

I've used search and replace hundreds of times, if not thousands.

Me too, and most definitely in the 1000s.

I can see silliness like this happening if you select a whole bunch of files, and then do a F&R on a relational field that they all share. And that also would be user error.

It was about 1500 albums, so about 15000 files. It was in the Musicians tag (my creation) which is "one per album". I've done stacks of these and initially it was only changes that involved () until this morning with the Saxello. I'll see if I can repeat under video. All of the countless other changes I've been doing lately are also to that same tag, and with no problems.

[wer]

Fence, if you're admitting you made multiple changes to a relational field, I don't need a video.  Since you're offering to still post a video, I guess you don't get the point to what I am saying.  Let me spell it out.

If you select 5 files, and do an S&R on a relational field, it does the S&R 5 times, updating the field each time.
It EXECUTES THE CHANGE for the first file, then moves on to the second file, and EXECUTES THE CHANGE for the second file. And so on.  So think:

What happens to the contents of the relational field after it does the change for the first file?  Now what happens to those NEW contents when it does the change for the second file?

You're shooting yourself in the foot. Stop.

If you've ever gotten away with doing this in the past, it was because after the first change, the find string was no longer present in the relational field, and therefore all the subsequent changes were ignored.

Example for 5 files:

Relational Field Contents: I am silly.
S&R: "silly" -> "really silly"

Field Contents: I am really silly.
Field Contents: I am really really silly.
Field Contents: I am really really really silly.
Field Contents: I am really really really really silly.
Field Contents: I am really really really really really silly.

See what I mean?   

Your Surname(G) example is EXACTLY this. Exactly.

So I hope you see why you got away with it before. Another example.

Example for 5 files:

Relational Field Contents: I am silly.
S&R: "silly" -> "thinking"

Field Contents: I am thinking.
Field Contents: I am thinking.
Field Contents: I am thinking.
Field Contents: I am thinking.
Field Contents: I am thinking.

The relational field was still processed 5 times, but after the first change, "silly" was no longer found, so no more substitutions were made.  Get it? 

Don't select multiple files, and then do an S&R on a relational field they share. Select only one file that shares the relational field.

[FenceFurniture]

Well, I reset the files back to Saxello, videoed the process, and it changed them to
Saxophone–Saxophone–Saxophone–Saxophone–Saxophone–Saxello again,
only to find that the video doesn't capture the pop-up windows.

You'll just have to take my word for it that I know how to use F&R - 1000s of times - and it's just these couple of isolated instances amongst those 1000s.
I can provide a screenshot of the problem though: F&R 1 is the F&R window showing Musicians tag checked, Match case checked
and F&R 2 is the tag after doing it. Four of the other six albums that I did this with have 4x occurrences of Saxophone–, one of them has 6x, one has 7x.

That does match the number of tracks on each of those albums, and in this instance (only) I selected just those albums. That is in line with what you are saying
BUT, and it's a huge BUT,
why only for the Saxello change and none of the other hundreds that I have done just today. They (along with the original Saxello changes) were done to a files view, which is the third screenshot. The two versions of Head Hunters andand Thrust got 4x (4 tracks each), and Man-Child got 6x, Secrets got 7x.

I can't see how the view would make any difference (and indeed, it did not for Saxello - same result out of both views).

It just doesn't make any sense why it could be so super-selective.

[FenceFurniture]

So how can this be explained? In one of those albums I have just changed
Drums (& Percussion)
to
Drums & Percussion
and then back to
Drums (& Percussion)

quite successfully. I've probably done that 200 times or more just today, and all is well. Only the one aberration, which can very curiously be repeated but only with that same data.

Three screenshots attached.

[FenceFurniture]

That last example was an album with six files, and only one mention of Drums (& Percussion), so I thought I might do one that has three occurrences of Bass (in those same six files). The attached screenshots show that it was executed perfectly, just the same as 1000s of others I have done in the same way using the same tag "Musicians".

[FenceFurniture]

There was something I didn't make clear in this post:

Name Surname(G)(G)
Name Surname(G)(G)(G)
Name Surname(G)(G)(G)(G)
Name Surname(G)(G)(G)(G)(G)
Name Surname(G)(G)(G)(G)(G)(G)
Name Surname(G)(G)(G)(G)(G)(G)(G)
Name Surname(G)(G)(G)(G)(G)(G)(G)(G)
Name Surname(G)(G)(G)(G)(G)(G)(G)(G)(G)
Name Surname(G)(G)(G)(G)(G)(G)(G)(G)(G)(G)
Name Surname(G)(G)(G)(G)(G)(G)(G)(G)(G)(G)(G)

and so on depending on how many occurrences of the name there were.

The other day I got the equivalent of
Name Surname((((((((G))))))))

and that is that those lines are not for the files within one album - they were for the 10 albums that musician Name Surname appeared on (because the view that accesses that info only displays albums, not files.

Example for 5 files:

Relational Field Contents: I am silly.
S&R: "silly" -> "really silly"

Field Contents: I am really silly.
Field Contents: I am really really silly.
Field Contents: I am really really really silly.
Field Contents: I am really really really really silly.
Field Contents: I am really really really really really silly.

I should have pointed this out earlier. That is NOT what is happening.

Each file within the album has the same number of repeats in it.
So Saxophone–Saxophone–Saxophone–Saxophone–Saxophone–Saxophone–Saxello
where there are 6x mentions of Saxophone is IDENTICAL on each file of that album.

[wer]

Why wouldn't the contents be identical, since it's a relational field?  You told me it's a relational field.

Update: I didn't see a couple of your prior posts, since you posted so many back to back; I just went to the end.

Your example about the drums and percussion looks perfectly normal to me. I don't see any mystery in 2+2=4.  But showing me small clips, that don't show what fields are being changed, or what the F&R dialog looks like, don't tell me much.  When you do a S&R on a relational field (which I'm telling you is a bad idea: accept it) it's all about exactly what you put in the F&R, and exactly what is in the field at the time you start the F&R. With that, I can tell the results without seeing them happen. Without that, I don't know what you're doing.

Look Fence, don't I always try to help you?  You came for help. You are the one having this problem. You wanted to know how this could happen. I told you how it could happen, in a way that fit the facts as you described them.  You say I'm wrong, that that's not what's happening.

So give me something I can work with. Show me how I'm wrong, show me something I can reproduce.  I tried the S&R you described on a regular field: no problems. Do it on a relational field multiple times, you get the scenario I described.  If you want to "update" your description of the facts, because you left something out maybe, go ahead. Or give me a video, or reproduceable steps, to show me that this happens in a way other than I'm describing.  I haven't yet seen anything that doesn't fit the scenario I described.  Maybe I'm just not understanding you.  But I think I am.

[FenceFurniture]

Yes, it's a relational field, one per album. The question is why does it only happen with two very specific types of data (and can be repeated with them), and work for thousands of others. That's the part that's not making sense. I mean, I've just done a change for
Saxophone (Tenor)
to
Saxophone–Tenor

that occurs on 375 albums, so approximately 3500 files. No problems that I have seen (but I haven't inspected all 375 albums). However, there was no indication that there were any problems because I observed (actually noted) the number of changes that were made. It made 357 changes (the other 18 had already been done manually).

When it has gone berserk before I have noted that it made many more changes than I thought it should have.

[wer]

So how can this be explained? In one of those albums I have just changed
Drums (& Percussion)
to
Drums & Percussion
and then back to
Drums (& Percussion)

I'm going to post a second time, so I hope you read both.  I wanted to make you understand why I said I see no problem with 2+2=4.

You ask how can this be explained. It is very easy to explain.

So look at what you told me above.  This example will not cause you problems on a relational if you do it like this, which fits your description:

Find: Drums & Percussion
Replace: Drums (& Percussion)

That will be fine.  So will the opposite. Do it 10,000 times, only one replacement will be made and the other 9999 do nothing. That's what I understood that you did.

But do it this way:
Find: & Percussion
Replace: (& Percussion)

and you get this: Drums ((((((((((((((((((((((((((((((((& Percussion)))))))))))))))))))))))))))))))))))

So I don't see a problem with what you ACTUALLY said, because when you tell me you did it a certain way, the first way, and that way produces logical results, I believe you. I don't think you did it the second way when you tell me you did it the first way.

But you can't produce the results in my second example, doing it the way you did it in your first example.

[wer]

I think we're both typing at the same time.

If you want to keep going, I'll help, but no more descriptions alleging improper results.  Either a video, or a screenshot showing both the initial contents of the relational field, the files selected, and exactly how the F&R dialog is filled out.  BEFORE it happens. And then a screenie of the improper results.  Something I can replicate. The screenshots you gave before were either after the fact, or didn't show relevant contents. I don't need screenshots showing something worked correctly.

[FenceFurniture]

My reply #4 with the screenshots of what I did should surely say everything needed. It shows everything you have asked for except I didn't take a screenshot of it beforehand, but I know for an absolute fact that it was
, Saxello,
(there was other data before and after it which can be seen in the screenshot, hence the commas)
I know this because I changed it manually back to just Saxello (in 6 albums) before I did the F&R shown in the screenshots for the purposes of this thread. (I had already manually corrected the errors from this morning, so for this thread I had to manually take it back to what it was before any problem had occurred).

This happens only for that example. And then I was able to repeat it, only for that example. I have stayed away from the () changes since the original problem some weeks ago - I just figured that there was something about () that was causing trouble. No matter.

This Saxello thing is the only one that has happened since, and I promise you that I have done the thousands of these all in exactly the same way.

[wer]

It does show everything needed except, one thing.  It shows that you did a find and replace against a relational field, while selecting multiple files that shared that field, and that your replacement string contained the search string.

It shows that you did this:
Find: Saxello
Replace with: Saxophone–Saxello

And it shows the results that that action will rightly produce:
Saxophone–Saxophone–Saxophone–Saxophone–Saxophone–Saxello

Which is exactly what I described to you in my reply #1, and 3, and 10.

The only thing it doesn't show is your evidence for saying that I'm wrong, that what I describe is NOT what's happening, and that your results are impossible to explain. They're easy to explain, and I've explained them.

Search and Replace is a simple algebraic substitution, that when performed on a relational field multiple times, is iterative.

You can make that sort of thing happen whenever you like.  Try this. Against the same field:
Find: Saxophone
Replace with: Saxophone (Sax)

As I said before, if you do multiple S&Rs against a relational field (which is what you do when you select multiple files that share that field) and your replace string contains your search string, you will produce this sort of result.

I've run out of ways to explain it.

[FenceFurniture]

What I said was not happening was that there were different numbers of repeats within the same album.

[FenceFurniture]

and your replace string contains your search string, you will produce this sort of result.

Right. Ding! That was the explanation I needed. The search field cannot be a perfect subset of the replacement field. Had you said that, in as many words, I would have understood perfectly from the start.

Thanks for your help.