## Description The Music / Artists view currently appears to use the artist metadata from individual tracks. While at a track level this makes perfect sense, it can result in a very noisy and fragmented artists view. For example, an album by Eminem might contain tracks with artists such as: - Eminem - Eminem feat. 50 Cent - Eminem ft. Rihanna - Eminem & Dr. Dre Each of these seem to appear as a separate artist entry (even though they are all tracks from the same album by Eminem) This becomes particularly noticeable in large music libraries, where featured artists, collaborations, remixes, and slightly different artist metadata ends up resulting in a large number of sparsely populated or duplicate / strange looking artist entries. This PR adds an option / toggle to determine which metadata field is used to populate the artists view. This option sits neatly within the current artist view settings e.g. Music > Artists > View options > Artist source - Artist (current behavior) - Album Artist (use the album artist metadata instead) That Artist setting stays as the default choice (so nobody sees a change unless they pick it) but now gives the option to filter down only to Album Artists if desired - this choice is saved per library and applies immediately. ### Related issues Closes #1868 ### Testing I've tested it extensively on an Amazon Fire TV Cube Gen 2 (using the firetv debug variant) the following manual tests were performed: - The list changes when you pick Album artist and importantly the selection survives a full app restart - It was tested on a large library and can confirm only the Album Artists remained (e.g. only one Eminem entry remained) Automated checks were run (testFiretvDebugUnitTest & pre-commit) As well as two new tests being added to the CollectionFolderViewModelTest.kt: - For letter counting its checking via the album artist endpoint (and not the standard one) when the source is set as ALBUM_ARTIST - When the source is changed via the saveViewOptions its triggering a load from the album artist endpoint ## Screenshots Please see the screenshots below showing the UI impact / modification: <img width="4624" height="3472" alt="1" src="https://github.com/user-attachments/assets/6b53575e-ad15-4f66-b9c0-074657128a1d" /> <img width="4624" height="3472" alt="2" src="https://github.com/user-attachments/assets/528c5766-44d8-43d3-8519-778f5aab7441" /> <img width="4624" height="3472" alt="3" src="https://github.com/user-attachments/assets/5de2fb6d-173d-4ac3-ad1b-e08f27f4dafd" /> ## AI or LLM usage The code was written / supported with Claude - the approach (e.g. design / storing the choice in ViewOptions) endpoint research etc was done by myself - I reviewed the approaches / refactoring and than deployed a debug.apk to my local device to confirm everything was working as expected. I've reviewed each line and can explain it / the thinking to approaches / logic etc and am comfortable submitting the PR. --------- Co-authored-by: Damontecres <damontecres@gmail.com> |
||
|---|---|---|
| .. | ||
| config | ||
| schemas/com.github.damontecres.wholphin.data.AppDatabase | ||
| src | ||
| .gitignore | ||
| build.gradle.kts | ||
| proguard-rules.pro | ||