All Activity

Hi, we'll have a new ffmpeg build on the server beta channel soon, so stay tuned for that. Thanks.

Have you seen: Connecting from Client Apps?

Hi, are you still seeing this with Emby Server 4.10 ?

I think they are showing the correct size but they are just being clipped by a few pixels. We'll try to chase this down. Thanks.

Those two paragraphs seem to contradict each other?

it is mainly release notes.

Just wondering, is .62 out just to somehow update release announcements (as there wasn't one for .61) or are there actual changes with .62 as well ?

3.5.62 Core UI Update Only Core UI Changes from 26.0.27 to 26.0.29 Various spotlight bug fixes and improvements Various spotlight bug fixes and improvements

Emby for Android 3.5.62 Released Changes 3.5.62 Core UI Update Only Core UI Changes from 26.0.27 to 26.0.29 Various spotlight bug fixes and improvements Various spotlight bug fixes and improvements

Simple answer is: it doesn't. The plugin will still write and remove tags even if its locked. But it will only edit the tags made by the plugin. So if you have manually added a tag, it should still remain on the item.

26.0.29 Various spotlight bug fixes and improvements Various spotlight bug fixes and improvements

Emby Web App Update: Version 26.0.29 The Emby Web app has been updated to version 26.0.29 Go and try out: https://app.emby.media/ Changes 26.0.29 Various spotlight bug fixes and improvements

This may have been addressed before, but how does the plugin handle an item where the tags field is locked?

I believe so, yes.

Hello. I built the integration between Emby and Vimu myself. To be precise, I am someone with zero programming background who simply explained the task to ChatGPT, and after a series of failures, it made a working integration. For ethical reasons, I cannot share this version publicly, but ChatGPT can provide you with all the necessary information: Technical description of the Emby Android TV → Vimu integration The integration uses Vimu (net.gtvbox.videoplayer) as an external playback engine while keeping Emby Android TV responsible for library navigation, playback state and server-side resume positions. The important discovery was that there are two independent resume mechanisms involved: Emby's server-side playback position. Vimu's own local resume database, particularly when Vimu's "Resume by filename" option is enabled. Emby may provide playback URLs whose final path component is generic, for example stream.mkv or master.m3u8. Vimu's filename-based resume mechanism uses the final path segment of the URI as its resume identity. Consequently, unrelated Emby items can collide in Vimu's local resume database. Simply replacing the final component of an Emby URL is not safe. In particular, HLS endpoints such as master.m3u8 are functional server routes rather than arbitrary filenames. Renaming them can make playback fail. The working solution is therefore to make Emby the single source of truth for resume position and prevent Vimu's filename-based resume database from reusing an old position. Before launching Vimu, the client creates a small HTTP server bound exclusively to 127.0.0.1 on an ephemeral port. For every individual playback launch, a new alias filename is generated using the Emby Item ID plus a random UUID, while retaining an appropriate file extension. Conceptually: embyvimu_<EmbyItemId>_<random-UUID>.<extension> Vimu is launched with a URI similar to: http://127.0.0.1:<port>/embyvimu_<ItemId>_<UUID>.mkv The local HTTP server responds to Vimu with an HTTP 302 redirect whose Location header contains the original, unmodified Emby playback URL, including its original query parameters and authentication information. Therefore the actual media request ultimately reaches Emby exactly as originally generated, while Vimu sees a unique last path segment for every playback invocation. The UUID is important. Using only the Emby Item ID creates a persistent filename identity in Vimu and allows Vimu's own stored resume state to compete with Emby's state. Generating a fresh filename for every playback session prevents Vimu from finding an earlier filename-based resume record. The Emby resume position is explicitly supplied to Vimu using Vimu's startfrom Intent extra. Emby stores playback position in ticks, where 10,000 ticks equal one millisecond, while Vimu expects startfrom as an integer number of milliseconds. Therefore: startfrom = PlaybackPositionTicks / 10000 The Vimu Intent also uses: forceresume = false so Vimu is not instructed to override the supplied position with its own resume decision. forcename may be populated with the Emby item's display title. This affects the title displayed by Vimu but is independent of the URI filename used by Vimu's filename-resume mechanism. Vimu is launched for result. Its returned position value is read by the Emby client and converted back into the normal Emby playback reporting flow. Emby's existing Playing/Progress/Stopped reporting can therefore update the server-side UserData normally. The resulting playback flow is: Emby Server resume position → Emby Android TV → startfrom (milliseconds) → Vimu → returned playback position → Emby playback progress/stopped reporting → Emby Server The local redirect is only an identity shim for Vimu. It does not proxy the video payload itself. After the 302 response, Vimu retrieves the media directly from the original Emby URL, so the Android client is not placed in the media data path. This was tested with Emby Server 4.10.0.40 and Vimu Media Player 12.50. The key design principle is: Emby should be the sole authority for playback position. Vimu should receive Emby's position through startfrom, return its final position to Emby, and its local filename-based resume database must not be allowed to override the server-side state. In testing, generating a new UUID-based URI alias for every playback invocation solved the cross-title/cross-session resume problem while preserving normal Emby resume synchronization. -------------- Unfortunately, I have absolutely no background in programming or in what the AI actually did, so I won't be able to provide any additional consultation.

If I have the externally-installed version and want to move to the catalogue version, is it as simple as just installing the catalogue version?

Why wouldn’t they be shown as folders here?

No we may have to look at that.

Because before the edits, I could access it at least with Emby connect when I was using 5g on my phone, now not anymore. Only wifi over LAN. Regardless of the before, I would like to repoint everything to a config where I can connect to it via HTTPS with a single pointer over LAN or over 5g, so that I can also present the web link to friends over the Internet (with custom logins of course)

I did a test for BBC R1 Matt & Mollie Series recording and I have both recordings - 22nd and 23rd September 2026 As mentioned in my private message, I would need to see logs for when the guide refreshed before the recording of the 22nd September that did not happen to see if there are clues also to see the timers.json and seriestimers.json files I mentioned - Other areas to look into if there is an issue with the system clock or if the PC goes to sleep Did your recording for today 23rd happen ?

Fantastic, thank you very much for checking it

I’m not as upset about it anymore because there are now plenty of excellent third party apps & playback engines for Apple devices so Emby’s HLS pipeline is no longer needed. mpv & vlc used by all the legacy apps are terrible on Apple devices (for people who care about proper playback of modern formats). That said, the fix here should be trivial for the team as hevc already works with Safari which, like the Apple TV, also uses AVPlayer. So the pipeline is already there. All that’s needed is updating the device profile on the tvOS client to request media files in an AVPlayer friendly format.

Please check your DMs.

@LukeIs that Luna API being utilized on the LG to delay network requests until ready?

Exciting history lol. Thanks, I didn't know that and can now relate. However, I am whitelisting the domain but still face the issue when starting Emby the first time after powering on the TV