When casting to jellyfin-mpv-shim from jellyfin-web in the browser,
jellyfin-web sends data about which version (for grouped items) and
which streams the user selected in the browser to the
"Sessions/{sessionId}/Playing" API endpoint.
The API endpoint currently doesn't forward them to jellyfin-mpv-shim
through the Play command, which results in the default streams being
played instead of the browser selected ones.
PlayRequest already has the properties and they are already sent to the
cast client by SendPlayCommand when present.
jellyfin-mpv-shim will already use them to select the wanted streams
when it receives the Play command.
All that's needed to make it work is to take the parameters and assign
them to PlayRequest.
Without this fix my Samsung Soundbar (HW-Q80R) fails to play using DLNA
and returns "Error: Resource not found (716)" instead.
I had a look on tcpdump network logs between Jellyfin and the soundbar
and noticed that the device performs a HEAD request for the media before
responding to the DLNA UPNP control request from Jellyfin (or BubbleUPNP
Android App).
Jellyfin retuns 204 No Content response, which is unusual. Common web
servers generally return 200 OK if the GET would return content, and
this is not-very-clearly suggested [in HTTP
spec](https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.1)
The other patch is to ensure, that invalid Content-Length: 0 is not
returned with the HEAD response in the streaming case.
I think in both cases we still don't return the same headers with HEAD
as with GET (e.g. Content-Length or Accept-Ranges), but at least we
don't return anything misleading.
GHSL-2021-050: Issue 1,2,3 Arbitrary file read and directory traversal.
The segment id's can probably just be verified to be an actual ID or to not contain any forward or backward slashes
Claus Vium
Bond-009
Ian Walton
dependabot[bot]
BrianCArnold
Brian Arnold
crobibero
lmaonator
lmaonator
cvium
Szymon Acedański
David
Erwin de Haan
Patrick Barron
BaronGreenback