9001
MediaSession artwork weirdness on windows 11 with firefox
When playing a music file, the Mediasession artwork doesnt display on windows. After testing its because either windows / firefox decides to fetch the artwork themselves. And since their request doesnt have proper auth, its returning the e304 svg and being brokenly rendered. (shown the unauthenticated request)
I confirmed by turning the folder into a share and it displays fine.... kinda.
The artwork aspect ratio is off even tho its displaying properly on the browser
Just to confirm, i checked navigator.mediaSession.metadata and opened the artwork src manually and indeed its returning a weird image size
For the first part of the issue i was planning on making a PR where it first fetches the artwork, converts it to a base64 then uses that for the artwork, but the weird aspect ratio of the thumbnail made me write this bug report first.
Also of note, the src of the thumbnail on the browser and mediasession has different query string.
Browser: server.com/bla/song.flac?th=wf&cache=i&_=1Ek2e
Mediasession: server.com/bla/song.flac?th=j
Im unfamiliar with the codebase and cryptic codes sooo idk wut these mean kekw
To Reproduce
Just play a song on a server on a windows 11 machine using firefox ig
Expected behavior
Everything to work
Server details
remove the ones that are not relevant:
- Linux Arm64
- SFX
- copyparty v1.19.20 "usernames" (2025-11-02) CPython v3.9.21 on Linux64 [GCC 11.5.0 20240719 (Red Hat 11.5.0-5.0.1)] sqlite 3.34.1*1 | jinja 2.11.3 | pyftpd 1.5.10 | tftp 0.4.0
Client details
- OS version: Windows 11 26100.2161
- browser version: Firefox dev editiron 145.0b9
the thumbnail is cut off because by default, everything gets cropped to 4:3
the url given to mediasession specifies ?th=j, which means it requests a jpeg thumbnail with default cropping and default resolution
the browser js, meanwhile, requests ?th=wf, which means it wants a webp that's not cropped ("full")
(there's also 3 which corresponds to the 3x size button in the ui)
the conventional solution to this was to enable filekeys in the volume and give unauthenticated users the g permission, because that way the requester gains access through the filekey instead -- but the idea of optionally base64-encoding the image could also solve displaying the cover-art on car stereos, which currently does not work.
just two immediate concerns,
- I have a suspicion that timing is relevant for when the mediasession is set, relative to when the audio playback is initiated -- some browsers / devices seem reluctant to use it if the timing is wrong. However it is currently not working on all combinations of browsers/devices either way, so perhaps the delay added by the fetch could be a good thing
- there is probably a max size limit for the metadata depending on the receiving device, so it might be necessary to further shrink the image before adding it to the metadata, by painting it to a canvas and exporting a new jpeg at a lower quality (and/or resolution?)
- it is possible not all browsers/devices accept base64-encoded images, so there should be an option to disable this
I'm thinking a new UI setting could be added, a textbox which specifies the max size of the image after base64-encoding, and it would gradually reduce the quality in the jpg-export from the canvas to make it fit -- and leaving this field empty would also disable embedding with base64, using the regular url instead.
EDIT: Scotsguy covered the essentials, but I'll mention the other parameters too:
- th=wf&cache=i&_=1Ek2e means... *wf -- webp, fullsize (not cropped) -- alternatively jf / jf3 / j3 -- but maybe some devices may expect 4:3 or even 1:1
- cache=i -- adds a cache header in the response duration
i= "infinite" = 1 week - _=xxx -- cachebuster
Nvm i think its better to solve this by either adding some sort of special query string to bypass auth just for the thumbnail or stick with the conventional solution of granting g permission. Converting to base64 is not a viable option because after some more testing turns out theres a lot of inconsistencies on how the media thumbnail interacts with the browser, and OS.
Here are some of my testing results.
-
Android & Firefox
- without auth the e304 svg renders properly
- does not support base64 or blob url
- polls the artwork url every x seconds
-
Windows & Firefox
- windows doesnt render svgs / base64 / blob url
- i think firefox just gives the url to windows and lets it fetch it itself so it received the svg and renders brokenly
-
Windows & Edge (im assuming chrome will be the same)
- works outta the box lol, i didnt see the
@* has no accessmsg on the server so its fetching it then giving that to windows - confirmed by blob url also working
- svg works must be predendering it for windows
- base64 doesnt work for some reason
- works outta the box lol, i didnt see the
So yea i prob wont be makin a fix anytime soon. Also jf should mean jpeg full no crop right? But trying it returns the 4:3 cropped version. Is my assumption incorrect?
unfortunate that so many devices don't support base64 links; and allowing unfettered access to thumbnailing files without auth sounds iffy, so filekeys are better then i think.
Also jf should mean jpeg full no crop right? But trying it returns the 4:3 cropped version. Is my assumption incorrect?
no that sounds correct; for example:
- https://a.ocv.me/pub/demo/pics-vids/internet.jpg?th=j
- https://a.ocv.me/pub/demo/pics-vids/internet.jpg?th=jf
- https://a.ocv.me/pub/demo/pics-vids/internet.jpg?th=j3
- https://a.ocv.me/pub/demo/pics-vids/internet.jpg?th=jf3
the last two links produce the same picture because the source image is so low-resolution that cropping would be counterproductive, but you're seeing pictures getting cropped when they shouldn't be, so i don't have any explanation for that...
same thing on a larger picture for reference:
- https://a.ocv.me/pub/stuff/adabana-necromancy.png?th=j3
- https://a.ocv.me/pub/stuff/adabana-necromancy.png?th=jf3
You can use --ihead * to confirm your hypothesis of if it's windows doing the fetching instead of firefox itself.
For example, I just tried Windows + Firefox, and the request for the cover comes from the normal firefox user-agent string (and, indeed, without authentication, presumably because it identifies it as a cross-site request for some reason). The request even seems to show up in the networking dev tools, but I'm not quite sure since some of the headers don't seem to match up (e.g. sec-fetch-site)
According to web.dev, you can use a blob URL for artwork as well (no idea if it's supported in firefox), that might be worth trying out.
[there was originally some text here about a bug with embedded coverart but my package was just outdated, oops]