As a comparison I have the Apple TV, Android TV app and the Windows app.

Apple TV:

Windows App with Sidebar:

Windows app without Sidebar:

Android TV (Fire TV):

When comparing them the Apple TV cuts just way too much from the picture. The Windows App with the Sidebar does it much better. Though it's worse when the Sidebar is closed.

The best approach in my opinion is the Android TV app.

Could we get the Android TV version too?

Also the Spotlight on the Apple TV seems to be endless, while the other 2 are limited to 12 items. 

Missing ABC list in the library side for fast search.

Sometimes the app doesn't load the full library, I have got 1000+ movie in my library, yesterday I'm searching for Moana (in my language it called Vaiana) and the app only shows movies from 0 to L, closing the app then reopen solved this issue, but thats not a long time solution.

Sorry for said that, but I hate the new login method, I have got little kids and for them is too complicated if last time I watched something (changing user) the old method after app opening shows the users, then they choose the correct user and watch what they want

It seems to happen when playback starts for an item, as though the users session expires and it causes a crash.  Something will be playing for a period of time, and then it kicks out and crashes the app.  Whether shuffling TV episodes, or music, etc... it seems to happen during the shuffle and the next item starting to play.

embyserver.txt

I think I found a navigation bug in the Apple TV client related to autoplay.

It’s most noticeable when you fall asleep with Emby running. You wake up, autoplay has gone through several episodes, and now pressing Back makes you step through every single one before you get back to the home screen. Autoplay wasn’t something I chose to navigate to so it shouldn’t be stacking onto the back history the same way a tap would. I haven’t been able to reproduce it on demand but I’ll record it next chance I get.

Expected behaviour: wake up, press Back once, land back in the season/series/continue watching context you started from, press Back again and you’re at the Emby home screen.

This leads to my other bit of feedback around navigation friction more generally. Jumping to earlier episodes or switching seasons when you need to reorient yourself after falling asleep is harder than it should be, and other clients seem to handle it better.

If the Continue Watching screen could work more like a persistent season context, current episode selected (as it does now), previous episodes scrollable to the left, upcoming to the right, and a quick season dropdown, that would make “More…”, “Go To Season”, and “Go To Series” mostly unnecessary for the common cases. 

The best view you have right now for this is actually the Series screen. It has the current episode, watch history, and season navigation all in one place, it’s just buried in a menu if you enter via Continue Watching, and its never loaded into the back history, I'm always taken back to Continue Watching, which hides previous episodes, seasons, series behind added steps. 

The hierarchy is the problem. A unified series/season/episode/continue watching screen would be incredible and you’re already 90% of the way there with what exists in the season view. This is how most clients seem to handle this, every episode, season is a tap away rather than an extra menu, then tap. 

To give a better example, I was binge watching the Top Gear specials last night which are scattered across seasons. The amount of Continue Watching, Go To Series, Season 4, Find The episode, Back, Go To Series, Season 5 back and forth was the definition of UI friction.

Really appreciate all the hard work that goes into Emby, just trying to bring up a few pain points I find while using the app. I could be completely alone here and people may like the hidden history and buried navigation, but just thought I bring it up.

Thank you, Garrett

I am in a library and i want to delete a movie, i click the movie, then 3 clicks to get to the more menu, one click to enter the more menu, 5 clicks to get down to Delete, one click to get delete menu, down click to select delete, then click on delete, then click back to get to library.

14 clicks to delete a movie, this make emy unusable for any sort of library tidy or management. God forbid you want to delete a handful of videos, you'll drain the remote battery. Did no one even test using the app?

Changes

2.0.9.0

• Fix scroll problem on collection screen

Could we get regular themes to choose from within the app itself? The same ones you can choose on the Android app like Dark, Light, Blue Radiance or even the Apple TV Theme.

Any possibility of this?

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.
 

Here's a recording 

The topic remains locked. Please create your own topics or reply to the individual release posts.

Changes

2.0.8.0

• Update app icon
• Add group by to collection screen
• Show resume button if next up episode is resumable
• Improve video playback error handling
• Support A-Z picker on list screens
• Fix remove from resume context menu option

After some trying and working with ChatGPT on the issue I found a solution. I downloaded the "Diagnostics Options" plugin and found out that when I unticked "Disable Subtitle Filtering", the burn-in request is being processed correctly and a working transcoded stream is sent to Infuse. 

I reason it's just a workaround and not a true solution is that burn-in can lead to unintended results. I've seen files where subtitles were absurdly huge and others where they were not burned in at all. Therefore the only real solution has to come from the Infuse devs to not work with burned in subtitles but rather use HLS/WebVTT subtitles. I will send a report/request to FireCore.

I hope this helps other Infuse users. 

Here is a recording of what I mean:

It would be great if we could play the actual highlighted item.

This works for Intro but not for credits. 

When playing the same file on the phone it will show up.

But not on apple tv

I could not find any settings regarding this.

Did I miss something or is it not available on apple tv?

Thanks!

I recently bought a new HomePod Mini, connected it to my Apple TV and everything worked fine, for all apps.

But when I decided to watch some episodes in Emby on my Apple TV, I saw a change. Emby was very laggy when interacting with Emby during an episode (Moving forward, moving back, pausing and resuming the episode, pressing the button « Next episode »).

I reinstalled Emby, on both my server and the Apple TV, but the issue was still present. I also tried to use « Native » player instead of « Auto » (default) but it did not change anything.

After digging a bit the forum, some users met the same issue but I haven’t found any way to resolve it.

I finally decided to change the audio source in my Apple Tv settings, from my HomePod to my TV speakers, and the issue is not present when I use my TV speakers, and it comes back when using back my HomePod speaker.

Is this issue known by Emby ? If not, can we try to find a solution to ensure HomePods are working with Apple TV as an audio speaker ?

Thanks by advance.

I've been using Emby on a Apple TV 4K (2nd generation) for several months.  Sporadically, I experience crashes when starting a stream whether it be from stored content or Live TV content.  I cannot determine any pattern to when the app crash will happen - only that it happens at the start of the streaming session.  The Emby app completely closes and then I can go in and start the same movie or live TV channel again and it will work fine.  I'm currently running the latest Apple TV client and the latest server beta, but it also occurs on the latest stable server release.  I'm happy to help get to the bottom of this.  Below is the server log for a live TV stream as the client crashed.  My guess is that it isn't very helpful other than indicating that the server lost communication with the client.  Very much appreciate any help.

2026-08-09 11:05:24.638 Info PlaystateService-0HNNLNV55GBC2:00000006: http/1.1 POST http://host1:8096/emby/Sessions/Playing?X-Emby-Client=Emby for Apple TV&X-Emby-Device-Name=Apple TV&X-Emby-Device-Id=0B2265F9-14D4-4C09-ACD4-7E56068C0F71&X-Emby-Client-Version=2.0.7 (1)&X-Emby-Token=x_secret8_x&reqformat=json. Source Ip: host5, UserAgent: Emby/1 CFNetwork/3860.700.1 Darwin/25.6.0
2026-08-09 11:05:24.640 Info SessionManager: Playback start reported by app Emby for Apple TV 2.0.7 (1) on Apple TV playing ESPNU. Position: 0 ms. PlaySessionId: df77545def4943ef9a4926a21c7eb2d0. IsPaused: False
2026-08-09 11:05:24.641 Info PlaystateService-0HNNLNV55GBC2:00000006: http/1.1 Response 204 to host5. Time: 3ms. POST http://host1:8096/emby/Sessions/Playing?X-Emby-Client=Emby for Apple TV&X-Emby-Device-Name=Apple TV&X-Emby-Device-Id=0B2265F9-14D4-4C09-ACD4-7E56068C0F71&X-Emby-Client-Version=2.0.7 (1)&X-Emby-Token=x_secret8_x&reqformat=json. 
2026-08-09 11:05:24.645 Info PlaystateService-0HNNLNV55GBCB:00000001: http/1.1 POST http://host1:8096/emby/Sessions/Playing/Progress?X-Emby-Client=Emby for Apple TV&X-Emby-Device-Name=Apple TV&X-Emby-Device-Id=0B2265F9-14D4-4C09-ACD4-7E56068C0F71&X-Emby-Client-Version=2.0.7 (1)&X-Emby-Token=x_secret8_x&reqformat=json. Source Ip: host5, UserAgent: Emby/1 CFNetwork/3860.700.1 Darwin/25.6.0
2026-08-09 11:05:24.646 Info PlaystateService-0HNNLNV55GBCB:00000001: http/1.1 Response 204 to host5. Time: 2ms. POST http://host1:8096/emby/Sessions/Playing/Progress?X-Emby-Client=Emby for Apple TV&X-Emby-Device-Name=Apple TV&X-Emby-Device-Id=0B2265F9-14D4-4C09-ACD4-7E56068C0F71&X-Emby-Client-Version=2.0.7 (1)&X-Emby-Token=x_secret8_x&reqformat=json. 
2026-08-09 11:05:24.729 Info VideoService-0HNNLNV55GBC9:00000001: http/1.1 Response completed after client disconnected to host5. Time: 2887ms. GET http://host1:8096/emby/videos/80653399/original.mpegts?DeviceId=0B2265F9-14D4-4C09-ACD4-7E56068C0F71&MediaSourceId=xtream_live_1826_2c8d8ff1d88548899d8d2a234471098f&PlaySessionId=df77545def4943ef9a4926a21c7eb2d0&api_key=x_secret8_x&LiveStreamId=06044cf0e6f93cdae5f285c9ecfaaeb4_01413a525b3a9622ce6fdf19f7dde354_xtream_live_1826_2c8d8ff1d88548899d8d2a234471098f. Headers: Connection=close, Content-Type=video/mp2t, Date=Sun, 09 Aug 2026 15:05:23 GMT, Server=UPnP/1.0 DLNADOC/1.50, Transfer-Encoding=chunked, Cross-Origin-Resource-Policy=cross-origin, Private-Network-Access-Name=K Media, Private-Network-Access-Id=ae879ea1032e468a8c897afa1c2d5ae6
2026-08-09 11:06:24.645 Info SessionManager: PlaySession df77545def4943ef9a4926a21c7eb2d0 has gone idle while playing
2026-08-09 11:06:24.645 Info SessionManager: Playback stopped reported by app Emby for Apple TV 2.0.7 (1) on Apple TV playing ESPNU. Position: 58999 ms. PlaySessionId: df77545def4943ef9a4926a21c7eb2d0. IsPaused: False
2026-08-09 11:06:24.646 Info MediaSourceManager: Closing live stream 06044cf0e6f93cdae5f285c9ecfaaeb4_01413a525b3a9622ce6fdf19f7dde354_xtream_live_1826_2c8d8ff1d88548899d8d2a234471098f
2026-08-09 11:06:24.646 Info MediaSourceManager: Live stream 06044cf0e6f93cdae5f285c9ecfaaeb4_01413a525b3a9622ce6fdf19f7dde354_xtream_live_1826_2c8d8ff1d88548899d8d2a234471098f closed successfully
2026-08-09 11:06:24.646 Info SessionManager: Removed playSession df77545def4943ef9a4926a21c7eb2d0 from session f5a2397d7f582e0d2b96d2d4f96fcfc9

I remember that if you had started an episode of a TV show/series and had not yet finished it the default option upon selecting the series from the TV library (Home screen > TV Shows for example) the default option presented would be to resume the partially watched episode. Instead I am presented with "Play Up Next" which instead of resuming the partially watched episode starts it from the beginning. 

I can get to the resume option but the flow is longer:

Home Screen > Tv Shows > {select show} > (scroll down to the "Next Up" list} > Select the show with a partial progress bar > Finally select "Resume from ..."

Where I thought the flow used to be:

Home Screen > Tv Shows > {select show} > Select "Resume."

If it makes any difference the Emby app on the AppleTV shows version 2.0.7 (1) and the server is version 4.9.5.0 running on linux. 

The channels are too big on the guideline, and we can't filter by tags as we do on Roku. 

I'm not interested in live TV. Yet, this is front and center and can't be removed.