Print

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

[vagskal]

The last couple of weeks I have noticed that the data in a (artist) relational custom field have been mysteriously altered. I have a custom field (string type, but with ISO date data, i.e. 1931-02-22 or 1932 or 1932-02), Date Born, relational to Artist and as of lately a smartlist I have to check that the relation is working (code: [Media Type]="audio" ~nodup=[Artist],[Date Born] ~sort=[Album] ~dup=[Artist] ~sort=[Artist]) has been reporting from time to time inconsistencies - artists (groups, not individuals that have been born sometime) that should not be assigned that value has in some cases been assigned such value and in several cases an artist (individual) had been assigned one or more incorrect values in addition to the correct value. I have a corresponding Date Died relational field that has the same issue.

I have added a lot of data to that field lately, but I would not have done all the mistakes reported by the smartlist. Yesterday the smartlist again reported faulty values for some 30 artists. I correct the values by clicking on the little arrow beside artist to get all files with that value, check in the tag action window that there is just the correct single artist in the Artist field and use the drop down list on the Date Born field, which is showing Varies, to choose the correct value. The correct value is always there and sometimes there are multiple wrong values and sometimes just one file has an incorrect value; sometimes the incorrect value is empty, i.e. nothing. The incorrect values seems completely random, but as far as I can tell the incorrect values for one artist correspond to correct values for other artist(s), i.e. I have not found completely new date values added.

Earlier I thought that I must have made some mistake, but yesterday I first noticed that when I went back to the smartlist after I had corrected the values for one artist the number of artists with wrong values had increased. In fact I had to correct the value for poor Ella Fitzgerald (with almost 500 songs i my library) four times before the correct value for her stuck.

Has anyone else seen this?

[Matt]

I want to make sure I understand.

Are you saying that editing a value in a list would cause the change to revert back to the wrong value right away?

Or was it after something like an auto-import?  Or was it that some files didn't change right away?

[vagskal]

Let me take an example. The smartist reports that (inter alia) the artist Ella Fitzgerald has multiple Date Born values. I click on the arrow next to her name in the grid to search for [Artist]=[Ella Fitzgerald]. In the resulting view (with all files selected or deselected) Ella Fitzgerald is shown in the Artist field in the tag action window and in that window the Date Born field shows "Varies", which I hope is not supposed to happen with a field that is relational to Artist. I invoke the dropdown menu in the Date Born field and can see, in this case, several different values above the dotted line. I choose the correct value (1917-04-25) and then use the go back option to return to the smartlist, then correct in the same manner the Date Born value for another artist and go back to the smartlist and sometimes Ella Fitzgerald shows up again, i.e. the correction did not stick.

The same thing has happened also with artists with fewer files in the library, maybe just one album so any changes would have been saved to the file tags before I switched back to the smartlist.

The basic issue for me is that MC somehow by itself makes it so that files with one and the same value in the Artist field can have different values in the custom Date Born string type field which is set to be relational to Artist ("Store one value for each artist"). A secondary issue is that when this relation for some reason does not work a manual correction (manually setting the same Date Born value for one Artist) does not stick sometimes. And if there was no basic, primary, fundamental issue in the first place then the secondary issue would not be an issue at all.

I do not know what causes the basic issue.

I have not imported (auto or otherwise) any new files to the MC library in the time frame relevant, i.e. from when the smartlist did not report any inconsistencies until it did. But I have in the meantime entered a lot of Date Born values for artists that previously did not have any value in that field.

Please let me know if I have misunderstood the nature of the relational field (so that files with one and the same  Artist value actually can have, in this case, different Date Born values) or anything else.

Thanks for taking an interest. Let me know if you need some more information.

[vagskal]

Oh, and the answers to your concrete questions.

Are you saying that editing a value in a list would cause the change to revert back to the wrong value right away?

Or was it after something like an auto-import?  Or was it that some files didn't change right away?

The Date Born field is a string type field (not a list) just as the stock Artist field shown in the tag action window.

I checked that I had changed the Date Born field to the correct value (when selecting all files the Artist and Date Born values were, respectively, the same, as reported by the tag action window) before going back to the smartlist. And no, the smartlist did not right away report that artist as having incorrect values again. It took a while. I did not do any manual auto import or update the MC fields from the file tags.

[MrC]

vagskal - does this still happen, and if so, does it look like the same issue here?

   http://yabb.jriver.com/interact/index.php?topic=77960.msg529559#msg529559

[vagskal]

This has since long been fixed. My smartlists to check relational field consistency have not alerted me to any anomalies for a very long time.

The only issue I have with relational fields now is if I have a list of artists and a field relational to artist. If the primary artist has a relational value and I alter the primary artist, the new primary artist inherits the relational value from the former primary artist (at least if the new primary artist does not already have a relational value; I cannot remember what happens if he already has a value).

Artist: Artist1; Artist2     Relational field: Xxx

Alter to Artist: Artist3; Artist2 or Artist2 and the Relational field still says: Xxx

[MrC]

Ok, thanks for the input.

Take a look at Matt's explanation in the thread linked above.  Maybe that makes sense for what you see.