All Activity

I will totally chime in on this one. Being able to spot the age rating at a glance by the color and symbol would be a solid improvement, when those symbols are used everywhere outside of your media server. Having grown up with such symbols, they are so recognizable that legibility isn't a concern. For me, those icons would be the Danish icons. They share some similarities with the British, and the concept is the same And while I acknowledge that not everyone like emojis, having the option to display these icons will greatly help us that do.

And this still isn't being ignored after another 3 months -

I wasn't using a plugin when I was having the issues. I am using the ACdb plugin now and so far its been fine.

Both of these are still the case in .62.

How so? You asked how it handled an item with locked tags, and the plugin doesn't care. It would still write new tags and remove them. What i meant with "Simple answer is: it doesn't." is that it doesn't need to handle that, because it "overrides" the locked setting. Maybe bad expressed by me.

But it would still be helpful if you could update as there are some internal updates to focusing with arrow keys so it's mainly a matter of if you run into anything odd.

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)