2091 Album Artists, 3126 Artists, 6635 Composer = How many EmbyArtists

[user24 313]

Hi Luke, after some more thinking, here's a (simple is better) naming option for you to consider...

• Featured On> (grouped name)
• Featured Artist> (ungrouped name)
• Featured Composer> (ungrouped name)

Essentially, just replace the current "Appears On" with "Featured On". I quite like "Featured" because it aligns nicely with existing MusicBrainz terminology and works well for both "Artist" and "Composer" entities.  This would also reduce the possible new section headings to just two (non-verbose) words, that are very distinctive, from the other existing headings.

This would potentially give sections (current ungrouped order):

• Songs>
• Albums>
• Featured On>
• Included In
• More Like This
• About

This would potentially give sections (new grouped order):

• Songs>
• Albums>
• Featured Artist>
• Featured Composer>
• Included In
• More Like This
• About

[Luke 42077]

Quote

Featured Composer

I don't think this makes sense. To me, this makes it sounds like I'm going to be looking at a Composer or list of Composers. It's not clear that there will be a list of albums under there. I don't love the extreme verbosity either but it has to accurately describe what you're looking at.

[user24 313]

OK then.... I haven't given up just yet... if the section context is "Albums" ... and the section differentiator is 'contributing entity'.... then, perhaps...

• Featured Artist Albums
• Featured Composer Albums

I'm not super-keen on these myself, but it may help lead you to the Apple-like elegant solution that you're probably aiming for???

My thinking cap has now fallen off for the day... but I'll check back again if anything else comes to mind later on...

[user24 313]

Hi again, A couple more thoughts… (nothing to do with naming)… you are probably aware of this anyway, but just in case it's of any help…

Similar to your pictured example, there is the potential for a split “Appears On” section to give MANY Album duplicates across the two new sections, depending greatly upon the make-up of a music library, plus how the music is tagged;

• The new Artist row would be showing (Artist + Composer tagged) Albums and (Artist only tagged) Albums.
• The new Composer row would be showing (Artist + Composer tagged) Albums and (Composer only tagged) Albums.
• Albums could potentially also be duplicated through random correct Artist/Composer tagging of different Songs on a compilation Album, giving unexpected associations? This is a much more unlikely scenario - but still possible.

Any of this could potentially cause a lot of confusion and annoyance? But a Group/Ungroup option would perhaps get around this?

Also, irrespective of duplicates, if Play/Shuffle was selected from the top of an Artist page, like it is done now, then all of the underlying Composer only Songs would still be in the mix, no different to now. Therefore the OP request to filter out the Composer only Songs would not be achieved (but of course they should comment on that for themself).

Please don’t take this as me not supporting splitting the “Appears On” section (because I do support it). Anything that allows for greater sub-sectioning of a large music library is good for me (e.g. Artist/Composer split, sub-genres, Album release types, etc.). This all contributes towards greater individual customization, especially if/when new “smart” functions are added later on…

Thanks for considering!

[Luke 42077]

They won't show up in the second and third section if they are an album artist. 

[user24 313]

On 3/11/2025 at 2:08 PM, Luke said:

They won't show up in the second and third section if they are an album artist. 

All good with me. Whatever Emby potentially implement with this will likely be very useful for me and everyone else with large music libraries. 

As an aside, I've been trying out some different Album hierarchy sizing as follows (full-screen landscape - still early days WIP):

If/when "Appears On" is split int two rows, then three Album rows will fit very nicely into a full-screen Album-focused view. E.g. a large main "Albums" row with two smaller secondary "Artist" and "Composer" rows underneath. This sizing is possibly not suitable for Emby to implement across everything because I don't think it works well for portrait view or phones, but it's great for landscape on a touchscreen laptop or tablet! Anyway - it's just a FYI to consider...

Keep up the good work with everything you do. Cheers!

[Luke 42077]

The changes I mentioned are already in the beta channel by the way.

[Vicpa 611]

On 5/23/2024 at 9:40 AM, Vicpa said:

EMBYARTSTS=  AlbumArtist(TPE2) + Artist(TPE1) + Composer(TCOM)

Hi @Luke

Is there now an option to define the above grouping ?

On 3/19/2025 at 10:58 PM, Luke said:

The changes I mentioned are already in the beta channel by the way.

 

[Luke 42077]

No it’s just based on embedded info.

[user24 313]

On 3/20/2025 at 1:28 PM, Luke said:

The changes I mentioned are already in the beta channel by the way.

Luke, Thanks for the heads up. I’ve set it up it now and done a small test to verify for myself how it works, by tagging “John Smith” in all the different combinations of AlbumArtist, Artist and Composer:

(The tagging is shown in the Album Title, where 1 = “John Smith”)

The "John Smith" results for Emby 4.8.11.0 and 4.9.0.42-beta are both as I expected they would be:

Therefore, I guess this will work well with my whole library when I get around to checking it out a bit more…

One thing I did notice though, that seems to be inconsistent, is that, when the Album Years are all the same, the row sort order becomes ascending alphabetical title for the main Albums row but descending alphabetical title for the other rows (both stable and beta). It’s not likely going to be greatly noticeable in practical use but was obvious with the test above. I also tried with letters and got the same result.

Do you have any plans for making the new rows expandable as their own separate grid page view, like the Albums row is now? Even with “Appears On” being split into two rows, there can still be many Albums in a single row with no way of further viewing/sorting/filtering/playing/etc.

[Luke 42077]

Yes we should make them clickable.

[Vicpa 611]

@Luke

Thanks for the confirmation, that you are 

1) Not doing what you could, I guess you won't (or can't , or are clueless)

2) You have no SME's that can change that, yikes even @softworkzcan't be bothered to understand the difference between shuffle and random play. Or be bothered by it

Glad there are so many better out of the box Music Options .

Emby Music= Your Music, Luke's way..........

 

[Luke 42077]

3 hours ago, Vicpa said:

@Luke

Thanks for the confirmation, that you are 

1) Not doing what you could, I guess you won't (or can't , or are clueless)

2) You have no SME's that can change that, yikes even @softworkzcan't be bothered to understand the difference between shuffle and random play. Or be bothered by it

Glad there are so many better out of the box Music Options .

Emby Music= Your Music, Luke's way..........

 

Hi @Vicpacan you please provide some coherent feedback that isn't a rant? It's impossible to understand what you're trying to suggest. Thanks.

[visproduction 315]

Vic,

These sorting features are a large challenge and require a lot of code and testing.  It helps to have all the requested features in one place and could be nice to make a numbered list.

A quick search online for white papers finds a lot of content.
 https://duckduckgo.com/?q=Sort+Music+database+white+paper+best+practice&ia=web

It's interesting to note that average development costs to add extensive sorting options inside a software package also needs different code to work for HTML, Android and iOS.  So, if you add the feature set to all, it's a 3 way development and it has to be QA tested, bugs listed and fixed in beta testing before release.

A little insight on the steps involved in adding a lot of these search and sort functions, testing and fixing issues with  large diverse dbase examples.  Have a look at this step by step process and cost estimation.  Entertainment app is probably the closest to a similar project on this breakdown.
 https://www.technbrains.com/blog/ios-app-development-cost/
Entertainment app    3-15 months    $15,000-100,000

Vic, I don't know how close you are to the actually code development process, but perhpas it is more involved than you think.

Whatever the actual dev team project manager says about this, is the best info to follow.  I am just an outside code developer who has worked on other large social media, domain hosting and content distribution services.  It seems like the Emby team is trying to work on this.  Hopefully, there will be some updates soon.  It's a lot of work.  That's all I wanted to mention.

[visproduction 315]

Vic,
By the way. I love music and studied in the UK for Music and Sound Engineering.  I've seen and met many musicians coming through with some of the music industry connections in London, including McCartney, Roger Waters and seen many amazing Jazz and live performances around the UK for quite a few years.  I did not get to see Miles.  I do have a huge collection of rarities which I like to playback on a decent tube based system, that unfortunately is all in storage.  Anyway, I appreciate your enthusiasm for Music.

[Vicpa 611]

55 minutes ago, Luke said:

Hi @Vicpacan you please provide some coherent feedback that isn't a rant? It's impossible to understand what you're trying to suggest. Thanks.

Read the thread