All Activity

Was there something in the log that helped point to the issue? Or is this just another way to say "GO away and shut up?" I actually do not believe that but "we are looking into it" just shows up so often that it is hard to believe. But the last time it was directed at me or my post(s) the bug actually got fixed. I hope this is one of those times. I could use a good fix.

Sorry been really busy but couldn't find the debug option mentioned. All I found was an embyserver.txt in one of the log settings.

如题，为什么只有在剧集媒体库才能浏览各个制片商工作室，还能添加图片，但电影媒体库却不行？有时候我想浏览所有电影公司，比如派拉蒙，皮克斯，但好像并没有这个功能，为什么？以后会有吗？我感觉这是一项遗漏的功能

Others will probably get to testing this out before me since I'm still in the middle of a move and my server is currently off for probably the next couple of days at least. Glad to see an update on this and hopefully it will fully address the issue and privacy concerns myself and others have voiced.

I’m a Premiere subscriber running linuxserver/emby on a Mac mini M4 in Docker. Roku Live TV was broken. Some channels played, others buffered or went black. No pattern. Found the root cause. Two problems. The linuxserver container’s LD_LIBRARY_PATH poisons Emby’s bundled ffmpeg on ARM64 at runtime. And Roku’s HLS client chokes on copy-codec passthrough for certain IPTV streams. The fix. Wrapper scripts via custom-cont-init.d that clean the environment before ffmpeg launches and selectively rewrite copy-codec live streams to libx264/aac. ffdetect stays untouched. IsEmbyCustom stays true. No binaries modified. Persists across restarts. Tested on: - Emby 4.9.3.0 - linuxserver/emby:latest ARM64 - Docker Desktop 29.2.1 - macOS 26.3.1 - Mac mini M4 - Roku Streambar SE Results: Five encoders detected. Zero errors. HLS confirmed on multiple live channels. Copy codec rewrite verified in logs. Drop-in fix. Three minutes to install. Clone the repo, copy the scripts, add one mount line to your compose file, restart. https://github.com/shiz504/emby-roku-as-fix Happy to help anyone hitting the same issue.

I have the x3600h. So far so good with this one but I'm less critical now about these kinds of things than I used to be. I use it probably every day

我看你没有回复我 其实就是danmaku功能 应该挺多用户需要的 我看你没回复我了 不知道你知不知道我说的danmaku

"Good" to know this is a Firefox bug, not a bug in Emby's browser app! Found this thread when I saw Emby (Firefox actually, apparently), trying to pre-fetch a whole ~16GiB movie ... cancelled it / gave up after ~6GiB (going by server logs) ... haproxy[185627]: [206] 192.168.1.10:48730 [31/Mar/2026:15:33:27.753]... 0/0/0/4/63732 6556730260 - - CD-- 19/19/1/1/0 0/0 {emby.example.org} "GET /emby/videos/185771/original.mkv?DeviceId=... HTTP/1.1" That's 6,556,730,260 bytes. Here's the related Firefox bug report, for those curious: https://bugzilla.mozilla.org/show_bug.cgi?id=2000420 Sucks that most non-tech-savvy users might end up thinking it's Emby at fault!

While we are in there ... clicking this button doesn't do anything:

thanks

the metadata editor would be the best way.

And how do I know if something has an external ID or !external ID?

If it has an external ID - you can't. Emby willl always remember it for userdata/tracking purposes (watchstates/playstates).

Are you saying this is not possible? : How do I delete everything about a title so that if I add it again later it is as if Emby never knew it existed before?

OK. user data, which is not metadata, does not get purged from the database unless the user is deleted. this is also what makes it possible to move a movie file from one place to another and have it retain watch data.

What exactly happens?

The latest beta server build has a hidden config switch. so if you open up the /config/system.xml file, set ValidateImageTags to true and then start the server. this will make the image tag value required, which will be unique per image and therefore you won't be able to guess a url anymore. It's an opt-in config switch for now to allow for time to identify cases where that param may not be supplied.

Record a program, watch the program, delete the program, record the same program again and Emby thinks it has already been watched.

I think if you can produce another couple examples then it might be easier to identify the common thread. Thanks.

@Brusniss?

HI there, can you please provide a specific example? How to Report a Problem Thanks !

You can also try that IPTV app on an Android emulator, and then intercept those requests using a tool like Fiddler, so you'll know what kind of request headers your IPTV streams accept. Once you do that, you can tweak the streams you added through Dispatcharr accordingly. Good luck!

Examples above, but I have only local IPs in my log. Still inconsistent behavior.

They actually should be, as long as those are remote IPs - but by no means it means it works 100%, you might've just found a bug - but you need to provide specific example.

Indeed I see the difference now, if a device/endpoint has a host name, it is obfuscated (e.g., "host2") but if the device/endpoint has an IP address then it is ignored and not obfuscated. (at least in most cases) What's the point of that?