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

Cover Art Sending requests on disabled tracks #4474

Open
Lagicrus opened this issue Jan 30, 2024 · 1 comment · May be fixed by #4475
Open

Cover Art Sending requests on disabled tracks #4474

Lagicrus opened this issue Jan 30, 2024 · 1 comment · May be fixed by #4475
Labels
bug Something isn't working

Comments

@Lagicrus
Copy link

Describe the bug
When WS detects you are on a video, even if it is not a detected song, it will still send a HEAD request through to coverartarchive.org even though it has nothing to show.

This is the case even when

  • The video is not a detected song
  • The channel has been disabled for WS

How to reproduce
Steps to reproduce the behaviour:

  1. Go to a video, such as a random YouTube video; it doesn't need to be a music video
  2. Go into DevTools
  3. Go to the Network Tab
  4. Watch the requests; you will find one to coverartarchive.org that gets redirected

Expected behaviour
Not to send a network request when the video isn't even a music video, nor is detected as one you want it to scribble.
It should only lookup the album art if you actually open the popup and not just have it running in the background.

Environment (please complete the following information)

  • OS: Windows
  • Browser: Chrome
  • Extension version: 3.5.0
@Lagicrus Lagicrus added the bug Something isn't working label Jan 30, 2024
@yayuyokitano
Copy link
Member

This should be implemented, though it is not trivial.
The user is allowed to force scrobbling a song marked as disallowed. This does not trigger a reprocessing, nor should it.
This means that we cannot actually rely on the pipeline for this, and have to move the logic out to lazily load it as needed.

Most likely this means implementing an abstract function on the BaseSong class named something like fetchTrackArt.
This function will be checking if there is anything in parsed.trackArt or metadata.trackArtUrl.
If those return null, then fetch. If nothing is returned we explicitly set metadata.trackArtUrl to the default art to avoid refetching.
In the clonedSong implementation we must also then send that trackArt down to the main song in the content script, as the fetching may (and usually will) occur in a clone in background or popup.
song.getTrackArt can then call fetchTrackArt as part of its implementation.
on top of getTrackArt itself having to call it, it must also be called in the webhook scrobbler before the song is sent.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants