Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[MUSIC] Only set libraryartfilled property if we actually found art #24675

Merged
merged 1 commit into from Feb 10, 2024

Conversation

the-black-eagle
Copy link
Contributor

Description

Current code sets the property libraryartfilled to true, regardless of whether or not any art was actually found. This PR moves the setting to inside the if (artfound) condition so that it's only set on an item if we actually did add some art to it.

Motivation and context

With PR #21940 , playlists now accurately load the duration of a track from the m3u file. This results in the creation of a CMusicInfoTag() which contains just the duration. Before that PR, no infotag would have been created.

The end result is that art is only looked up for the first item in the playlist (previously, items had no infotag and so were always looked up) and the rest of the items in the playlist end up with the libraryartfilled property being set. This prevents the thumbloader from loading any art when called by guiinfo.

Fixes #24665

Moving the setting inside the if condition restores the correct behaviour.

How has this been tested?

Tested locally with the same playlist before and after the change.

What is the effect on users?

All items in an m3u(8) playlist will show all art items.

Screenshots (if appropriate):

Before change

Track 1 of playlist - shows fanart, album cover etc

screenshot00091

Track 2 - just album cover, no fanart

screenshot00092

Track 3 - no art at all

screenshot00093

After change

Track 2 - all art

screenshot00095

track 3 - all art

screenshot00096

Types of change

  • Bug fix (non-breaking change which fixes an issue)
  • Clean up (non-breaking change which removes non-working, unmaintained functionality)
  • Improvement (non-breaking change which improves existing functionality)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that will cause existing functionality to change)
  • Cosmetic change (non-breaking change that doesn't touch code)
  • Student submission (PR was done for educational purposes and will be treated as such)
  • None of the above (please explain below)

Checklist:

  • My code follows the Code Guidelines of this project
  • My change requires a change to the documentation, either Doxygen or wiki
  • I have updated the documentation accordingly
  • I have read the Contributing document
  • I have added tests to cover my change
  • All new and existing tests passed

@the-black-eagle the-black-eagle added Type: Fix non-breaking change which fixes an issue Component: Music v21 Omega labels Feb 9, 2024
@the-black-eagle the-black-eagle added this to the Omega 21.0 Beta 3 milestone Feb 9, 2024
Copy link
Member

@enen92 enen92 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks sane

Copy link
Member

@DaveTBlake DaveTBlake left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I really can't remember if this would upset something else somewhere, so I'm just going to believe it won't😄. Actually it is the previous changes m3u to playlists that may or may not have an unwanted payload.

But would it make sense to check the artmap rather than just remove the property setting all together?

@the-black-eagle
Copy link
Contributor Author

@DaveTBlake Thanks for your comments and approval. To be clear, what this does is move the setting inside the if (artfound) condition. This in itself is set by artfound = !art.empty();

In view of this, I'm of the opinion that artfound can only be true if there is indeed art in the artmap. Blindly setting the property, regardless of whether or not there actually is any art does not seem correct to me.

@fuzzard fuzzard merged commit 8ca23a9 into xbmc:master Feb 10, 2024
2 checks passed
@the-black-eagle the-black-eagle deleted the fix_playlist_art branch February 10, 2024 07:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Component: Music Type: Fix non-breaking change which fixes an issue v21 Omega
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Music-playlists don't use discart/fanart ... in Kodi
4 participants