Search the Community

Very cool. I'll echo the Flatpak request (as opposed to snap or appimage). The Kodi Addon experience isn't quite the same as having a native Emby Theater application. Edit: Running Fedora here, I can't get Alien to cooperate with the existing .deb.

@ Luke: Or could we please, please have a flatpak version? Or an AppImage or even a snap? That way we wouldn't have to worry about about the specific distro or version thereof. I have to think it'd make life easier for you, as well. Surely, it'd decrease the required maintenance and support on your end?

Linux repositories are just locally stored files, shared to the public, and can be located anywhere, like GitHub. Don't have to be "approved" like flatpak, snap and docker. Very easy to setup. My vote is for Debian first https://wiki.debian.org/DebianRepository/Setup

Correct me if I'm wrong, but the only way the Emby server can be auto-upgraded is to run it on windows, right? The emby packages for native linux, flatpak, snap and docker are all manual downloads, and not in a repository that can be auto-upgraded from? Thanks

Hi All, I've been trying out using the Windows store version of Emby Theatre due to its superior resizing and ability to be snapped to the edges of my display (I would use the regular Emby Theatre if it had a regular windows title bar with functioning snap). Anyways, I've found that this version of Emby Theatre cant natively play any kind of subtitles I've used (ASS, PGSSUB, DVDSUB). Is this just a limitation of the player within the app? Is there any future plan to allow this version of Theatre to correctly play subtitles without burning them in? Thanks!

We have the packages built already but snap doesn't work well with the .NET core runtime as it blocks certain things from working. We had a back and forth dialog with snap about it but they kind of stopped responding to us about it and eventually I stopped bugging them. The packages only work when built in developer mode. When built using their strict mode, they're blocking the net core runtime from being able to load.

Hi Luke, Just checking on snap store for Emby?

Even giving the user the ability to choose tabs, it is still a question of space as we'd have to limit the number they can choose. But, that is our ultimate goal. It just doesn't happen with a snap of the fingers. We are a large, complex set of programs and apps and there are a lot of things we are working on. This is just one of them. Thanks.

If I shrink to about half the size for the browser window, the images snap to the same size.

I'm just grasping at anything that may have an effect. No cache would have any bearing here. The size of the images on disc is not related to their display size. The UI is deciding how large to make those. What happens if you adjust the size of the browser window? At any browser size, do the images all snap to the same size?

Any chance you could snap a pic or two of how it's done on the Samsung?

That almost sounds like things around here. Put in your order, grab your seat, maybe a snap or two of the fingers. I then rush off to the kitchen, get everything ready and serve the "crowd".

The Roku also has this same quirk. Press back once to snap to top. Press back again to exit. If you are already at top and press back one tap will exit. It is to make it easy to get to the top without having to exit and enter that same view. An easier way.

Before looking at the server log can you play this back again and take a snap shot of Stats for Nerds from the Shield (on the cog menu)? If there is an ffmpeg log generated for that time please upload that as well. Otherwise let us know the episode/movie being played so we know what is played in the server log. Thanks

So how come it is in both libraries? Have you linked the folder containing it into both? If so that's the cause, as this is not supported and does not work right. You need either to copy the file, or to use a strm file as a link. (EDIT: snap!) Paul

I haven't actually used playlist, but on mouseover you have sliders just like with 'Actors' or People section and 'More Like This' thanks to the way that Happy2Play modified the CSS. So you can scroll. and this works in certain ways.. The way the page is written for the WebUI, it accommodates varying screen size and resolutions, therefore has no fixed-width.. so that it is scalable.. so without additional code it, moves around when resizing, during browsing.. may have to be customized slightly between different setups, browser window size and resolutions. Mine does well between full screen and windowed size without too much problem.. BUT if I snap it to one side of my screen it gets a little cramped.. and alignment changes. Switching between a px ( or exact pixel distance from ) and % ( from, given total screen real estate ) alters its behavior and additional indicators could be used in the CSS to alter the behavior more but I haven't played around with it that much. Your zoom on your browser also can apply. In Edge I use 75% for example because I feel like I am always staring at HUGE fonts. The things I am mentioning are basic parameters/consideration when creating a web page. With a WebUI for Emby; it is written a little differently so that it fills the page, which is what you definitely want for appearance and variables, in this case. With a web page other things may allow you to actually indicate a fixed width like I mentioned above.

Snap. Movies > Filter > Studio > Marvel Studios > Select All > Add to Collection. Emby rules, but I was surprised that TheMovieDB didn't have one. Never mind... 'tis done now

snap

Hi Luke, Any ETA when Emby will be in Snap store?

Howdy everyone! Just wanted to report back. Sadly, looks like Primocache wasn't the issue. It looks like I need to reboot emby at least once a day to keep it "fresh", otherwise, it starts to slow down on all clients both locally and remotely. The movies stream fine, but browsing through emby has noticeable delays in between selections. The second I restart emby, everything works like a snap! I can confirm these symptoms happen both with the system being busy adding new media, or just sitting idle only serving requested media. Emby is the only application on the server showing these symptoms. It's a fresh install of Windows Server 2016 on a beefy server, so I'm 99.9% confident it's not the environment. The only other thing I can note is, right before I restart emby each time, it always appears that the memory is hovering around 900mb of usage, not sure if that matters. @Luke, I'm PM'img you some fresh logs in the hopes they give you more clues

I've created AppImages, and Snap file here : https://github.com/romainrbr/emby-theater-electron/releases/tag/3.0.12 With a PR created on the main repo to be merged : https://github.com/MediaBrowser/emby-theater-electron/pull/90

Idk about you but to my recollection of a decade and a half or so, fragmentation and packages for different distros has always been an issue. I get that you don't like extra overhead, I don't either, but I would much rather have an app be a flatpak or snap than not at all. MS teams is a perfect example. It downloads the things it needs and tbh you would be downloadinf dependencies anyway from a native install.

I will always install native packages, no conversions or container like Snap, Docker, Flatpak ...

There's not a lot a CDN will do for you with Emby except to cache your images. CloudFlare does NOT do this by default unless you create a rule to do this. Depending on the area you're users are logging in from a CDN can work against you and you could be far better off running your own reverse proxy for caching but it depends. As an example as I was on Verizon with Fiber and had hundreds of mb of upload bandwidth so I ran my own reverse proxy for caching images. That took the burden off Emby to deliver the graphics and made things SNAP. Anyone on Verizon in my family never actually hit the internet when accessing my server as it was all handled by Verizon backbone. Now I'm on Xfinity/Comcast (car took down a pole and Verizon would not re-run fiber as I was the last house on the line) with a crummy 18 mb upload bandwidth so anything I do to not serve graphics from my server is good. I now use CloudFlare as a CDN and turned on image caching so when Emby apps or web browser view my library all the graphics are served by CF making it appear fast. With transcoding or direct play I can still serve up a couple of remote sessions but browsing is FAST. So it DEPENDS and no right answer. But if your family/friends are getting to your server using the same provider you use then they aren't actually touching the "internet" and are on the ISP backbone so a reverse proxy is likely best assuming you have good upload bandwidth. With that said, for commercial apps I've developed in the past including a few big systems I typically use https://www.akamai.com/ It's not really appropriate for an Emby system but more for a Netflix or Amazon Prime. You will pay out the wallet big time for it as well. CloudFlare should do what you need for Emby or consider nginx for self hosting.

It's actually the best solution possible as no transcoding is needed and you get perfect playback by using media designed especially for the resolution and bitrate. Don't know how much you know about adaptive streaming done by all the major websites but there is a different file for every possible resolution and bitrate. It's not uncommon for each movie or TV Episode on their sites to have been master 12 different ways and that was with 1080 media. When you get into 4K you're adding additional version of the same media. You don't think Amazon and Netflix have one version of the media and convert on the fly do you? No way, they pre-convert the different versions, store them all so no real-time transcoding takes place. When you convert in real-time you ARE loosing quality compared to a proper conversion that takes how ever long is needed which could easily be 4X to 5X run time length. You can only do so much trying to process video quicker than it's consumed and that's just with one stream. What if you have 3 or 4 transcodes going? HW/GPU helps on the speed front but still is no where near as good as CPU based conversions. BTW, it's the same way with YouTube videos as well. There are multiple versions of each file so any client can "direct play" a single version. Emby does a fantastic job with 1080 and lower resolution files on most average hardware and even does 4K SDR conversions quite well given a decent CPU/GPU but when you get into having to change every pixel color along with everything else you need to do to transcode in REAL-TIME it's near impossible on average consumer hardware for a Server. The display/client side is a different story as it only need contend with one stream. It's one thing to do tone mapping or similar type thing on a PC or device like a shield TV with dedicated hardware and quite another on a server sending streams to rokus, cell phones, web browser, dlna, TVs, etc and that's just the "pure video" conversion. Now imagine having to factor in subtitle burn in on top of this, converting to h.265 or h.264 depending on client. It's a massive amount of processing. So while many are spoiled with Emby's ability to transcode on the fly for 1080p and lower SDR content, 4K HDR is another ball game you've stepped into and takes proper admin planning for these files and how they will get used. For most people a Bluray rip of 4K HDR material is usable only on LAN and not remotely (most not all). You could certainly also master a much lower bitrate version such as 8 to 10 mbps 4K HDR to have much better luck streaming remotely (like what Netflix and Amazon Prime due). But as stated previously you want the 4K version to be the 2nd version added to the system with a 1080 version being the primary so it's the main file used or transcoded from vs the 4K HDR version which for now should never be transcoded. Will this change in the future? Sure, with newer approaches, newer algorithms, newer GPUs that can do this in HW but Emby can't snap it's fingers and make this work across the board for every Emby Server, as it's just not possible at present. If you think of transcoding as a crutch to having proper versions like Netflix and others have it helps with understanding what can and can't be done with transcoding. Transcoding can convert certain video codecs in real-time, it can convert basically any audio format to another and can convert most subtitle formats to other formats to make them compatible with the client. It can even repackage this into a different streaming container. But even before getting into 4K media transcoding has issues with certain codecs that many machines can't handle like VC-1. Even when it can do this transcoding it's not optimal for all clients. For example if you have only 6 mb bandwidth to the client and the device/client can use h.265 that would be the optimal target for conversion of video as quality is better than h.264 for the same bitrate but that's far more CPU intensive and not all GPUs can convert to h.265 while most can decode it. That plays into 4K as well as one of the popular video codecs is 10 bit H.265. So real time transcoding of 4K 10 bit H.265 mostly likely has to downgrade resolution to 1080 or lower, has to massively reduce the bitrate used while also using a less efficient codec like h.264 while changing the 10 bit to 8 bit and that's even before having to tone map color changes, burn in subtitles or touch/modify audio. The moral of the story is that if you want 4K media in Emby and want things to work smoothly you add a 1080p version first to your standard movie library, then add the 4K media to it's own 4K library where only people with the ability to play it back direct can access it. None of this is meant to be an excuse, but just the reality of where we are industry wide of what can/can't be done and how other system handle things. In today's streaming setups you sacrifice storage which is cheap compared to CPU to accomplish different streaming resolutions.