All Activity

@matsushita - Wor, that's great. Thanks a lot for your contribution. Same to all other contributors, you are awesome!

Hi, I’m happy to report that the Japanese translation on Emby Translate is now 100% complete for all currently available components. Over the past several days, I reviewed and updated the Japanese translations across: - EmbyApps - Emby.Client - EmbyServer - Shared / UIEssentials - Shared / Terminology This included not only filling untranslated strings, but also reviewing existing translations for consistency, terminology, placeholders, UI wording, and technical context. I also completed the Japanese AlexaCommands translation. Since AlexaCommands is not a normal UI resource, I treated it as a Japanese interaction model rather than doing a literal translation of the English utterances. The sentence order, particles, spoken expressions, and device-name pronunciations were adjusted for natural Japanese speech while keeping all internal keys, slots, AMAZON.* identifiers, placeholders, and invocationName unchanged. The Shared terminology glossary was also reviewed and aligned with the completed Japanese UI, so future translations should have a more consistent terminology base. At this point, Emby Translate shows Japanese as fully translated across all currently exposed components. There are still a few source-side items I would appreciate confirmation on: 1. Core subtitle font size The description says the valid range is 5–50, while the validation range appears to allow 5–80. 2. Core subtitle margin The description says 1–200, while the validation range appears to allow 0–200. 3. Closed-caption standard One source string refers to “EIA-607/EIA-708”. Is “EIA-607” intentional, or should this be “EIA-608”? 4. Alexa invocation name The Japanese AlexaCommands model currently keeps: `m. b. home` unchanged, consistent with the source and other locales. Please let me know if a different invocation name is expected for ja-JP. Everything else on the Japanese side is now translated and reviewed. Thank you for providing access to the translation system and for the additional contributor permissions. Best regards,

Ok

If you just want to do it to resolve this specific issue then it's probably just worth waiting for the fix. The https option was just a work around in case you already had https configured.

Just the Emby app on the FireStick. It's resolved in v0.1.5 which should come fairly quickly to the store

Might look into it again then, thanks! Now PCs just need to have the HDMI-CEC issue solved.

Is this required to stay enabled, or can we revert after the install? Anyone know?

Hi, we’ll take a look at this. Thanks.

Are those volumes on the nas?

Thanks for the update. Just remember that once you customize it, you’ll also need to remember to keep it up to date if it ever changes, that’s why it should only be a last resort.

I forgot to mention, the app called Hi-Res Radio is an example of how the Emby app should support the feature, with a toggle in settings that can be turned ON and OFF only if the phone has support, for phones without support the option remains disabled or grayed out.

I forgot to mention, the app called Hi-Res Radio is an example of how the Emby app should support the feature, with a toggle in settings that can be turned ON and OFF only if the phone has support, for phones without support the option remains disabled or grayed out.

Also what software created the mkv? If the file has missing or incomplete header information then this can cause the player to have to fetch more of it before it will start playing. And that can vary per player depending on the way that it’s built, so the fact that you’re only seeing it on Roku doesn’t rule that out.

I ran into this too. Open Emby's Network tab and set the local IP binding manually That fixed my weird 0.0.1.2 address

Thanks for following up.

That's what I'm referring to, just trying to spread the word as it's rather inconvenient for me Thanks for all the hard work HS

Hey Bill, com skipper isn't skipping commercials for me. I checked the .ts files and the .edl files, ran comskip manually to ensure commercials were detected that doesn't appear to be the issue. The player states "Commercial Skipped" but it just keeps playing right on through the commercial without skipping. Kind of at a loss after some diagnosing, attached my log file. Shows 2026-10-07 16:49:32.902 Info Com Skipper: Skipping commercial. Session: cce82cf1a6683b4a20bce97a1cce9644 Start = 9927400000 End = 12250400000 But that's not what happened in the player. BTW it was working it seems before I updated Emby the last time. That's purely supposition because I hadn't paid too much attention to it for some time because it just always worked, but I just noticed it the other day. embyserver(1).txt

Chrome: Version 154.0.8037.93 (Official Build) (64-bit)

What browser and browser version?

Hey, just wanted to add my two cents. I understand your point but I honestly don't think a new file architecture is the most effective or efficient structure.. I have MANY items in my library that fit your example. For example. I love the MCU. Here's my point. Playlists are the best solution for what you're describing. A.) It keeps the strong simple architecture of type and doesn't mix them. B.) You can add anything within your library. In WHATEVER order you choose. I literally have two playlists for my MCU files both in movie time chronological order and one that includes series, where the other is simply movies only. You may want to reinvent the wheel but it's just a thought.

Yes, my original post states that.

The logo has a trident. The project has issues. We're working on the balance. I've been working on Undertow, an open-source plugin that brings Jellyfin libraries and compatible sources into Emby's native apps. There have been some very interesting projects recently connecting the Jellyfin world with other sources of content. Undertow brings those straight into Emby. How we run it. Browse movies and series, choose a playback version, and let Emby handle playback and local watch progress. Catalog refresh imports metadata. Playback sources are requested when needed. No generated STRM collection to babysit. We run it at home. Now I'd like testers with different servers, devices and viewing habits to find the bugs our household hasn't adopted yet. Full disclosure Vibe coded with Codex, Claude, and whoever still had a free trial. I put it in production, so apparently I'm the adult supervision. Guaranteed to have bugs. Probably some I haven't met yet. Good luck. Bring logs. Getting started The documented target is Emby 4.10.0.40, with one source per Emby instance. Read the setup guide and back up your Emby configuration. A test instance is a sensible starting point. Download Undertow.dll from the latest release. Stop Emby, copy the DLL into its plugins directory, then restart. If upgrading an older build, remove Jellyembifier.dll, keep the existing configuration and data, and install one plugin copy. Open Dashboard → Plugins → Undertow → Settings, enter your source details and choose catalogs. Select Maintenance → Refresh now, let the import finish, then try a movie and an episode in a native Emby client. What needs testing Playback startup, version selection, subtitles, audio languages, seeking, resume and actually finishing something. Apple TV, iOS and other native Emby clients are especially welcome. Successful reports help too. Tell us your versions, device and what worked. “Watched an episode, sought twice, resumed correctly” is useful evidence. This is experimental software. Sync keeps existing titles when upstream catalogs change, search covers imported titles, and watch progress stays in Emby. ASS subtitle rendering remains unresolved. Check the README for current limits. Found a bug? Put your robot to work. Please use GitHub Issues for bugs. Search first, then click New issue. You'll need a free GitHub account. Keep it short and useful: Undertow, Emby Server, source and client versions. Device and host OS. Steps to reproduce. Expected result and actual result. Relevant redacted logs, with the time and timezone. Whether the same item plays directly from the source. One problem per issue. “Broken” is a terrible title and an excellent description of my enthusiasm for debugging it. AI-assisted debugging and pull requests are encouraged. Give your AI tool the repository, reproduction steps and redacted logs. Ask it to investigate, suggest a fix and help you test it. If you get a working fix, fork the repository, push it on a branch and open a pull request against main. Your AI tool can walk you through that too. Include what broke, what changed and how you tested it. Disclose the AI assistance, review the diff yourself, and follow the repository's contribution instructions. Please don't paste forty pages of chatbot conversation into an issue. I have my own robots and absolutely no intention of reading yours arguing with themselves. Send the diagnosis, evidence and preferably a tested PR. If you're stuck, a concise, reproducible issue is still welcome. Coding is optional. Remove passwords, tokens, API keys, private profile URLs and signed playback URLs before sharing logs with an AI service or posting them publicly. Check screenshots too. Report Undertow problems to the project first. Emby's developers didn't volunteer to debug my hobby. Source and documentation · Downloads · Issues · Pull requests Bring curiosity, patience and logs. Bonus points if your robot fixes something before mine does.

Is this in the web app?

It’s actually all one screen. One screen with two tabs

What version number are you on now?