Pausing for more than 60 seconds kills the play session — cannot resume without exiting the player

[brianpooe 2]

On Emby for Apple TV, pausing for longer than about 60 seconds permanently breaks
resume. Pressing play does nothing. The only recovery is to back out of the player
and re-enter the item.

Two things appear to combine:

1. On pause, the Apple TV client immediately POSTs /Sessions/Playing/Stopped for the
   current PlaySessionId, which the server acts on ("Removed playSession").

2. The client then stops sending progress pings, so 60 seconds later the server's
   idle reaper fires ("PlaySession ... has gone idle while playing") and removes the
   session for good. Meanwhile the client loops /Items/<id>/PlaybackInfo with
   StartTimeTicks=0, not the paused position, and never recovers.

This is NOT transcoding- or hardware-related. See the "Things already ruled out"
section below: 9 of 10 affected sessions were direct-stream (video copy) with no
hardware decoder or encoder involved at all.

VERSIONS

Emby Server:  4.9.5.0
Client:       Emby for Apple TV 2.0.9 (1). Also reproduced on 2.0.8 (4).
Device:       Apple TV 4K, tvOS 26.6
              User-Agent: AppleCoreMedia/1.0.0.23L773 (Apple TV; U; CPU OS 26_6
              like Mac OS X; en_us)
Server OS:    Debian in an unprivileged LXC on Proxmox (Linux 7.0.6-2-pve),
              official linuxserver/emby Docker image
Media:        MKV (both h264 and HEVC 10-bit affected). The client cannot Direct
              Play MKV, so every session is HLS, logged as
              TranscodeReasons=ContainerNotSupported

The server is reached through a reverse proxy on the LAN. See "Things already ruled
out" - the client itself sends the Stopped request, so this is not a proxy timeout.

STEPS TO REPRODUCE

1. Play any MKV title from Emby for Apple TV (any title that produces an HLS session
   rather than Direct Play).
2. Pause mid-playback.
3. Wait more than 60 seconds.
4. Press play.

Expected: playback resumes from the paused position.
Actual:   playback does not resume. Backing out of the player and re-entering the
          item is the only way to continue.

Pauses shorter than about 60 seconds resume normally, which is what makes the
60-second boundary so visible.

SERVER LOG - FULL SEQUENCE

Game of Thrones S3E1, item 30853, PlaySessionId eb4fdfc5...
API keys, user IDs and hostname redacted; lines trimmed for width.

17:18:14.762  PlaystateService: POST /emby/Sessions/Playing/Progress
17:18:14.762  SessionManager: Playback progress (Pause) reported by app Emby for
              Apple TV 2.0.9 (1) on Apple TV playing Game of Thrones - S3, Ep1.
              Position: 3194000 ms. PlaySessionId: eb4fdfc5...

              --- client sends Stopped 42 ms after pausing ---

17:18:14.804  PlaystateService: POST /emby/Sessions/Playing/Stopped
17:18:14.804  SessionManager: Playback stopped reported by app Emby for Apple TV
              2.0.9 (1) ... Position: 3194076 ms. PlaySessionId: eb4fdfc5...
              IsPaused: True
17:18:14.804  SessionManager: Removed playSession eb4fdfc5... from session c6f42131...

              --- progress arrives for the session that was just removed ---

17:18:14.814  PlaystateService: POST /emby/Sessions/Playing/Progress
17:18:14.814  SessionManager: Setting _lastPlaySessionId for session c6f42131...
              to eb4fdfc5...
17:18:14.815  SessionManager: Playback progress (Pause) ... Position: 3194076 ms

17:18:14.865  MediaInfoService: POST /emby/Items/30853/PlaybackInfo?...
              &StartTimeTicks=0&IsPlayback...
17:18:18.340  MediaInfoService: POST /emby/Items/30853/PlaybackInfo?...
              &StartTimeTicks=0&IsPlayback...

              --- exactly 60 seconds later ---

17:19:14.815  SessionManager: PlaySession eb4fdfc5... has gone idle while playing
17:19:14.815  SessionManager: Playback stopped reported by app ...
              Position: 3194076 ms. IsPaused: True
17:19:14.815  SessionManager: Removed playSession eb4fdfc5... from session c6f42131...

17:19:18.392  MediaInfoService: POST /emby/Items/30853/PlaybackInfo?...
              &StartTimeTicks=0&IsPlayback...

Two details stand out:

- The PlaybackInfo retries carry StartTimeTicks=0, not the paused position
  (3194076 ms). Even if a new session were established, it would not resume where
  the user paused.

- Between 17:18:14.815 and 17:19:14.815 the client sends no progress pings at all,
  which is what trips the 60-second idle reaper.

THE SAME SESSION REPEATEDLY FAILING TO REATTACH

Love Hard, direct-stream session 8fe401b7..., with the position frozen while the
reaper fires over and over:

20:46:53.381  PlaySession 8fe401b7... has gone idle while playing   Position: 371567 ms
20:48:23.736  PlaySession 8fe401b7... has gone idle while playing   Position: 378048 ms
20:50:03.858  PlaySession 8fe401b7... has gone idle while playing   Position: 378048 ms
20:54:04.961  Playback stopped reported by app ...                  Position: 378048 ms
20:55:04.996  PlaySession 8fe401b7... has gone idle while playing   Position: 378048 ms

THINGS ALREADY RULED OUT

Not hardware transcoding.
Every play session that hit the 60-second reaper was mapped back to its own ffmpeg
log by PlaySessionId:

    PlaySessionId     ffmpeg session type
    ---------------   -------------------
    b09fd03a...       direct stream
    8fe401b7...       direct stream
    0495c2b9...       direct stream
    c8e0f0f9...       direct stream
    fac7c767...       direct stream
    c710f5fe...       direct stream
    42bb9945...       direct stream
    ce82d71a...       direct stream
    9f88e55f...       direct stream
    3741b140...       transcode

Nine of ten never touched the GPU. The processing plan for one of the affected
direct-stream sessions:

    >>>>>>  Processing Plan
            Name                      CanDoInHW  WillDoInHW  Reason
            Copy video stream      >> False      False       Software Codec
            VideoInput             >> False      False       Not a hardware decoder
            VideoOutput            >> False      False       Not a hardware encoder
            Copy video stream      >> False      False       Software Codec

Not the reverse proxy.
The /Sessions/Playing/Stopped request originates from the client and is logged as
"reported by app". The server is honouring a request it was sent, not timing out a
connection.

Not a specific codec or title.
Reproduced across h264 direct-stream and HEVC 10-bit NVENC transcode sessions, on
multiple titles, and under two different user accounts.

Not new in 2.0.9.
"has gone idle while playing" appears in logs from client version 2.0.8 (4) as well.

Not configurable.
There is no exposed setting for the idle timeout in system.xml or encoding.xml.

QUESTIONS FOR THE DEVS

1. Why does the Apple TV client POST /Sessions/Playing/Stopped when the user pauses,
   rather than reporting a paused progress state and continuing to ping?

2. Why do the subsequent PlaybackInfo retries use StartTimeTicks=0 instead of the
   paused position?

3. Should the server's 60-second "gone idle while playing" reaper apply to a session
   the client has explicitly reported as paused? A paused session going quiet seems
   like expected behaviour rather than an abandoned one.

Happy to supply full unredacted server logs, ffmpeg session logs, or a fresh capture
of a deliberate reproduction if that would help.
 

[Luke 42982]

 

Hi there, let's look at an example. Please attach the information requested in how to report a media playback issue. Thanks!