All Activity

After the next stable is out do we actually get to see (the beginnings of) TVNext ?

Those rows you're showing - Apple, HBO etc, are they custom rows you've made in Emby that this app is picking up, or are they something this app is creating itself ?

Yes, I’ve been wanting something like this for a while too. I suppose seeing just (e.g.) MP3 or FLAC is a good minimal approach for many, but all my music is FLAC. I therefore also want to see (e.g.) 16/44 or 24/96, at a glance, without having to open “Stats for Nerds” or leave that visible the whole time. Even then, this doesn’t show bit-depth in the available info. I also similarly want to see more relevant info like this, but don’t need to see “everything” to be able to easily determine if the track is “standard” or “hi-res”. So, rather than just waiting for Emby to implement something, I had a friendly AI conversation and ended up with this (full screen): Here’s the JavaScript code for anyone interested in experimenting with it, for the web player (at your own risk): (function() { async function updateAudioInfo() { try { const sessions = await window.ApiClient.getSessions(); const session = sessions?.find(s => s.NowPlayingItem); if (!session) return; const item = session.NowPlayingItem; const audio = item.MediaStreams?.find(s => s.Type === "Audio"); if (!audio) return; const codec = (audio.Codec || "").toUpperCase(); const bitDepth = audio.BitDepth || ""; const sampleRate = audio.SampleRate ? (audio.SampleRate / 1000).toFixed(1) : ""; const el = document.querySelector('.videoOsd-audioInfo .mediaInfoItem'); if (el) el.textContent = `${codec} • ${bitDepth}-bit • ${sampleRate} kHz`; } catch (e) { console.error("Error:", e); } } const obs = new MutationObserver(updateAudioInfo); obs.observe(document.body, { childList: true, subtree: true }); })(); I have no idea if this is optimum code, but it seems to work ok for me. Alter this line to change the format of the data: if (el) el.textContent = `${codec} • ${bitDepth}-bit • ${sampleRate} kHz`; To show other data will require more extensive changes, of course. Depending upon screen size size, aspect ratio, screen view, font-size, etc., some CSS finessing may also be required to adjust any misalignment due to the extra space that the additional info takes up. I found that the text-centering may not align well and the time-remaining may wrap to the next line, but it seems fine, with no tweaking, for a landscape view., on my set-up. While this won't help for all the client apps, perhaps it's still useful to some, as an interim approach, for the web player?

Yeah so I made another small video of what it is like with faster settings and main screen with no audio until you click a movie or show you like as you will see at the end of this small video. 2026-07-26 21-53-25.mp4

I suppose that is possible, and maybe if the devs see this, they will check it out. Either way, one would think that sometime within the last 2+ years, they would have fixed this.

We have been waiting for this for over a decade so don’t hold your breath that we will ever get it. 4 years ago we were teased there is a developer that made it search for nexttv but it looks like it has all been canned unfortunately . I am still waiting for my tv recording virw to be restored back

Yeah, you can disable the auto trailers or you also can have it muted so you see the trailer but can't hear it or set it to play the audio only after you click a movie you wanna watch then after a few seconds it will play a high quality full screen trailer until you back out of it. Loads of features i wish emby already had but whatever..

Looks pretty good. It has way less padding than the official Emby app which has also been a complaint of mine. The autoplay trailers within the card is pretty neat too, not sure that I'd use it though.

Also you can use StreamBridge to connect your emby server to it and it will load your emby library into the front end and use imdb to display trailers and metadata, pretty cool just sayen. Be cooler if emby app had this so people dont need go looking for 3rd party apps.

This a small video I made of how it looks as my front end when connected to emby server. 2026-07-26 20-47-40.mp4

hi team, i spent some time looking into why my emby server sometimes leaves ffmpeg processes pegging 100% of a core post-playback, and i figured out why and how to fix it (it's already fixed upstream). it seems that this occurs when ffmpeg seeks beyond the start of the last cue of the subtitle track. if a video is 1 minute long, but the subtitles end 30 seconds in, and you seek to 31 seconds, this will cause the process to remain, and spin its wheels. in fact, it occurs on any filtered subtitle output that receives zero frames; i reproduced it with a sparse forced track and a seek to a point in the first half of a video. looking at https://mediabrowser.github.io/embytools/ffmpeg-2023_06_25-u1.tar.gz i can see that this is due to the emby patches on top of ffmpeg. in fftools/ffmpeg_filter.c:758 is this comment: if (ist->st->codecpar->codec_type == AVMEDIA_TYPE_SUBTITLE && ist->dec_ctx) { // For subtitles, we need to set the format here. Would we leave the format // at -1, it would delay processing (ifilter_has_all_input_formats()) until // the first subtile frame arrives, which could never happen in the worst case ifilter->format = (uint16_t)ist->dec_ctx->subtitle_type; } so emby presets the format so a subtitle graph configures with zero frames, which breaks the invariant that early return was written against - af1761f7b5 - "init filtergraphs only after we have a frame on each input". this means choose_output() can select this output stream that is already finished as is seen in fftools/ffmpeg.c:3855: static OutputStream *choose_output(void) { for (i = 0; i < nb_output_streams; i++) { OutputStream *ost = output_streams[i]; ... if (!ost->initialized && !ost->inputs_done) return ost->unavailable ? NULL : ost; if (!ost->finished && opts < opts_min) { opts_min = opts; ost_min = ost->unavailable ? NULL : ost; } } return ost_min; } inputs_done is never set for a configured graph, and a subtitle sink with zero frames never sets initialized either. both flags stay 0 permanently so choose_output()'s early return fires forever, resulting in a livelock. emby tries to send "q" to ffmpeg's stdin to gracefully shut it down, but it never acts on it due to the livelock, so the process just spins its wheels forever. the fix is to extend the test for the return: if (!ost->initialized && !ost->inputs_done && !ost->finished) this is probably best done by cherry picking e1d12aaa45 onto the 5.1-emby source you could also harden this in reap_filters() in fftools/ffmpeg.c:1522: } else if (flush && ret == AVERROR_EOF) { if (av_buffersink_get_type(filter) == AVMEDIA_TYPE_VIDEO) do_video_out(of, ost, NULL); else init_output_stream_wrapper(ost, NULL, 1); } that's pretty much the whole story. i see that there are other posts likely about this as well. also, i can't seem to find the p6 version source for ffmpeg, could you please point me towards it?

Hi, I'd like to suggest adding server-side control over some client experience settings across Emby clients, specifically: Play theme songs Play theme videos Enable backdrops These settings are currently controlled individually on each client (Windows, Mobile, Tablet, TV apps, etc.). While this is useful for personal preferences, it creates a challenge for server administrators who want to provide a consistent experience for their users. For example, an administrator may spend time setting up theme songs, theme videos, and custom backdrops to make the library feel more immersive. However, users may never enable these options, may not know they exist, or may accidentally disable them and not know how to restore the experience. Suggested feature: Add a server-side "Client Experience Settings" section where the administrator can manage how these options behave across connected clients. Option 1: Default "on" The server provides preferred settings when a client connects for the first time. Users can still change them locally if they want. Option 2: Enable/Disable control The administrator can allow or disable certain features across clients. This helps users enable features they may not know about. It also allows administrators to disable features if they become a performance concern. Option 3: Reset client settings Allow the administrator to restore client settings back to the server-defined defaults. This would be especially useful for family/friends servers where the administrator manages the entire experience and users are not expected to configure advanced settings themselves. The goal is not to remove user choice, but to give server administrators better control over the intended media experience across all Emby clients. Thanks!

Are you the same guy from efnet the other night talking about releasing something for trailers on here? Looks cool BTW.

joining in this discussion as well since i would be very interested in having this feature made available..

One of the better shows

Yes it is just a front end, only part I like is the trailers and animation it looks very nice. Basically just a 3rd party app that can be used to watch your emby library among other stuff.

And so do Android TV and Roku.

There's no sense in which this would be even remotely true. It's a complicated subject. First of all, there are no fixed intervals - not even approximately. Then there are diffent generations and differnet kinds of objects (short-lived, long lived and in-betweern). The best assumption you can make about garbage collection is that your assumptions are likely wrong. It also happens rather rarely that .net allocations are not being releases for long durations The second best assumption you should make is that whenever there's a memory problem, the garbage collector is the least likely cause. There are multiple levels in the game. The garbage collector releases managed objects and their memory, But this doesn't directly free application memory. .NET allocates larger blocks of native memory and uses this for its own memory management, except for large objects - for which it has the "large object heap" - this is being treates differently, with the goal to free the native memory more early, when it's no longer used. Under normal operation (with sufficient native memory available), all this is done in a rather "lazy" way. Better keep already allocated memory because it might be needed again in a moment, so rather not free it. All these things change when there's memory pressure, signaled by the system: the gatbage collector is working more eagerly and on shorter notice and kicking out unneded allocations pro-actively. Also memory allocations are de-fragmented if necessary to have more contiguous blocks which can be freed. And something similar also happens at the native side, because there's once another virtualization of memory space, and here again (in the case the OS), memory that has been freed by the application is being actually made available for use by other processes, and only then you will see the process' memory usage drop. Finally, the total memory being used by Emby Server is not all just .NET memory. There's also quite an amount of native memory being allocated directly by various components, biggest consumer in the area being the SQLite client and its caches. It's complicated (see the part about 'assumptions' above)

Can you please do a new test? Enable debug logging, then restart the server and play one movie or show that you knows has the problem, then please post the logs from that session? Thanks.

I sometimes get what might be the same problem with Emby on my shield connected to an AVR. I believe the problem lies in the AVR or TV somehow having problems with the Shield changing resolution/hz and then takes a long time to recover. Disconnecting the Shield for a couple of seconds, rebooting the shield and/or AVR usually helps.

Hi iPhone HEVC (.MOV) videos containing a Rotation 180 deg metadata tag play upside down in both the Emby Web Client and the Samsung TV app. The same files play with the correct orientation in Windows Media Player/Explorer, and Emby generates thumbnails in the correct orientation. This suggests the rotation metadata is being interpreted correctly during thumbnail generation but not during playback. Is this a known issue with QuickTime rotation metadata (Rotation 180 deg), and is there a server or FFmpeg setting to honour it during playback? Emby 4.10.0.20 beta on DSM 7.4 Thank you

One of the next betas for the Windows, Xbox and Linux apps will have this as an experimental feature. The WMC UI apps already have it, btw.

If this matters: Emby stopped working sometime shortly after I purchased Emby Premiere and put in my license key. we did just now try the option to “Restart Server” on the Mac app, and now it appears to be back. Is that all we needed to do?

Hi Luke, Thanks for taking a look. Here are the logs capturing the behavior. In this example, when a recording attempt fails due to an upstream proxy/tuner returning a 503 Service Unavailable, Emby immediately enters a hardcoded 60-second retry loop, which can cause resource contention with external gateways: 2026-07-26 13:20:03.812 Info LiveTV: Opening live stream for recording from channel [Redacted Channel] to [Redacted GUID] [Redacted Path]/[Redacted Program].ts 2026-07-26 13:20:03.812 Info LiveTvManager: Opening channel stream, external channel Id: [Redacted ID] 2026-07-26 13:20:03.822 Info HttpClient: Http response 503 from http://[Redacted IP]:5004/x_path1_x/x_path7_x after 9ms. Headers Server=BaseHTTP/0.6 Python/3.14.2, Date=Sun, 26 Jul 2026 20:20:03 GMT 2026-07-26 13:20:03.824 Error MediaSourceManager: Error opening live stream MediaBrowser.Model.Net.HttpException: MediaBrowser.Model.Net.HttpException: ServiceUnavailable at Emby.LiveTV.EmbyTV.GetChannelStreamWithDirectStreamProvider(...) at Emby.Server.Implementations.Library.MediaSourceManager.OpenLiveStreamInternal2(...) 2026-07-26 13:20:03.830 Error LiveTV: Error recording to [Redacted GUID] [...] 2026-07-26 13:20:03.830 Info LiveTV: Retrying recording in 60 seconds. 2026-07-26 13:20:03.861 Info LiveTV: Creating recording timer for [Redacted GUID], [Redacted Program] As you can see, it forces the subsequent retry precisely 60 seconds later. Having a toggle or adjustable backoff for these tuner failure retries would prevent these aggressive handshake loops from locking up custom proxy setups. Let me know if you need any further details!

Can you provide the server and any transcode logs to assist the devs?