Print

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

[Rubberduck0]

I noticed two things, which came unexpected and are disturbing in my point of view. That is, unless I am mistaken or did something wrong...

1) [Artist] does not retrieve the artists if separated with a semicolon
When I use the [Artist] field, e.g. in move, rename, copy, and the artists are separated with a ; then I only get the first artist. If they are separated with other characters then it works. I've read something, that this field, like genre, is actually a list field now and just looks like a string field, where ; is the list separator. So be it. But IMHO that cannot be the intended behavior. Even as a list the [Artist] field should return all artists. Furthermore as I could not find any other field or method to retrieve the full list of artists.

2) Quicksearch for artist (sorry, have no idea how to name this better)
What I mean is the little arrow in front of an artist name (also album and genre have this). If you click on that then the search field is pre-filled with the artist and I see all songs from this artist. Or so I would think. But this is not the case. Because in some cases, where an artist is listed as the album artist but not in the artist field itself, this will not show up (e.g. George Micheal's album 'Five Live', track 6 'Dear Friends', where this is performed by Queen only. If I click on the little arrow in front of 'George Michael' the song disappears/does not show). This is somewhat unexpected and confusing. Even more so, as if I type 'George Micheal' manually into the search field, the song does show up. So, in both cases I will see 'George Michael' in the search field, but the results are different. So I'd think that "Quicksearch" for an artist should also take the album artist field into account.

If you want to make me happy, then please tell me that these two issues are bugs and are corrected soon...

[MrC]

Regarding (1), use [Artist,0] when you want the entire list.   The ,0 gives you the raw field data:

   http://wiki.jriver.com/index.php/Media_Center_expression_language#Fields

[kstuart]

I don't think that you are referring to this... but just for future readers...

In many places, where MC18 shows the word Artist (as a column header, for example), the actual data it uses is the value of [Album Artist(auto)] which is the first part of [Artist] up until the first semicolon.

[Rubberduck0]

Regarding (1), use [Artist,0] when you want the entire list.   The ,0 gives you the raw field data:

   http://wiki.jriver.com/index.php/Media_Center_expression_language#Fields

Thanks a lot. Although I regard this as a workaround. I still find it confusing and should be the other way round, i.e. there should be a function which gives the n-th element of a list, so e.g. [Artist[0]] would give the first artist name. But the default field [Artist] should return what one would naturally expect, the full artist, especially as this only happens with a semicolon as delimiter. I understand the technical reason behind this, but does every user have to understand this?

I don't think that you are referring to this... but just for future readers...

In many places, where MC18 shows the word Artist (as a column header, for example), the actual data it uses is the value of [Album Artist(auto)] which is the first part of [Artist] up until the first semicolon.

No, this is something different. It also works a little different as you describe it. It actually uses the [Album Artist] field, if it is not empty. If empty, it uses the first entry of the [Artist] field. However, in both cases this is only true, if all tracks of an album have the same entries. If one or more tracks differ in the artists, then [Album Artist(auto)] returns "(Multiple Artists)".
By the way, I never liked this field as I do not want to have "(Multiple Artists)" in my collection. But with JRiver this is no problem, and I created a simple custom field which gave me exactly what I wanted:

Code: [Select]

If(IsEmpty([Album Artist]),[Artist],[Album Artist])

[MrC]

Thanks a lot. Although I regard this as a workaround. I still find it confusing and should be the other way round, i.e. there should be a function which gives the n-th element of a list, so e.g. [Artist[0]] would give the first artist name. But the default field [Artist] should return what one would naturally expect, the full artist, especially as this only happens with a semicolon as delimiter. I understand the technical reason behind this, but does every user have to understand this?

It doesn't make sense in same cases to present the entire list of artists.  The change from a single value to a list for Artist (and other fields) required some smart defaults.  How should Album Artist (auto) be handed, for example?

The ,0 field modifier is standard in MC - it is used to obtain Raw field values, whereas ,1 returns formatted (display or pretty-printed) values.  In most areas, the ,1 usage is default.  This makes sense for things like Rename and Album Artist (auto).

The ListItem() function can return the nth value of any field with an arbitrary delimiter.

I suppose every user does have to understand delimiters to some degree, if they care about lists.  And semicolon is MC's default separator.

[kstuart]

I think those are all really good choices.

You don't want "comma", because of single Artists like:

Crosby, Stills, and Nash

I don't think I have ever encountered a semicolon in a real artist's name, since they are used as part of sentence structure.

[Rubberduck0]

Understood, although definitely not agreed. I think the other way round would be more intuitive. I also don't see the problem with "Album Artist(auto)", as in my understanding this is only one name (or a "(Multiple artists)" album) and therefore, if there is a list, it is only the first name. But that doesn't mean that if I want the field value of [Artist] I also get only the first name.

However, I do not want to start a fruitless discussion. I understand that both issues are the intended behavior (for the second I guess so, as there was no response to that).

@kstuart:
I didn't want to question the semicolon as separator. It comes as a natural first choice. But a slash would also be a good choice. I just think it is not good, that depending on the separator someone uses, the behavior of the [Artist] field is totally different. What if you already have a large music collection started many years from now, and back then you unfortunately decided to use a different separator? Or you used another MC before JRiver and that MC uses a different separator? So, the separator is not always a deliberate choice.
Therefore it would be intuitive for me to return the whole field, because this is what people expect and this would be the same for all separators. Even more so, as there is already a function to return the n-th element of a list. So, for all those purposes where you want to have the first name only, just use "listitem([Artist],0)"... But wait, I said, I do not want to start a discussion on principles... sorry for that...

[kstuart]

Slash is already used in Artist names, eg "AC/DC".

Semicolon is about the only separator that is not commonly used in any artist names, yet is intuitively noticeable as a separator.

And it doesn't require a shift key, which is a plus over the long term...

[MrC]

But a slash would also be a good choice.

Slash is illegal in file system path names, and therefore requires translation before using metadata as a template for renaming files.  This then makes it impossible to reverse the action (going from file or folder names back to meta data).  The only way to avoid this would be to encode a slash, but that encoding would only have meaning to MC and hence would not be portable.

[Rubberduck0]

Sorry, for not expressing myself clearly. I also think that semicolon is the best separator and as a list delimiter for MC the only one choice which makes sense. What I meant with "Slash would also be a good choice" was not in respect to MC, but that some users might regard a slash (and this was only an example as I am sure there are some more separators used by some users and/or media centers) as a good enough choice and may use this instead of semicolon. And in such cases the results from the [Artist] field are not consistent as they differ from a semicolon delimited list.

Again, I do not want to steal your time on a discussion on principles. I understood that this is intended and therefore will not be changed. And there is a solution for me ([Artist,0]) and so I can/have to live with this.

For issue 2 I admit this will not happen very often, as in most cases the album artist is also the performing artist, or one of the artists. The problem only occurs if this is not the case and I only have this one example I mentioned. So, this is also more an issue of principles then a real problem. I just mentioned it, because I am very keen on principles and if I were a developer of MC I couldn't live with this...