All Activity
- Past hour
-
roliac joined the community
-
Othmanes0 joined the community
-
96564 joined the community
-
Movies in collections that I made are missing movies
Luke replied to ZamBucca1's topic in General/Windows
Did you ever determine if you have nfo files next to your video files? -
JDTV457 joined the community
-
OK it should be pretty straight forward. You won't see it on an individual movie file, but you will see it on the parent folder.
-
diLma9518 joined the community
-
DigitalG joined the community
-
Miguel678 joined the community
-
Redbug22 joined the community
-
ok .. When I reproduce using the exact same files it works, but in a new library everything works no matter the path, strm vs .mp4 etc .... but now I found something... the few folders that have the gray while none of the other folders have that, they have folders I named WORK with poster pics such as poster-1.jpg etc... and I mean the folders in gray I posted above such as Frankenstein... But when reproducing I did not copy those work folders so I'll play with it some more.
-
uemby89277 joined the community
-
steve7789 joined the community
-
SortSpion started following Parental Ratings - Use BBFC Rating Symbols
-
Parental Ratings - Use BBFC Rating Symbols
SortSpion replied to abroadhursthall's topic in Feature Requests
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 -
-
Movies in collections that I made are missing movies
ZamBucca1 replied to ZamBucca1's topic in General/Windows
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. -
-
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.
-
Tone mapping doesn't work with Dolby Vision, correct?
Luke replied to heffeque's topic in General/Windows
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?
-
VideoToolbox H.264 Hardware Encoding Fails on Apple Silicon (M1 Ultra) - Invalid Profile Parameter
Luke replied to rockinyp's topic in MacOS
Hi, are you still seeing this with Emby Server 4.10 ? - Today
-
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.
-
External Player (Vimu) resume position issue on Android TV
franco72 replied to franco72's topic in Feature Requests
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?
