Non-MP4 web links (in STRM file) do not work correctly

[ddurdle]

Describe the bug When accessing a STRM file that contains a MP4 file via the Android TV client, playback is correct and seeking is supported. I can see the client is talking to the web server hosting the STRM file to seek within it (with content-range requests, handling 206 response codes, etc)

When accessing a STRM file that contains a MKV file via the Android TV client, the player is not properly seeking within the file. It only makes a single request to the destination without any content-ranges. Thus, if the file has it's header information at the end of the file, playback won't start until the entire file is downloaded to the player. Likewise, because the player is not behaving correctly, fast forward and seeking is not supported. It never makes the correct content-range requests and, thus, doesn't invoke 206 response codes from the web server.

With the same MKV files, playback via jellyfin-ffmpeg transcoding, via android tv with external player, via KODI, via web, etc, all correctly handle the stream and request the appropriate content-ranges to seek within the file to correctly playback the file. I can see on the server side 206 response codes being delivered back to the client. Thus, fast forward and seeking work as expected.

To Reproduce

1. Create a simple ngnix site hosting 1 sample MP4 and 1 sample MKV file. Create a STRM for each of these files and map these STRM files to a library in JF.
2. Click on the MP4 file in the Android TV app. You will see on the server side ngnix log that the communication to the ngnix is following the expected behaviour with content-ranges and corresponding 206 responses.
3. Click on the MKV file in the Android TV app. You will see on the server side ngnix log that the communication to the ngnix is NOT following the expected behaviour. There are no content-ranges in the requests and corresponding are only 200 responses. Therefore, FF and seeking are not supported, and MKV files that contain the media header information at the end of the file will not start playback until the entire file has downloaded to the player.

Expected behavior With the same MKV files, playback via jellyfin-ffmpeg transcoding, via android tv with external player, via KODI, via web, etc, all correctly handle the stream and request the appropriate content-ranges to seek within the file to correctly playback the file. I can see on the server side 206 response codes being delivered back to the client. Thus, fast forward and seeking work as expected.

Logs n/a

Screenshots n/a

System (please complete the following information):

• Android TV or Fire TV version: Fire 4k TV stick 11.5
• Device manufacturer: Amazon
• Device model: Fire 4k TV stick
• Jellyfin server version: 10.7.1

Additional context n/a

[nielsvanvelzen]

I'm not familiar with strm files but this looks like an issue with the current playback code in general. You could try changing the preferred video player to either LibVLC or ExoPlayer and see if that solves the issue.

[ddurdle]

I will try libVLC. I think it’s using ATV/ExoPlayer by default, as this is where I see the playback calls being made from when looking at the ngnix logs.

On Sunday, March 28, 2021, Niels van Velzen @.***> wrote:

I'm not familiar with strm files but this looks like an issue with the current playback code in general. You could try changing the preferred video player to either LibVLC or ExoPlayer and see if that solves the issue.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/jellyfin/jellyfin-androidtv/issues/794#issuecomment-808863240, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGP4NHXVFRN43AAQ25XXO3TF3WZFANCNFSM4Z5MUL4A .

[ddurdle]

Seems libvlc always forces transcode regardless of the media. Always complains about the framerate.

The media is being converted into a format that is compatible with the device that is playing the media. Framerate: 270fps

4.0 Mbps MKV H264 AAC

Reason for transcoding: RefFramesNotSupported

[ddurdle]

When using libvlc, If I disable the "video encoding" option in the user profile, the transcoding goes to direct streaming with reason being the audio channels is not supported. The video is AAC. If I disable all the transcoding options, the video plays back without issue, including with audio, and it's requesting content-ranges.

So to recap:

With ExoPlayer, it does not falsely think it needs to transcode, but it only properly streams with MP4 STRM files.

With libvlc, it tries to transcode for invalid reasons, but properly streams with all file types.

[stale[bot]]

This issue has gone 120 days without comment. To avoid abandoned issues, it will be closed in 21 days if there are no new comments. If you're the original submitter of this issue, please comment confirming if this issue still affects you in the latest release or master branch, or close the issue if it has been fixed. If you're another user also affected by this bug, please comment confirming so. Either action will remove the stale label. This bot exists to prevent issues from becoming stale and forgotten. Jellyfin is always moving forward, and bugs are often fixed as side effects of other changes. We therefore ask that bug report authors remain vigilant about their issues to ensure they are closed if fixed, or re-confirmed - perhaps with fresh logs or reproduction examples - regularly. If you have any questions you can reach us on Matrix or Social Media.