Leaderboard

Okay, so I tested some DV P5 content from a memory stick, it played fine. I also went back and tested the same content in Emby, and it also played fine this morning. My theory is that because I was trying to force a bunch of media into compatibility mode last night (to play films with DTS tracks, and stop the freezing) that some piece of state was retained when I tried to play the DV media and it didn't attempt to direct play even though it was a different title... all P5 media wasn't working last night; so yeah, my best guess is some bad state was being retained somewhere.

It was indeed a problem connecting to tmdb. After I changed it to a usable IP address, I could get the picture normally.

I thought it was already doing this.

Okay, I checked both Android devices. The Oppo RenoZ (slave) had disabled logs, so I could only access the logs on the Oppo Findx5 (master). emby_android_1755953102173.txtemby_android_1755951916259.txtemby_android_1755951647100.txtemby_android_1755950669389.txt (Oppo Reno Z)

You are right - I have a bug - I will fix it asap VIc

Kodi bug, happens on some of my devices too. I try to find a workaround.

I'll check that..

It is not pointless at all. ffmpeg is a poor audio conversion utility - there are far better utilities to convert audio. Some formats ffmpeg can't convert to at all - such as to DTS or 7.1 AAC for example. So yes, the Emby transcoding process via ffmpeg will get you 'audio', but currently it's low bitrate poor(ish) quality 5.1 AC3 at best.

Just lean-in to realtime transcoding; it's very fast if you're not transcoding the video stream. It's by far the best feature of Emby, and it should be celebrated. There are many devices playing the media, they all need different treatment; their respective clients should know the proper way to request the media is massaged by the server for each device.

It's permanent, yes. When its happend again i send you the myvideo.db.

No they are not. Not for audio, because you're going to lose direct play with external audio files.

The beta release has also added support for external audio files - Support external audio tracks for movies and episodes So you now have the additional option to add better quality / pre-made external audio files vs a transcoded version. Depending on the naming of the files, I believe these can act as Default audio without the need to add tracks within the MKV. ie adding <movie file name>.default.eac3 will add a Dolby Digital Plus file and make it the default audio playback option - as I believe external default files are a preference to internal ones - but not 100% on that. @Luke?

Hi, yes this makes sense. Thanks.

Please make it a toggle on/off feature. I don't need/want that feature. I often do myself leave it on pause for a long amount of time because I start a meeting, get a call, etc. I work from home and tv show playing in the background help me concentrate. But having to log back everytime is already a problem specially when it doesn't resume right away like it used to.

Perfect! Thank you!Of course, I expect auto transcoding to AC3; this was working fine on my CX for years. I see no reason to transcode my media; 1. No TV exists for a lifetime, I don't want to butcher my archive quality media for one TV 2. Many people share my library, with many different TV's, it's impossible to form media files that suit all devices; Emby must aggressively transcode to suit whatever device is playing 3. I have thousands, maybe 10s of thousands of media... it would take me months to format it all specifically for the G5... it could meanwhile break on my friends and families TV's, and then what when I get a G8 or change teams to Sony or whatever? 4. I'm not a fan of adding a bunch of duplicate tracks to the media; it doesn't play well; 1, usually the compatibility track needs to come first, or the device won't select it by default and you transcode anyway, 2, if the compatibility track DOES come first, then nobody ever selects the best track for their player and just roll with the most inferior transcoded experience anyway! Emby's realtime transcoding is the best thing about the software. Lean-in to that awesome feature! I desperately wish Emby would do MP4 transcoding for LG TV's when playing any DV media in MKV files... I transcode all MKV content to MP4, but it's a lossy conversion (subs -> mov_text) and I feel sad every time, because I'm destroying the source material. Please consider adding DV MKV->MP4 transcoding; `ffmpeg -i [src.mkv] -c copy -c:s mov_text -map 0:v -map 0:a -map 0:s -strict unofficial dst.mp4` is all it takes, unless the source mkv also has pgs subs and/or unsupported audio format; then I have to work out the ID's of all bitmap sub files and selectively strip those streams from the dest, which is something that should be performed so much nicer by emby! (It's a tragedy to destroy my archive media just for LG players! also, I can't share/seed any of my archive after I've butchered it) I'll experiment with the DV playback from memory stick shortly and get back to you...

Thanks all, I uninstalled then reinstalled xmltv and it works now.

Just make a separate library for your books and set that library's default view to "Folder" view and you do not need to switch views to view them.

Small beta if people want to test before i release. A memory leak has been fixed. EmbyIcons.dll

Ei Gude, ich habe hier mein Setup mit einer Qnap am Laufen. Schau mal hier: https://kb.synology.com/de-de/DSM/tutorial/Quick_Start_External_Access Die Idee ist, dass deine Synology sich um die Erneuerung der Domain kümmert, nicht die Fritz Box. Dann musst du nur noch den Port in deiner Fritz Box weiterleiten. Ich würde dir auf jeden Fall empfehlen, mit Zertifikat zu arbeiten, und nur per https auf den Server von Außen zuzugreifen. Beim Router bitte generell UPnP ausschalten und manuell konfigurieren, ich weiß es nervt, ist aber sinnvoll. Falls Sicherheit wirklich keine Rolle spielt, kannst du den unsicheren Port 8096 direkt in deiner Fritz Box weiterleiten. Die Netzwerkeinstellungen von Emby müssten dann noch angepasst werden. Passwörter werden dann jedoch auch unverschlüsselt übertragen. Alternativ https://kb.synology.com/de-de/DSM/help/DSM/AdminCenter/application_appportalias?version=6 => Reverse Proxy Regeln anpassen Der Plan ist, dass 8920 dein öffentlicher Port ist. Die Box leitet von 8920 an deine Synology Reverse Proxy als https weiter, Reverse Proxy leitet die Anfrage dann als http ungesichert an Emby 8096 weiter. Die Synology regelt somit die Domain, Zertifikat und Sicherheit selbst.

FFmpeg 8.0 added support for the Whisper filter that is able to detect and transcribe speech https://www.phoronix.com/news/FFmpeg-Lands-Whisper

The debug logs will give you a good indication as to where it's stalled and why. If you want to run it up, wait for it to hang and then send me a pm with the log, I'll happily take a look for you.

TBH its incredible that Emby does not warn admins about these settings. And Admins need to have a scare, to correct them. It's both dumb and dangerous, when exposed to the internet, if these things are not mentioned or warned about.

𝕻𝖔𝖑𝖚𝖓𝖉𝖗𝖆 https://musicbrainz.org/artist/209edccc-ea35-4347-8c20-8f8d24ab0728

And before people say, this can be simply adjusted or avoided in the apps by building in a query as to which backend is used, the answer to that is: no, not simply. The technical debt is high. To preserve behaviour you would need a parallel mode with dual writes and read-compare to validate that every operation returns identical results. The test matrix would quite literally explode. So, while in theory, Emby could support both SQLite and a heavier engine such as MySQL or MSSQL, but that is not the same as just flipping a switch. The difficulty is ensuring identical behaviour across two very different systems. SQLite is embedded and predictable, while MySQL and MSSQL bring client/server semantics, different planners, transaction models, collation rules, and indexing strategies. With InternalItemsQuery allowing almost any combination of filters, sorts, groupings, and field-level selections, the test surface becomes massive. Optimisations that work on one engine may need a completely different approach on another. Caching also becomes problematic because partial field selection conflicts with storing complete entities, and now that logic would need to be maintained for both providers. When it can be simple(-ish): Read-only, scoped endpoints: Add a /v2 set of endpoints that serve a few hot use cases only. Back them with a separate read model (denormalised tables or materialised views). One-way sync: Keep the legacy DB as the source of truth and use change data capture or event/outbox to feed the new read model. No free-form queries: Drop InternalItemsQuery flexibility on v2; expose presets/profiles with fixed filters, sorts, and field sets. Independent caching: Cache whole entities or fixed projections only, with ETags. No field-level partials. That lets you run two (or more) kinds of endpoints side by side with limited blast radius. When it won’t be simple: Write parity required: The moment v2 must handle writes, you need dual-writes, idempotency, reconciliation, and consistency checks. Complexity jumps. Full InternalItemsQuery support: Replicating arbitrary filtering/grouping/sorting on a second store recreates the same optimisation and caching problems twice. So, while supporting both is possible, it means maintaining schemas and migrations for two (or more) engines, validating results across both, and dealing with their differences in search, JSON support, upserts, and isolation levels. Unless the scope is narrowed to something like read-only endpoints or predefined query shapes, these becomes permanent parallel systems and a significant ongoing engineering burden. In other words, the Emby team won't have the bandwidth to handle this and still have time to handle features that would make a lot more sense for a private media server... Again, I'd love to have this feature, but I get why not... (also, I prefer to have the ebook feature built out and the TV Next released, but that's just personal preference )

Just to answer the question: It's months of continuous work, preceded by a couple of weeks alone for prototyping, testing out options and working out a solid concept. Again - for the short-attention-span readers: this is not about a simple data layer change - it would require fundamental changes at varrious core elements of Emby Server, even down to client apps and APIs in various aspects to get equal results like now with SQLite. And like @ebrsaid: it cannot go in a way that we'd stop working on things for the Emby user base - which is and has been driving Emby for so many years already.

You are basically describing a ORM in almost every other language. It's been ages since I have heard refer to an ORM as a DAL, because it's just a subset of what an ORM provides. The ORM of choice for most dotnet projects is EFCore (https://github.com/dotnet/efcore/), but moving to that is quite a significant effort. Probably in the order of months of a single developer's dedicated time & focus. As an example, Jellyfin has been moving towards it for more than a year now (counting the development time). Testing with the initial merge of the movement to EFCore has been happening since Nov. 2024. And this is all with basically no other significant feature added on the server side in the meanwhile. I don't think Emby can afford such a long pause for any new functionality, especially when there are a lot more impactful and demanded feature requests still open: https://emby.media/community/index.php?/forum/98-feature-requests/&sortby=forums_topics_reactions.topic_reactions&sortdirection=desc.

Not sure the reason, but the bitrate had something to do with it. When I change the quality/bitrate in Chrome and other browsers on a laptop, it fixes the issue.

From a trustworthy point of view, I find it difficult that I need to grant an external website access to my library via API Key directly. I personally run Emby in combination with an external auth solution in front of it, and I would never ever tear down this wall for anything external. But thanks for you effort!

I too am not buying the performance implications, I've got 80TB of media and my data folder is only 530MB, I've got databases elsewhere a couple orders of magnitude in this size. 6.3M ./config 3.9G ./cache 5.2M ./plugins 1.0K ./.gnupg 393K ./root 31K ./.dotnet 18K ./sync 33G ./metadata 366K ./.nv 21K ./localization 529M ./data 4.0M ./fonts 40K ./.cache 273K ./transcoding-temp 14M ./logs 37G . You are not really going to gain anything performance wise out of having an external database with a pittance of a dataset like this. You will however, as I pointed out before.. gain the ability to configure high availability.. and potentially performance gains from distributing transcoding jobs across machines. These are not enterprise desires, we can spin up highly available setups with COTS hardware and recycled gear.. I understand this is not a priority, and there are other more important features I'd like to see first (like HEVC output on transcode) that potentially have a bigger impact on more users first.. but this is definitely a feature I'd like to see work its way out sooner than later. If the underlying design always had this in mind then the effort required to implement this should not be as technically hard as some of the other things on the todo list, low hanging fruit. I believe this would make a fine premium feature, none of your competition supports highly available configurations and those evaluating the options available will see that and it will stand out among the crowd, even if they dont have immediate plans to use it its one of those things I believe if you build it, they will come.. People will keep it in the back of their minds and once they have a highly impactful outage the chances are high they will consider building towards a HA goal.. its unlikely to be a feature widely used by the masses, but it is a feature that I believe will be attractive to those whom use Emby as the primary/only source of media. I can pretty much guarantee soon after you finally implement this feature you will have several users publish quick/simple/easy to follow guides for spinning up a HA k3s config on whatever hardware they can scrape together, from lil arm boards to big xeon recycler servers... The community will start writing charts, other automation and dramatically simplify this for everyone else, it will then take off as people see the advantages container orchestration brings and the vail of technical debt is lifted, it will only take a few days before less technical Emby admins can understand and deploy their own HA setup too with a few simple commands.. this is not a bespoke feature request that will languish such as the LDAP implementation, k8s is a major technology player just gaining more and more adoption, You are going to have a ton of HomeLab users jump on this so they can run personal production workloads at home simply for the exposure and experience they will use in their professional careers.. The Staff must see this, how much uptick have you seen in your docker container downloads since you released it.

Hi there, we can't verify the legality of the content so for app store releases we run all remote streams through your emby server. If we were to direct play to remote urls that are known sources of pirated content, this could put us in jeopardy of violating app store policies. Thank you for your understanding.

Wow, I didn't realize you have been working on getting Asustor users back online for 5 years. Those poor users, I had know Idea.

@radeon Check the logs before closing the conversation if your not providing refund.

OK, so let me make this clear and final: The plugin is working exactly as advertised. It downloads theme media. If you don't like what it downloads, you're welcome to delete them whilst leaving them in the filter list and they won't download again with the plugins still installed and the tasks running. That’s what it was built to do, and that’s what it does. It’s not broken, it’s not outside its scope, and nothing in the description ever promised language guarantees. That point has now been repeated enough times. You had a free trial to decide if it suited you. You bought it anyway. That means you accepted the functionality as delivered. Buyer’s remorse doesn’t retroactively change the terms. Support and feature requests are provided as and when I have capacity. This is development work done in my own time, not an enterprise service with SLAs attached. That’s been obvious from day one, and if you expected 24/7 support and a dictated roadmap for the price of a plugin, that’s an unrealistic expectation. Dragging this across public threads and DMs, nitpicking over wording like “pal,” and now throwing around “side hustle” as if that’s some kind of revelation, none of that changes the reality: the plugin works, and it works as sold. If you don’t like it, uninstall it and move on. But I’m not going to waste more time repeating myself. This conversation is closed.