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
crobibero
lmaonator
Bond-009
Claus Vium
cvium
MrTimscampi
Szymon Acedański
cocool97
David
BaronGreenback
Kenneth SB
Nyanmisaka
Joshua M. Boniface
LIAUD
Bill Thornton
Erwin de Haan