when `ProviderManager.SaveMetadata` gets called before
`ProviderManager.AddParts`
```
Error Message:
System.ArgumentNullException : Value cannot be null. (Parameter 'source')
Stack Trace:
at System.Linq.ThrowHelper.ThrowArgumentNullException(ExceptionArgument argument)
at System.Linq.Enumerable.Where[TSource](IEnumerable`1 source, Func`2 predicate)
at MediaBrowser.Providers.Manager.ProviderManager.SaveMetadata(BaseItem item, ItemUpdateType updateType, IEnumerable`1 savers) in D:\a\1\s\MediaBrowser.Providers\Manager\ProviderManager.cs:line 674
at MediaBrowser.Providers.Manager.ProviderManager.SaveMetadata(BaseItem item, ItemUpdateType updateType) in D:\a\1\s\MediaBrowser.Providers\Manager\ProviderManager.cs:line 655
at Emby.Server.Implementations.Library.LibraryManager.RunMetadataSavers(BaseItem item, ItemUpdateType updateReason) in D:\a\1\s\Emby.Server.Implementations\Library\LibraryManager.cs:line 2012
at Emby.Server.Implementations.Library.LibraryManager.UpdateItemsAsync(IReadOnlyList`1 items, BaseItem parent, ItemUpdateType updateReason, CancellationToken cancellationToken) in D:\a\1\s\Emby.Server.Implementations\Library\LibraryManager.cs:line 1970
at Emby.Server.Implementations.Library.LibraryManager.CreateRootFolder() in D:\a\1\s\Emby.Server.Implementations\Library\LibraryManager.cs:line 775
at Emby.Server.Implementations.Library.LibraryManager.get_RootFolder() in D:\a\1\s\Emby.Server.Implementations\Library\LibraryManager.cs:line 180
at Emby.Server.Implementations.IO.LibraryMonitor.Start() in D:\a\1\s\Emby.Server.Implementations\IO\LibraryMonitor.cs:line 135
at Emby.Server.Implementations.IO.LibraryMonitorStartup.RunAsync() in D:\a\1\s\Emby.Server.Implementations\IO\LibraryMonitorStartup.cs:line 26
at Emby.Server.Implementations.ApplicationHost.StartEntryPoints(IEnumerable`1 entryPoints, Boolean isBeforeStartup)+MoveNext() in D:\a\1\s\Emby.Server.Implementations\ApplicationHost.cs:line 541
at System.Threading.Tasks.Task.WhenAll(IEnumerable`1 tasks)
at Emby.Server.Implementations.ApplicationHost.RunStartupTasksAsync(CancellationToken cancellationToken) in D:\a\1\s\Emby.Server.Implementations\ApplicationHost.cs:line 525
at Jellyfin.Server.Integration.Tests.JellyfinApplicationFactory.CreateServer(IWebHostBuilder builder) in D:\a\1\s\tests\Jellyfin.Server.Integration.Tests\JellyfinApplicationFactory.cs:line 101
at Microsoft.AspNetCore.Mvc.Testing.WebApplicationFactory`1.EnsureServer()
at Microsoft.AspNetCore.Mvc.Testing.WebApplicationFactory`1.CreateDefaultClient(DelegatingHandler[] handlers)
at Microsoft.AspNetCore.Mvc.Testing.WebApplicationFactory`1.CreateDefaultClient(Uri baseAddress, DelegatingHandler[] handlers)
at Microsoft.AspNetCore.Mvc.Testing.WebApplicationFactory`1.CreateClient(WebApplicationFactoryClientOptions options)
at Microsoft.AspNetCore.Mvc.Testing.WebApplicationFactory`1.CreateClient()
at Jellyfin.Server.Integration.Tests.OpenApiSpecTests.GetSpec_ReturnsCorrectResponse() in D:\a\1\s\tests\Jellyfin.Server.Integration.Tests\OpenApiSpecTests.cs:line 26
--- End of stack trace from previous location ---
```
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.
