StreamInfo.ToUrl() generated URLs like `/master.m3u8?&DeviceId=...` (note `?&`)
because `?` was appended to the path and all parameters started with `&`. When
the first optional parameter (DeviceProfileId) was null, the result was a
malformed query string.
This is harmless when clients hit Jellyfin directly (ASP.NET Core tolerates `?&`),
but when accessed through a reverse proxy that parses and re-serializes the URL
(e.g. Home Assistant ingress via aiohttp/yarl), `?&` becomes `?=&` — introducing
an empty-key query parameter. ParseStreamOptions then crashes on `param.Key[0]`
with IndexOutOfRangeException.
Changes:
- StreamInfo.ToUrl(): Track query start position and replace the first `&` with
`?` after all parameters are appended, producing valid query strings
- ParseStreamOptions: Guard against empty query parameter keys
- Tests: Remove .Replace("?&", "?") workaround that masked the bug
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The DisplayTitle property was using .NET's CultureInfo.GetCultures(NeutralCultures)
to resolve language display names. Since zh-CN is a specific culture (not neutral),
it would fall back to the base 'zh' code, resulting in generic 'Chinese' instead
of 'Chinese (Simplified)'.
This change adds a LocalizedLanguage property to MediaStream that gets populated
via LocalizationManager.FindLanguageInfo() when streams are retrieved from the
database. This leverages Jellyfin's existing iso6392.txt mappings which correctly
map zh-CN to 'Chinese (Simplified)'.
The same pattern is already used for other localized strings like LocalizedDefault
and LocalizedExternal.
The DisplayTitle property was using .NET's CultureInfo.GetCultures(NeutralCultures)
to resolve language display names. Since zh-CN is a specific culture (not neutral),
it would fall back to the base 'zh' code, resulting in generic 'Chinese' instead
of 'Chinese (Simplified)'.
This change adds a LocalizedLanguage property to MediaStream that gets populated
via LocalizationManager.FindLanguageInfo() when streams are retrieved from the
database. This leverages Jellyfin's existing iso6392.txt mappings which correctly
map zh-CN to 'Chinese (Simplified)'.
The same pattern is already used for other localized strings like LocalizedDefault
and LocalizedExternal.
* Check MaxAudioChannels for directAudioStream candidates
The current stream builder logic does not check the channel limit when determining if the audio stream can be directly used, and this can cause some undesired effects:
- A high channel count surround sound stream might be picked even if a stereo one exists when the user requires stereo audio.
- The user's preferred audio codec might not be respected during the downmix because the requested codec is now forced to be the same as the original source.
Signed-off-by: gnattu <gnattuoc@me.com>
* Fix unit test
Signed-off-by: gnattu <gnattuoc@me.com>
* Set correct transcode reason and target channels for unit test
Signed-off-by: gnattu <gnattuoc@me.com>
* Match old stream selection behavior
Signed-off-by: gnattu <gnattuoc@me.com>
* Fix reason matching
Signed-off-by: gnattu <gnattuoc@me.com>
---------
Signed-off-by: gnattu <gnattuoc@me.com>
* Correct MIME types for comicbook file extensions
cb7, cba, cbr, cbt and cbz all refer to different types of digital
comicbooks. The last letter of the extension indicates the compression
algorithm that was used: 7zip, arc, rar, tar or zip.
All these filetypes used to have the `application/x-cbr` MIME type
assigned to them. However, that has since been deprecated and was
replaced with
- `application/vnd.comicbook-rar` for rar compressed files and
- `application/vnd.comicbook+zip` for rar compressed files.
Only these two are officially listed by IANA
https://www.iana.org/assignments/media-types/application/vnd.comicbook+zip
. cbr and cbz are by far the most common file extensions for comicbooks.
There's no official MIME type for cb7, cba or cbt files. However, with
rar being a proprietary compression algorithm, FOSS applications will
often refuse to handle files that identify themselves as
`application/x-cbr`, so I decided to assign extension specific MIME
types to them. I've seen these being used by other applications,
specifically comic book readers.
I've read through the docs on iana.org, but haven't figured out why they
chose `-rar`, but `+zip`.
* Add conversions from MIME type to file extensions for comicbook formats
cb7, cba, cbr, cbt and cbz all refer to different types of digital
comicbooks. The last letter of the extension indicates the compression
algorithm that was used: 7zip, arc, rar, tar or zip.
All these filetypes used to have the `application/x-cbr` MIME type
assigned to them. However, that has since been deprecated and was
replaced with
- `application/vnd.comicbook-rar` for rar compressed files and
- `application/vnd.comicbook+zip` for rar compressed files.
Only these two are officially listed by IANA
https://www.iana.org/assignments/media-types/application/vnd.comicbook+zip
. cbr and cbz are by far the most common file extensions for comicbooks.
There's no official MIME type for cb7, cba or cbt files. However, with
rar being a proprietary compression algorithm, FOSS applications will
often refuse to handle files that identify themselves as
`application/x-cbr`, so I decided to assign extension specific MIME
types to them. I've seen these being used by other applications,
specifically comic book readers.
* Update CONTRIBUTORS.md
