Jump to content

"Resume" refuses to direct play


Go to solution Solved by Bims0n,

Recommended Posts

Bims0n
Posted

I'm having a bit of an exotic problem with the sideloaded Amazon App (using current version 3.5.24) on my Amazon FireTV Cube 2nd Gen. Occasionally on some high bitrate hevc 4k mkv files the "resume" functionality refuses to work and I get the endless spinning wheel of death. "Start" from the beginning and "chapter select" work flawlessly. This applies only for direct play - transcoding files work in all 3 playback states.

I've counter tested this now on Windows10 with the Emby Store App and the file in question, all 3 states (start, resume, chapter select) work without a problem (direct play). Attached my serverlog with the playback starting from the following timecode:

2026-01-19 17:42:55.985 - 1 x playback with Windows 10 Client
2026-01-19 17:46:18.951 - 1 x playback with Fire TV Cube 2. Gen Client

Also attached the media info (I've used both tracks to test):

image.png.35998b30a4a46885f6f10384f6a17e05.png

 embyserver.txt

visproduction
Posted

Enbyserver.txt

Line 1341

Why is playback for 10.ts failing?

Quote

Accept-Encoding=identity, Range=bytes=8351531893-, Icy-MetaData=1
2026-01-19 17:46:29.179 Info Server: http/1.1 GET http://emby_remote_ip/emby/videos/219509/hls1/main/10.ts?PlaySessionId=aa6d6bbedcab48f38b22e37e55ec05bf. Source Ip: host2, Connection=close, Host=emby_remote_ip, User-Agent=Emby/2.1.23g (Linux;Android 12) ExoPlayerLib/2.18.7, Accept-Encoding=identity, X-Real-IP=host2, X-Forwarded-For=host2, X-Forwarded-Proto=https
2026-01-19 17:46:29.180 Error Server: Error processing request
    *** Error Report ***
    Version: 4.8.11.0
    Command line: /volume1/@appstore/EmbyServer/system/EmbyServer.dll -programdata /var/packages/EmbyServer/var -ffdetect /var/packages/EmbyServer/target/bin/ffdetect -ffmpeg /var/packages/EmbyServer/target/bin/ffmpeg -ffprobe /var/packages/EmbyServer/target/bin/ffprobe -nolocalportconfig -ignore_vaapi_enabled_flag -pidfile /var/packages/EmbyServer/var/EmbyServer.pid -defaultdirectory /volume1/Public -updatepackage emby-server-synology72_{version}_x86_64.spk -noautorunwebapp
    Operating system: Linux version 4.4.302+ (root@build5) (gcc version 12.2.0 (GCC) ) #86009 SMP Wed Nov 26 18:19:17 CST 2025
    Framework: .NET 6.0.36
    OS/Process: x64/x64
    Runtime: volume1/@appstore/EmbyServer/system/System.Private.CoreLib.dll
    Processor count: 4
    Data path: /var/packages/EmbyServer/var
    Application path: /volume1/@appstore/EmbyServer/system
    MediaBrowser.Common.Extensions.ResourceNotFoundException: MediaBrowser.Common.Extensions.ResourceNotFoundException: Exception of type 'MediaBrowser.Common.Extensions.ResourceNotFoundException' was thrown.
       at Emby.Server.MediaEncoding.Api.Hls.BaseHlsService.CreateRequestFromPlaySessionId(BaseSegmentRequest segmentRequest)
       at Emby.Server.MediaEncoding.Api.Hls.DynamicHlsService.Get(GetHlsSegment segmentRequest)
       at Emby.Server.Implementations.Services.ServiceController.Execute(HttpListenerHost appHost, Object requestDto, IRequest req, Type serviceType)
       at Emby.Server.Implementations.Services.ServiceHandler.ProcessRequestAsync(HttpListenerHost httpHost, IServerApplicationHost appHost, IRequest httpReq, IResponse httpRes, IStreamHelper streamHelper, RestPath restPath, String responseContentType, CancellationToken cancellationToken)
       at Emby.Server.Implementations.HttpServer.HttpListenerHost.RequestHandler(IRequest httpReq, ReadOnlyMemory`1 urlString, ReadOnlyMemory`1 localPath, CancellationToken cancellationToken)
    Source: Emby.Server.MediaEncoding
    TargetSite: System.Tuple`3[Emby.Server.MediaEncoding.Api.StreamRequest,System.String,MediaBrowser.Controller.Net.AuthorizationInfo] CreateRequestFromPlaySessionId(Emby.Server.MediaEncoding.Api.Hls.BaseSegmentRequest)
 

===

AI comment on search: https://duckduckgo.com/?q=Media+playback+ResourceNotFoundException&ia=web

Quote

A ResourceNotFoundException during media playback typically indicates that the media file cannot be found or accessed by the application. This can happen if the file path is incorrect or if the file has been moved or deleted.

===

Of interest - from competitor media server info:

Quote

In most cases,4K buffering is due to slow network speed. To stream a typical 4K video at 20 Mbps (bitrate) without buffering from a remote server, you need at least double or more home Internet speed (starting from 40 Mbps). A 4K at 12 Mbps should work with a home Internet of 25-30 Mbps. Directly playing a 4K stream will inevitably consume data usage and bandwidth. 

The closer you are to the server serving the 4K stream, the lower the network latency and delay will be. If your client is on the same LAN, use a Gbit Ethernet (with CAT6 cables) to connect to the server. If you want to use WiFi, you’ll have to optimize the range and avoid interference. When it comes to remote streaming, your ISP will play the biggest role. 

Hope that helps.

Bims0n
Posted (edited)

ad: the device is hardwired (ethernet) and not used remotely, I've also tested the file in question on the olderr "Emby for FireTV" App and there the "resume" function is working properly. Server & bandwith issues can therefore be ruled out in my oppinion, this seems to be client only. So maybe an issue with the Emby Android app?
However I think @visproduction has a point, when checking the log I was also surprised by the "10.ts/resource not found" error and how often it appears in the log.

Edited by Bims0n
typo fix
Posted

Hi, please attach the ffmpeg log as well. Thanks !

Bims0n
Posted

This only happens on direct play, so no ffmpeg-transcode log is available. Unless I have mistaken something.

Bims0n
Posted

@Lukeany ideas on this one? I'm a little bit clueless where to start honestly.

Posted
On 1/20/2026 at 3:35 AM, Bims0n said:

This only happens on direct play, so no ffmpeg-transcode log is available. Unless I have mistaken something.

 

On 1/19/2026 at 2:39 PM, visproduction said:

2026-01-19 17:46:29.179 Info Server: http/1.1 GET http://emby_remote_ip/emby/videos/219509/hls1/main/10.ts?PlaySessionId=aa6d6bbedcab48f38b22e37e55ec05bf. Source Ip: host2, Connection=close, Host=emby_remote_ip, User-Agent=Emby/2.1.23g (Linux;Android 12) ExoPlayerLib/2.18.7, Accept-Encoding=identity, X-Real-IP=host2, X-Forwarded-For=host2, X-Forwarded-Proto=https
2026-01-19 17:46:29.180 Error Server: Error processing request

Is the above not from the item in question?

Have you tried remuxing the item with mkvtoolnix?

Bims0n
Posted

Yes this is from the above mentioned file, I am just as confused as you are. Direct play is mentioned in the "stats for nerds" and the admin dashboard.

Unbenannt.PNG.a0b4fb037ac82a69333204f35fa86844.PNG

Just did a remux with mkvtoolnix without changing any of the audio/subtitle tracks and the result is the same. As soon as I forward/backward the stream, or quit -> resume I just get a freeze (audio sometimes continues). I'm not sure if there is an issue with the .mkv file(s) as the old "Emby for FireTV" App plays the same file on the same client without any issues. The stream takes a little bit longer to load, but apart from that all is fine.

I also tried with the adaptive framerate/resolution settings from the client as this might be an usual culprit in these cases but to no effect.

Posted

Hi, can you try Emby for Android 3.5.28 and see how that compares? Thanks.

Bims0n
Posted

Updated to 3.5.28, was also hoping this would fix it since the patch notes mentions several playback fixes. Unfortunately no change on the result 😕

Posted

OK we'll take another look at it. Thanks.

Bims0n
Posted

If you are in need of the media file or some other information related to this issue feel free to contact via pm!

Thanks!

  • Thanks 1
  • 3 weeks later...
  • Solution
Posted

Small update: I "fixed" it by selecting the "convert unsupported audio to dolby digital" in the playback option on my FireTV client. This does not fix the problem itself with native playback, but it forces transcoding of the audio track into AC3 - wich apparently is good enough for my client to work flawlessly with the whole file in question. Still don't quite understand the whole problem of the scenario but hey, a win is a win.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...