Bugzilla – Bug 6276
COMPOSER tag not displayed when there is no ARTIST tag
Last modified: 2011-11-06 23:24:50 UTC
When a file is tagged with COMPOSER, CONDUCTOR, BAND (orchestra), PERFORMER but without an ARTIST tag, it confuses Moose (moose keeps the previously used artist tag), Squeezescrobbler (squeezescrobbler tries to scrobble with an empty artist), etc. This situation can obviously be solved by copying COMPOSER tag in ARTIST tag on those files, but having a "fallback behaviour" at squeezecenter level can be a nice feature. For my personal use, I write the attached patch. It is rather "bulk" as I've chosen to give COMPOSER tag complete priority over ARTIST tag: if COMPOSER tag exists, it will be used whatever the ARTIST tag is. Maybe this could be made an option "give composer tag priority" in Squeezecenter settings panel or it could be improved to work this way: ===== if( not exists(tags->{ARTIST}) and exists(tags->{COMPOSER}) { return tags->{COMPOSER}; } ===== What can be done for this specific case? I've seen a lot of old bugs about COMPOSER and ARTIST and I fear my feature could be a bug for some others.. I don't really know what to think about it... can somebody comment? Robin
Created attachment 2470 [details] Bulk patch replacing artist by composer if it exists
My feeling is that there are plenty of options for tagging software. Those should be used to populate the tags in the way required to provide SqueezeCenter the info it needs, in the way that you want it. Blank should mean "nothing to do here" as the increasing attempts to do something intelligent with missing data is just causing increasing confusion, special cases, and bugs.
I'm sorry not to agree totally with you. I've already received that kind of answer in the forum. If this is answer is shared among everyone... I must incline and I wont insist, keeping my patch for myself. But... In my mind, a file with COMPOSER, CONDUCTOR, BAND (orchestra) and PERFORMER has no "missing data". According to id3 reference: TPE1 The 'Lead artist(s)/Lead performer(s)/Soloist(s)/Performing group' is used for the main artist(s). They are seperated with the "/" character. TPE2 The 'Band/Orchestra/Accompaniment' frame is used for additional information about the performers in the recording. TPE3 The 'Conductor' frame is used for the name of the conductor. TPE4 The 'Interpreted, remixed, or otherwise modified by' frame contains more information about the people behind a remix and similar interpretations of another existing piece. TCOM The 'Composer(s)' frame is intended for the name of the composer(s). They are seperated with the "/" character. Nothing says TPE1 is mandatory or can/should be filled with composer. I agree that what I'm doing is not standard according to "what people do" or according to "how programs work". But I feel like everybody is doing wrong and I'm doing right (I'm the Don Quichotte of music tagging :) ).
Your comment does not contradict what I have said. Re-reading your initial report, it seems that your problem is with Moose. I'd guess that the bit of code that updates artist info is looking to update based on "if (artist)", which would be false for a blank artist tag. SlimServer/SqueezeCenter tracks composer/artist/band/etc as contributor roles. They can and should be handled as the roles that they are. There is already a pref for including composer/band/conductor in artist lists. If the Moose problem turns out to be that the CLI command it's using refuses to return data for a track when there is no artist, then I'd see that as a bug. Otherwise, it's more a case of specific use of the existing data. What to do with it is a design choice, so I have no opinion on what Moose should do.
I don't know how moose updates its track info, but I agree that there is some sort of problem with the updating code of this field. But as I mainly use moose for browsing album art, that wasn't really a problem. Things began to get worse with squeezescrobbler that tried to scrobble tracks with empty artist that leads to error in scrobbler protocol. The second "problem" (sort of) is that when there was both a COMPOSER and an ARTIST, let's say "Antonio Giovanini" as ARTIST and "Antonio Vivaldi" as COMPOSER, or "Philippe Herreweghe" as ARTIST and "Johan Sebastian Bach" as COMPOSER, Squeezescrobbler sends track by "Philippe Herreweghe" or "Antonio Giovanini"... that is true, but I prefer to remember in my listening statistics that I listen to some Bach or to some Vivaldi than to gather statistics about soloists or conductors (this isn't meaningful at all with scrobbler). For sure I can (and that was my first idea) patch Squeezescrobbler and contact Moose developer for a fix of the artist field update, but I thought that the Squeezecenter workaround was broader and could be useful for other classical music fans like me. If I'm wrong with this, It's not a problem as I have my solution... it was just for the community. Just for being clear, I have absolutely no complaining about how SC deals with composer/artist/band tags in the web or SB interface, I set the options and It works perfectly...it's all about SC extensions...
Chat log with triode about this: Triode RobinV - there is already some support for treating composers as artists via the composerInArtists pref. There's lots of extra logic for this and unfortunately some of the recent changes have not really followed it, but I would suggest any enhancement should be aligned to it. So I think perhaps track->artist should be using artistOnlyRoles rather than being hard coded. Who's the db expert these days???? Robin V. "composerInArtists pref" you mean "Composer, Band and Orchestra in Artists" option in preferences? Which recent changes are you talking about? Can you explain "track->artist should be using artistOnlyRoles rather than being hard coded" ? Triode yes to first bit, it is used in creating result sets from the database. Its current use is to allow you to browse by contributors including these optionally. I was thinking it could be used to define what track->artists returned. However there's probaly a performance hit from that. Triode Much of the recent UI is just doing $track->artist[0] so getting the first artist for a track which means that adding multiple tags per track is probably less valuable now.. Robin V. This option is working very well for browsing the music collection with the Squeezebox or the web interface. So your advice would be to use this preference to choose which roles to include in "track->artists"... it's a good one I think Triode The main issue here is performance vs configurability/flexibility. We appeared to have been heading in the flexibility direction, but if we only show one artist per track/album we should probably go back to the simpler schema and performance direction.....????? Robin V. if @{track->artists} is filled according to the composerInArtists (and alike) parameter, this could solve the problem rather cleanly... Triode yes, but need to understand the performance hit as track->artist is called a lot - I'd sugget adding this to the enhancement request and it can be considered post 7.0 Robin V. i don't know enough the guts of SC to really understand performance effects of these kind of changes... I'll copy a log of this chat in the bug report Robin V. i thought it was mostly called in small list context (now playing display, song details, not in bulk database operation like album/artist/song browsing
Will look at this post-7.0.
Unassigned bugs cannot have a priority.