You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Go to a video, such as a random YouTube video; it doesn't need to be a music video
Go into DevTools
Go to the Network Tab
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
The text was updated successfully, but these errors were encountered:
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.
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
How to reproduce
Steps to reproduce the behaviour:
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)
The text was updated successfully, but these errors were encountered: