Please provide a Windows Emby Theatre legacy version

[scottpro 10]

Wow, this thread kinda got out of control. I'm going to give my 2 cents worth about both versions of ET.
A while back ET (the legacy version) stop working due to a server update and causing ET the hang at startup.  The solution provided then was to install the Windows Store version, so I did.  Here's where the trouble started.

I use a custom version of "mpv.dll" which fixes problems with Dolby Atmos (it's a FFMpeg issue).  I also have extensive plug-in & scripts which are tailored to my theater needs.  Also the mpv.conf has a lot of options that are not supported by ET UI.  Once I installed the Windows Store version all that stop working.  The store version installs the "mpv.dll" at the root of the ET app location.  The Windows Apps location (Program Files\WindowsApps) is a system protected folder which restricts file manipulation (copy, modify, deleting, ...).  Also, the ET store version does not load the mpv.conf or scripts/plug-ins which are disabled in this version.  This made using the ET Store version useless for my needs.  I was able to get this store version working but that's another thread topic.
Long story short, I still use the ET legacy version with my custom mpv.dll, plugins and scripts because that's what works for me.  Once support for this version stops than I will be forced to use the store version which makes things way more complicated.  Yeah I know the store version is suppose to be for the general user but some of us like the customization/extendibility of the legacy version.  The store version just needs an advanced user option to use a custom "mpv.dll" at a user managed location and allow config/script loading as well.

That's all folks...

[Mahinepua 81]

Once external player support is added to the new app you will still be able to use your custom mpv settings and mpv-1.dll`s plus played and continue watching status should  work if using mpv as an external player etc as it did with legacy.

I simply boot with a linux usb distro to replace mpv-1.dll for the time being, take 2 mins.

The new app is about 90% there, not far to go now. Accurate refresh rate and aspect ratio switching for IMAX on a 2.35:1 screen is a nice upgrade. 

Sad to see Generiq go from the forums but also some of his posts crossed the line.  

[scottpro 10]

54 minutes ago, Mahinepua said:

Once external player support is added to the new app you will still be able to use your custom mpv settings and mpv-1.dll`s plus played and continue watching status should  work if using mpv as an external player etc as it did with legacy.

I simply boot with a linux usb distro to replace mpv-1.dll for the time being, take 2 mins.

The new app is about 90% there, not far to go now. Accurate refresh rate and aspect ratio switching for IMAX on a 2.35:1 screen is a nice upgrade. 

Sad to see Generiq go from the forums but also some of his posts crossed the line.  

Using mpv as an external player loses all the screen overlays from ET, which is a nice feature using it as a built-in player.  I've used MPC-BE/HC with madVR but exclusively use MPV because it's a nicer experience.  The application switching was not pleasant.
Replacing the mpv.dll is only one piece of the puzzle (and yes, I have to use a Live Linux USB to replace it).  Since I compile my own version of mpv.dll, I modified the "no-config" option so ET (store version) can't enable it which allows loading of configs and scripts/plugins as before.

Additional info.  I have the following:

1. Panamorph lens on my projector so special scaling is required which ET does not support. 
2. Masking screen (constant height) and is controlled by MPV when calculating scale and horizontal size. Variable from 2.4:1 to 16:9 in 1% increments
3. Custom tone-mapping and projector configuration
4. Dynamic aspect changes for IMAX based movies
5. Event point automation, play, pause, credits, teasers, ...

I could probably do a lot of the video processing using a madVR Envy or Lumagen but I was able to accomplish everything I need in MPV for free (my labor is cheap).  MPV is very powerful especially after it incorporated libplacebo (gpu-next).

Edited August 20, 2025 by scottpro

[softworkz 5065]

@scottpro- the bottom line - as said several times before is this:

Either a player is managed by us - or by the user. But not both at the same time.
That's why mpv configs are not supported and won't be supported.

Going forward, we might open up the client player API (.net) to allow custom player integrations (full integration with Emby overlay controls), but it requires substantial work to build such an integration.

14 hours ago, scottpro said:

Replacing the mpv.dll is only one piece of the puzzle (and yes, I have to use a Live Linux USB to replace it). 

You can make it accessible from Windows, but you need to disable a number of Windows security features, specifically "Tamper Protection". Then you can take ownership of the folders and adjust permissions.

[Mazvydas 5]

1 hour ago, softworkz said:

@scottpro- the bottom line - as said several times before is this:

Either a player is managed by us - or by the user. But not both at the same time.
That's why mpv configs are not supported and won't be supported.

Going forward, we might open up the client player API (.net) to allow custom player integrations (full integration with Emby overlay controls), but it requires substantial work to build such an integration.

You can make it accessible from Windows, but you need to disable a number of Windows security features, specifically "Tamper Protection". Then you can take ownership of the folders and adjust permissions.

But you can and have the ability to provide a user managed application already - the Electron app.

As I've stated once before - we can lock down the server version if we don't feel like we need to update. Why can't we lock down our client version as well?

You can bundle the client side assets into the application instead of using tv.emby.media as the host. Release it once, if the community wishes to support and maintain it to bring it up to parity with time - cool. If not, those who wish to remain offline and away from the internet/Microsoft/whatever else, integrate their own MPV distribution, hack in their own player, etc - they can still have that perpetually.

Just give us that option is what we're asking, as it's not that much work to just bundle the web app assets into the Electron .asar application. You already have that capability as it's clear in the code that is open source, and just choose to have them hosted via your online service instead of fully local.

We run the Emby servers and don't rely on your platforms to watch our content. I can open the web URL and watch directly from my server without any external internet access. Then why did you make applications that rely on your online services and platforms in order to provide runtime code for apps instead of bundling them in with the app?

On 4/2/2025 at 12:38 AM, Mazvydas said:

I'm specifically referring to the Electron version that I linked in my comment.

It relies on pulling assets from tv.emby.media https://github.com/MediaBrowser/emby-theater-electron/blob/master/main.js#L492

    function getAppBaseUrl() {

        var url = 'https://tv.emby.media';

        //url = 'http://localhost:8088';
        return url;
    }

That commented out localhost URL, presumably used for testing, potentially could be packaged either directly into the app, OR for us to be able to run alongside our Emby servers. In turn it would let those who want to use the pre-Microsoft store Electron version indefinitely as long as we stick to supported server versions.

I much prefer the Electron version visually and functionally as it doesn't interfere with my monitor settings. I wish to run it for the foreseeable future, but even if I have the Electron version binaries - because you will sunset the tv.emby.media endpoints as stated in the FAQ - it's just a matter of time until the app will stop working.

Instead of sun-setting and removing those endpoint thus rendering this app useless - please release some version of it for the community to be able to use alongside the Electron apps, even if they will never receive an official update ever again. I'm happy to lock my Emby server version and stick with the Electron apps.

 

[Luke 42077]

12 minutes ago, Mazvydas said:

But you can and have the ability to provide a user managed application already - the Electron app.

As I've stated once before - we can lock down the server version if we don't feel like we need to update. Why can't we lock down our client version as well?

You can bundle the client side assets into the application instead of using tv.emby.media as the host. Release it once, if the community wishes to support and maintain it to bring it up to parity with time - cool. If not, those who wish to remain offline and away from the internet/Microsoft/whatever else, integrate their own MPV distribution, hack in their own player, etc - they can still have that perpetually.

Just give us that option is what we're asking, as it's not that much work to just bundle the web app assets into the Electron .asar application. You already have that capability as it's clear in the code that is open source, and just choose to have them hosted via your online service instead of fully local.

We run the Emby servers and don't rely on your platforms to watch our content. I can open the web URL and watch directly from my server without any external internet access. Then why did you make applications that rely on your online services and platforms in order to provide runtime code for apps instead of bundling them in with the app?

 

When he says application managed what he's saying is that the app is internally configuring many mpv parameters based on both your settings as well as things that are auto-detected by querying the environment.  It would be really hard to mix that with mpv.conf. But as he's said, there's still a way to provide an equivalent.

[scottpro 10]

1 hour ago, softworkz said:

Either a player is managed by us - or by the user. But not both at the same time.

Exactly.  That's why I wanted an advanced user option to disable all the Emby options being passed along to mpv and let the user setup the player as needed.  Emby would still composite all the overlays into the rendered frame but everything else would be user defined.  The current solution I have for using the store version of Emby is to set all the mpv options back to there default settings and than apply all my settings.  This works but I'm doing a lot of work-arounds to get the store version to where the legacy version is.

2 hours ago, softworkz said:

You can make it accessible from Windows, but you need to disable a number of Windows security features, specifically "Tamper Protection". Then you can take ownership of the folders and adjust permissions.

We've chatted about this in the past but the permissions under Windows 11 does not allow this anymore.  The Linux solution was the only way I was able to get a custom mpv.dll into the apps folder.  Even then Windows detected a change in the folder and did a scan of the folders.  So a simple file copy takes about 30 minutes to complete with all the restarts and scans.

Again, I will continue to use the legacy version of the ET until support for it stops and at that point I will decide what to do next.  I just hate the fact that the legacy version has an online dependency that is out of our control and can break the anytime.  I like Emby and I've been using since it was MediaBrowser for WMC on Windows 7.  It's has great product evolution adding features along the way.  I feel as if the store version is a step back even though it seems as if it makes it easier for the average user which it does.  I understand the Emby eco -system and treating Windows as another generic platform makes sense in that regard.  Heck, I have the iOS version on my iPads, iPhone and AppleTV and they're great.  But for custom theater, I like the customization of the mpv player which the legacy version provides even though most users never do.

 

[softworkz 5065]

2 minutes ago, scottpro said:

2 hours ago, softworkz said:

Either a player is managed by us - or by the user. But not both at the same time.

Exactly.  That's why I wanted an advanced user option to disable all the Emby options being passed along to mpv and let the user setup the player as needed. 

It's not like options are "passed once and that's it". Many settings are made dynamically while it's already playing and we will not change our code to conditionally do all this or not. It is sufficiently complicated already since the same player code is also driving MPV on Linux and even on Android (internal testing prototype) and there's no way that we'd clutter-up things such stuff and answer support questions from people whoe are trying to use it that way.

 

9 minutes ago, scottpro said:

We've chatted about this in the past but the permissions under Windows 11 does not allow this anymore.

It's working for me, so there is a way.

 

10 minutes ago, scottpro said:

I feel as if the store version is a step back even though it seems as if it makes it easier for the average user which it does.

I see it as a huge step forward, because it provides high quality video playback for all users rather than just a handful of people who know how to configure it.

 

[scottpro 10]

7 minutes ago, softworkz said:

It's not like options are "passed once and that's it". Many settings are made dynamically while it's already playing and we will not change our code to conditionally do all this or not. It is sufficiently complicated already since the same player code is also driving MPV on Linux and even on Android (internal testing prototype) and there's no way that we'd clutter-up things such stuff and answer support questions from people whoe are trying to use it that way.

Not sure what properties you're changing during playback, perhaps scaling... 

[softworkz 5065]

It burns down to this:

There can be only one captain on a boat.

And not two or more, where one has no clue about what the other is doing.

The volume of user reports about playback issues in the new Emby Windows app is remarkably low - and that is not accidental but for the reasons by how it was done.
In the old app, mpv player was more or less uncontrolled and it was almost a requirement to do extra custom configuration in a config file in order to achieve decent video playback. The new app has changed this fundamentally and for good.

It had been expected that some people would be unhappy about not being able to use mpv.conf anymore, but to be honest, it's a lot less than I thought it might be.

 

 

Edited August 20, 2025 by softworkz

[softworkz 5065]

Future Evolvment

None of the above means that we are aiming at limiting any features that users want or need.

During the next beta phase, people will be free to explain their needs (especially those for which they think that they would need mpf.conf configuration) and we will try to add these to the options as far as possible.
We've done so during the intial beta and we will continue this way in order to allow people to get the most out of all the features which mpv provides.

[scottpro 10]

15 minutes ago, softworkz said:

It burns down to this:

There can be only one captain on a boat.

And not two or more, where one has no clue about what the other is doing.

The volume of user reports about playback issues in the new Emby Windows app is remarkably low - and that is not accidental but for the reasons by how it was done.
In the old app, mpv player was more or less uncontrolled and it was almost a requirement to do extra custom configuration in a config file in order to achieve decent video playback. The new app has changed this fundamentally and for good.

It had been expected that some people would be unhappy about not being able to use mpv.conf anymore, but to be honest, it's a lot less than I thought it might be.

 

 

I totally understand.  As a developer myself I know the complexities of opening up the application for user modification/customization.  After years of platform specific titles, mainly PlayStation and Xbox, adding those titles to the PC market was a total nightmare.  We had to test just about every PC configuration type, GPU's, CPU's, memory size, display types, ...

It's good business sense to unify the Emby experience across multiple platforms while minimizing the work load on the develop team.  I'll assume the burden of overcoming the restrictions the new application enforces while keeping the integrity of the product.  I just don't want to go down a path that will nullify all my work in a single ET update.  Since Linux is finally catching up in the HDR world with Wayland, perhaps I should change my focus to that environment, provided ET still allows some user customization, but that's a whole new topic.

Like the original topic states, it would be great if Emby plans on sunsetting the ET legacy version and provides a snapshot of the online assets so we can host it locally.  Heck, Emby server could probably host it if needed.

Anyway, keep up the great work and I'm still a loyal Emby user.

[Jdiesel 1431]

I have two users that are currently using the new windows/Xbox app. One on windows and the other on windows and Xbox. Both aren't tech savvy and had zero issues setting up both apps. One user previously struggled getting the legacy ET to work reliably and ended up just using a web browser that continuously resulted in unnecessary transcoding. I am happy that the new apps are much simpler and work out of the box, this is coming from someone who was angry when ET switch from DS to MPV wich removed madVR support.

[softworkz 5065]

14 minutes ago, scottpro said:

Since Linux is finally catching up in the HDR world with Wayland, perhaps I should change my focus to that environment, provided ET still allows some user customization, but that's a whole new topic.

ET for Linux is the same Electron app like the old one for Windows and Linux users have been very dissatisfied for a long time. The upcoming Linux app is from the same code base as the new Windows app, which is fully cross-platform and supports a range of UI frameworks (UWP[Win,xbnox], WinUI, MAUI[Android,iOS,Mac,Tizen,WinUI], Electron[Win,Linux,Mac] - yes, there are four ways for running on Windows). 

The new Linux app uses the same MPV integration like the Windows app (and also works on Android in an internal test sample), so that might be not-so-good news for you, but the more platforms we can cover with a unified code base and player integration, the lower the debt for maintaining inidividual player adaptions on all client platforms - that in turn might give room for additional/different player integrations, like VLC and maybe an "mpv fiddler's player" which is entirely configured manually, but at this time we just don't have enough resources for spending on such things.

Thanks a lot for your understanding  

[Mazvydas 5]

No one from Emby side has yet to address the fact that in the Electron app source code it's obvious you CAN run the app without tv.emby.media and have a fully local app.

It's just that you both refuse to even acknowledge this, and stubbornly refuse to even talk about it.

I want a fully offline experience with Emby. I've paid for the license, I run it locally, I don't want any online requirements, including the Windows store and including tv.emby.media for runtime assets.

This is my main point I've been making since I made this post, and every time it has been ignored and some other sentence has been nitpicked.

Just bundle those runtime assets so we can have a fully offline self contained app, label it as unsupported and those who want it will be happy it's an option. Those who want a next next finish solution will not use it regardless.

[scottpro 10]

1 minute ago, softworkz said:

ET for Linux is the same Electron app like the old one for Windows and Linux users have been very dissatisfied for a long time. The upcoming Linux app is from the same code base as the new Windows app, which is fully cross-platform and supports a range of UI frameworks (UWP[Win,xbnox], WinUI, MAUI[Android,iOS,Mac,Tizen,WinUI], Electron[Win,Linux,Mac] - yes, there are four ways for running on Windows). 

The new Linux app uses the same MPV integration like the Windows app (and also works on Android in an internal test sample), so that might be not-so-good news for you, but the more platforms we can cover with a unified code base and player integration, the lower the debt for maintaining inidividual player adaptions on all client platforms - that in turn might give room for additional/different player integrations, like VLC and maybe an "mpv fiddler's player" which is entirely configured manually, but at this time we just don't have enough resources for spending on such things.

Thanks a lot for your understanding  

I think your plans for having external player support while integrating Emby overlays would be a great solution, provided you can get the render context from those external players.  The mpv.dll gives you that flexibility but limits the users to that Emby full control integration.  If the mpv.dll/exe could be treated as a external player than that would satisfy my needs.  Just a thought.

[scottpro 10]

4 minutes ago, Mazvydas said:

No one from Emby side has yet to address the fact that in the Electron app source code it's obvious you CAN run the app without tv.emby.media and have a fully local app.

It's just that you both refuse to even acknowledge this, and stubbornly refuse to even talk about it.

I want a fully offline experience with Emby. I've paid for the license, I run it locally, I don't want any online requirements, including the Windows store and including tv.emby.media for runtime assets.

This is my main point I've been making since I made this post, and every time it has been ignored and some other sentence has been nitpicked.

Just bundle those runtime assets so we can have a fully offline self contained app, label it as unsupported and those who want it will be happy it's an option. Those who want a next next finish solution will not use it regardless.

Technically you could setup a local proxy server and cache the web contents.

[softworkz 5065]

10 minutes ago, Mazvydas said:

Just bundle those runtime assets so we can have a fully offline self contained app,

Well,  that's what the new Windows app does. But those assets need to be kept up-to-date and that's why it uses Windows' MSIX update mechanism as a replacement for having the assets online.

[scottpro 10]

4 minutes ago, softworkz said:

Well,  that's what the new Windows app does. But those assets need to be kept up-to-date and that's why it uses Windows' MSIX update mechanism as a replacement for having the assets online.

True, but the ET legacy version can't run locally without the online connection.  The store app downloads those assets on updates but can run locally.  I think the main request here is, can we have the legacy version run locally with a asset bundle stored locally or on the Emby server?

[Luke 42077]

10 minutes ago, scottpro said:

True, but the ET legacy version can't run locally without the online connection.  The store app downloads those assets on updates but can run locally.  I think the main request here is, can we have the legacy version run locally with a asset bundle stored locally or on the Emby server?

That is the kind of duplicated effort that we're trying to avoid. Actually that's why we unified the two windows apps in the first place.

Even if we built this for you, we would not be able to do it just once. We would have to keep on doing it to ensure that it stays up to date with the server. We'd have to fix it when a windows update impacts something. We'd have to keep mpv updated. We'd have to update the code based on changes in mpv versions and to support new video features as they become available. We'd have to provide you with some kind of way to get notified when updates are available. All of these things that we've already done once we'd have to duplicate. 

I think softworkz's suggestion of an "mpv fiddler's player" option in the app makes the most sense.

[softworkz 5065]

9 minutes ago, Luke said:

Even if we built this for you, we would not be able to do it just once. We would have to keep on doing it to ensure that it stays up to date with the server. We'd have to fix it when a windows update impacts something. We'd have to keep mpv updated. We'd have to update the code based on changes in mpv versions and to support new video features as they become available. We'd have to provide you with some kind of way to get notified when updates are available. All of these things that we've already done once we'd have to duplicate.

Yea, and we must not forget about the core problem:

The kind of MPV integration with Electron in ET doesn't work anymore. Chromium has closed this way. So ET is already at an Electron/Chrome version from 3 years ago and will never be able to update.
We will make use of newer browser and JavaScript features over time, and sooner or later there will be a time when the Emby Client code doesn't run anymore on this old Electron version, then it is locked to the last Emby Client code version that works, and then there will be the final countdown running: until that version cannot connect to newer Emby Server versions anymore.

Whatever could be done, it always has a timer running, because it's definitely a dead end and the only question would be "when" it's finally dead.

 

Edited August 20, 2025 by softworkz

[Mazvydas 5]

26 minutes ago, softworkz said:

Well,  that's what the new Windows app does. But those assets need to be kept up-to-date and that's why it uses Windows' MSIX update mechanism as a replacement for having the assets online.

Cool beans. But evidently not everyone is happy using the Microsoft Store version. 

I'm asking for a legacy, unsupported, at your own risk, etc. locally portable version of the Electron app.

I can open http://emby.local and just watch it from my browser on LAN without an internet connection, but I cannot do that with the Electron app as the runtime assets are pulled from tv.emby.media

Just bundle those assets in to the app - why was this even a thing when the app launched in the first place? Were update mechanisms too advanced that the fallback was "let's just load assets from prod all the time requiring internet connection to view local media"?

 

[scottpro 10]

4 minutes ago, Luke said:

That is the kind of duplicated effort that we're trying to avoid. Actually that's why we unified the two windows apps in the first place.

Even if we built this for you, we would not be able to do it just once. We would have to keep on doing it to ensure that it stays up to date with the server. We'd have to fix it when a windows update impacts something. We'd have to keep mpv updated. We'd have to update the code based on changes in mpv versions and to support new video features as they become available. We'd have to provide you with some kind of way to get notified when updates are available. All of these things that we've already done once we'd have to duplicate. 

I think softworkz's suggestion of an "mpv fiddler's player" option in the app makes the most sense.

There are 2 issues here, one is the Emby Theater app (legacy version) itself and second is the online assets.  The bundled assets would be updated every time you update the online assets.  That could be downloaded by the Emby server as needed.  The Emby app is a separate issue, which includes the mpv player and ET system components.  The mpv player is not updated though the online assets.  You pretty much have all the components in place for this.  In fact, the URL for the online asset location is commented out for local host testing.

Just an observation.

[softworkz 5065]

RELATED TOPIC  

Now that things have calmed down a bit, I have taken time discuss and explain the background of choosing MS Store for app delivery here in more detail: