All Activity

Took a while with Chatgpt but got it fixed. Some folders were full like transcoding was like using most of the space so AI guided me to fix this at least for now

This is a really helpful pointer. This issue arose just before i went on holiday on the 1st of April, and I don't have those logs any more. I've just updated all the permissions and I'm running a few things as a trial run. Hopefully this will work! Big thanks to both.

That first embyserver.txt is when I first noticed it. I just checked from a completely different network and it looks the same. Here's the current log. embyserver.txt

#1 Blur on the header is an all or nothing sort of thing. Maybe try playing around or add a new variable here to find a neutral ground. /* --- EFFECTS & ANIMATIONS --- */ --blur-light: blur(10px); /* Soft background blur */ --blur-heavy: blur(20px); /* Strong background blur */ --blur-extreme: blur(30px); /* Maximum depth blur */ #2 I'm curious because your display looks a LOT different than mine. Mine shows the seasons in a row, and your buttons look different. are you using extensions or maybe some plugin that makes it look differently? What web browser are you using? I'm curious because I've never seen that. #3 There is no way I know of how to accomplish that, maybe some sort of plugin can do that. But nothing as far as I'm aware. #4 When in a season a season view (clicking on the Series from the screenshot above, it is vertical when it displays the episodes. (see image below)) but if you go into an episode, it lists the episodes vertically. as seen below. As far as my CSS I'm not really going to change that behavior. Major lift and shifts of elements is not something I'm trying to do.

Yes, it will update just like other plugins in the catalog. Will still require a reboot of the server ofc. Edit: You will need to install it from the catalog before it will automatically update. Having the dll manually installed is not enough.

Hi @Aaronelderwe are working on getting a windows app update out that should help improve the download feature with it. Thanks. @softworkz @sa2000

Did you go through the checklist and did you spot the one about having two emby servers on the local network?

@SamES

WOOOOOWWW nice! thx a lot to you and @ebr! So when an update drops is the plugin updated automatically? P.S.: using EmbyServer on Linux in an Unraid docker.

Ich schätze, dass Ryo Saeba genau die richtige Frage gestellt hat. Durch deine Ordnerstruktur in Kombinationen mit den gemischten Inhalten werden manche Filme wohl als Serien oder Episoden von Serien gematcht. Verwende am besten nfo Dateien zum Speichern der Metadaten, so dass korrekte Matches erhalten bleiben. Eventuell hilft es, eine neue Filme Library zu erstellen, und diese die Metadaten korrekt für deinen Filmeteil matchen zu lassen. Initial könntest du auch mit z.b. mit Tiny Media Manager die Ordner+Filme korrekt mit nfos für Emby versehen lassen. Deine Extras kannst du in entsprechende Unterordner wie trailers verschieben, siehe Emby Doku, so dass sie ignoriert werden, TMM bietet auch eine Option, Ordner beim Scan auszuschließen.

I have managed to get access on my phone and shield TV on my local network. Stuck at trying to access it at my work. Sky broadband is a bit of a nightmare for port forwarding. Is this the correct method in the photo below? I am back on shift next week so I can try access it again on my tablet.

Hi, yes this is the most common reason for conversions taking up a lot of disk space.

Your wish has come true. Ebr was so nice as to give me an ID so i could put this and EmbyIcons in the catalog. EmbyCredits is now in the catalog under metadata.

hi, what metadata and image fetchers do you have enabled on the library?

Udpates to beta version to protect images: https://emby.media/community/topic/128420-unauthenticated-access-to-images-by-itemid/page/6/#findComment-1514783

Hi! I am running 4.9.3.0 and this just started happening. Any suggestions? Thanks

@amck24has this helped?

Thanks again for the great work. No glitches or issues have been detected so far, but I'd like to clarify a few details. 1. Is it possible to make the blur disappear after scrolling to the top of the page, as is the default. So, when we scroll the page, the header remains blurred, but when we scroll all the way up, it disappears? (Screenshot 1) 2. Currently, when a show has multiple seasons, they are selected via a drop-down list. Is it possible to make this selection like it is in the TV version, in a row (screenshot 2)? 3. This question is more for the EMBY developers, but I'll ask anyway, maybe you know a solution. Is there a way or possibility to add aliases for movie titles and place them, say, under the main title, so that in addition to the localized title, the original and alternate titles are displayed? 4. This question is more for the developers, but is it possible to display episodes not through horizontal scrolling but through vertical scrolling, as is already done, for example, on the home screen? (Screenshot 3)

Conversions should not fill up the space unless there's a problem with the job or a bug. Each file that's converted is copied back into the library based on the settings (replace or new version) and the temporary work file should be deleted. If there's a problem copying the file back then work files could be left behind. Usually because the library folder (directory) or the source media file itself have the wrong ownership and/or permissions that keep Emby from creating or overwriting. Other problems or failures during conversion could also leave files behind. The activity should be logged along with possible errors. Enable debugging to get more detail in the logs.

This is exactly the kind of issue that has been plaguing Emby for years, yet it continues to be ignored and downplayed. At this point it's clearly not just isolated edge cases, there’s a fundamental problem with Emby's architecture when it comes to user permissions. Emby has never treated user data leakage as a serious security issue. On multiple occasions, the developers have spent more time arguing semantics than actually addressing the problem. When issues like this come up they might eventually get fixed, but rarely in a reasonable timeframe, and not consistently, with many others left unresolved. If users can access directories they were never granted access to, that's a fundamental security failure. Expecting privacy or proper user isolation in Emby at this point is wishful thinking. The developers have shown time and time again that this just isn't a priority and it clearly never will be. The issue isn't just the bugs, it's the refusal to treat them like they matter. If you'd like to see some more examples of these leaks, here's just a few... https://emby.media/community/index.php?/topic/128420-unauthenticated-access-to-images-by-itemid/&do=findComment&comment=1401206 https://emby.media/community/index.php?/topic/145821-bug-parental-control-tag-restrictions-do-not-hide-tagged-items-from-restricted-users/ https://emby.media/community/index.php?/topic/144179-security-issue-using-home-button-makes-pin-bypass-possible/&do=findComment&comment=1499952 https://emby.media/community/index.php?/topic/145761-just-discovered-a-potentially-horrifying-problem/ https://emby.media/community/index.php?/topic/131295-leaking-inaccessible-music-info-to-other-users/&do=findComment&comment=1378489

I don't think that's the problem in my case. I still see 400 Bad Request replies from Trakt in my Emby log files the Export Library to Trakt job: 2026-04-17 02:23:36.650 Info TaskManager: Executing Export Library to Trakt 2026-04-17 02:23:36.651 Info Trakt: Syncing user data for USER 2026-04-17 02:23:37.852 Info HttpClient: POST https://api.trakt.tv/oauth/token 2026-04-17 02:23:37.979 Info HttpClient: Http response 400 from https://api.trakt.tv/oauth/token after 128ms 2026-04-17 02:23:37.983 Error Trakt: Error in SyncUserData *** Error Report *** Version: 4.9.3.0 Command line: /system/EmbyServer.dll -programdata /config -ffdetect /bin/ffdetect -ffmpeg /bin/ffmpeg -ffprobe /bin/ffprobe -restartexitcode 3 Operating system: Linux version 5.15.0-130-generic (buildd@lcy02-amd64-062) (gcc (Ubuntu 9.4.0-1ubuntu1~20.04.2) 9.4.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #140~20.0 OS/Process: x64/x64 Framework: .NET 8.0.22 Runtime: system/System.Private.CoreLib.dll Processor count: 8 Data path: /config Application path: /system MediaBrowser.Model.Net.HttpException: MediaBrowser.Model.Net.HttpException: BadRequest at Emby.Server.Implementations.HttpClientManager.CoreHttpClientManager.SendAsyncInternal(HttpRequestOptions options, String httpMethod) at Emby.Server.Implementations.HttpClientManager.CoreHttpClientManager.SendAsync(HttpRequestOptions options, String httpMethod) at Trakt.Api.TraktApi.GetResponseFromTrakt(HttpRequestOptions options, String method, CancellationToken cancellationToken) at Trakt.Api.TraktApi.PostToTrakt(String url, Object data, TraktUser traktUser, CancellationToken cancellationToken) at Trakt.Api.TraktApi.RefreshUserAuth(TraktUser traktUser, CancellationToken cancellationToken) at Trakt.Api.TraktApi.SetRequestHeaders(HttpRequestOptions options, TraktUser traktUser, CancellationToken cancellationToken) at Trakt.Api.TraktApi.GetFromTrakt[T](String url, TraktUser traktUser, CancellationToken cancellationToken) at Trakt.ScheduledTasks.TraktUserSync.SyncMovies(User user, TraktUser traktUser, TraktApi traktApi, ISplittableProgress`1 progress, CancellationToken cancellationToken) at Trakt.ScheduledTasks.TraktUserSync.SyncUserData(User user, TraktUser traktUser, TraktApi traktApi, ISplittableProgress`1 progress, CancellationToken cancellationToken) at Trakt.ScheduledTasks.SyncLibrary.Execute(CancellationToken cancellationToken, IProgress`1 progress) Source: Emby.Server.Implementations TargetSite: Void MoveNext() which would also explain why the job finishes is just 3 seconds. I also see the same 400 Bad Request response when Emby tries to tell Trakt that a single episode was watched: 2026-04-16 06:23:36.153 Info Trakt: 1 Episode Adds to Process 2026-04-16 06:23:37.353 Info HttpClient: POST https://api.trakt.tv/oauth/token 2026-04-16 06:23:37.442 Info HttpClient: Http response 400 from https://api.trakt.tv/oauth/token after 89ms 2026-04-16 06:23:37.446 Error Trakt: Exception handled processing queued episode events MediaBrowser.Model.Net.HttpException: MediaBrowser.Model.Net.HttpException: BadRequest and: 2026-04-16 20:54:14.530 Info Trakt: Item Not fully played. Tell trakt.tv we are no longer watching but don't scrobble 2026-04-16 20:54:15.729 Info HttpClient: POST https://api.trakt.tv/oauth/token 2026-04-16 20:54:15.879 Info HttpClient: Http response 400 from https://api.trakt.tv/oauth/token after 149ms 2026-04-16 20:54:15.883 Error Trakt: Error sending scrobble MediaBrowser.Model.Net.HttpException: MediaBrowser.Model.Net.HttpException: BadRequest Notice these are not 429 Rate Limit Exceeded responses, which is what the Trakt API returns in such situations.

What plugins are you referring to?

Nice to hear! v2.5.0 is not a 100% complete version, think of it as beta as iI'm still working on some stuff in it. Just didn't feel like fixing the old version and then this as well. All the important bits should work as they should.

2.5.0 configuration pages seem to be working with reverse proxy. I have yet to see Tracer do anything, but I have other priorities now. Thank you

I first spoke about this bug on a thread in the Linux page and have just gotten around to raising this as a bug report on GitHub, though I'm not sure how actively that's monitored. Posting here as well in case it's a better route to the right people, like @Luke --- Environment Emby Server: 4.9.3.0 OS: Ubuntu Server 24.04 LTS Hardware: Intel i5-12500, Intel UHD 770 (VAAPI / QuickSync) IPTV source: ErsatzTV 26.3.0 (Docker), HLS Segmenter mode Client: Emby for Android 3.5.28 --- What's happening When playing a Live TV channel via an HLS/IPTV source, Emby detects a significantly inflated stream bitrate and triggers ContainerBitrateExceedsLimit, forcing unnecessary transcoding of a stream that should be eligible for direct play. ErsatzTV is configured to encode at 1200 kbps video + 128 kbps audio (~1.33 Mbps total). The HLS manifest advertises a correct BANDWIDTH= value consistent with this. However, Emby's Live TV pipeline detects the stream at 4,192,000 bps (~4.2 Mbps) - more than 3x the actual encode bitrate. From the transcoding logs, Emby is summing bitrate values read from the probed TS stream headers: Video stream: BitRate 4,000,000 Audio stream: BitRate 192,000 Container total: Bitrate 4,192,000 These values do not reflect the actual encode settings. Emby appears to be trusting stream-level header metadata from the probed TS segments rather than the BANDWIDTH= value advertised in the HLS manifest. --- Steps to reproduce 1. Add an HLS-based M3U source to Emby Live TV (e.g. ErsatzTV configured to encode at ~1.2 Mbps) 2. Set the client's streaming bitrate above the actual encode bitrate but below ~4.2 Mbps 3. Play a Live TV channel 4. Observe ContainerBitrateExceedsLimit in the transcoding log and transcoding being initiated despite the stream being within the client's stated limit --- Expected behaviour Emby uses the BANDWIDTH= value from the HLS manifest to determine the stream bitrate. A ~1.33 Mbps stream should direct-play when the client bitrate limit is set above that value. --- Actual behaviour Emby probes the TS segment headers and reads a bitrate of ~4.2 Mbps regardless of the actual encode bitrate or the BANDWIDTH= value in the HLS manifest. ContainerBitrateExceedsLimit is triggered even when the client limit far exceeds the true stream bitrate. --- Log evidence Two separate sessions confirm the same behaviour: Session 1 — client bitrate limit set to 3,808,000 bps: Detected container bitrate: 4,192,000 bps TranscodeReasons: ContainerBitrateExceedsLimit, DirectPlayError Session 2 — client limit raised to 4,000,000 bps (still just below the detected value): Detected container bitrate: 4,192,000 bps TranscodeReasons: ContainerBitrateExceedsLimit, DirectPlayError The second session is particularly telling — raising the client limit to exactly 4 Mbps still triggers transcoding because the detected container bitrate is 4,192,000, just above it. Full logs attached. --- Related ErsatzTV issue #2022 — HLS stream bitrates inflated during detection in Jellyfin/Emby Live TV pipelines --- Workaround Setting the client's maximum streaming bitrate to 20–30 Mbps masks the problem by raising the threshold above the inflated detected value. This is not a fix... it disables a meaningful safeguard and causes all Live TV to transcode regardless of source quality. --- Potential solution For Live TV HLS sources, Emby should use the BANDWIDTH= value from the HLS manifest as the authoritative bitrate for the ContainerBitrateExceedsLimit check, rather than probing the TS segment headers. The manifest value is what the HLS spec intends for this purpose (probing live segments for bitrate is unreliable, as segment headers may carry peak or nominal values that don't reflect the actual encode target.) It's also worth noting that the reason the probed values are so far off (4 Mbps vs ~1.33 Mbps actual) may involve incorrect bitrate metadata being written into the TS stream headers by ErsatzTV, but regardless of the source of that discrepancy, trusting the manifest BANDWIDTH= value would be the more correct and robust behaviour. ffmpeg-transcode-2c59b904-f3b8-417a-91db-6111478bb332_1 (1)(2).txt ffmpeg-transcode-3aa1a334-fdde-419f-a931-cb9380d36de0_1(1).txt