Search the Community

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 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".

I've always liked the snap feature since it was introduced in Vista (or was it W7) but it is so much better now. Four way snap is nice but the intelligent suggestion after you snap is very helpful. I use(d) it more on my small screen laptop since on a large screen I prefer to have overlapping windows. But that also brings me to my favorite new feature in Win10. And that's the fact that metro/modern apps are in a window now. No longer does Skype have to be full screen or snap to a 30% of my screen if I want to run it and see people (ignoring the desktop version of Skype in this example). Now I can have 5 metro apps open on my desktop just like traditional Windows apps. The metro app model is actually really great since those apps all run in their own sandbox. This adds a layer of security to apps that was never present before in Windows. On top of that developers are being encouraged to design them in a responsive manor so not only do they run better on different screen sizes but they handle being resized very well. I haven't played with virtual desktops on my laptop much other then just testing the functionality. It works really well and I will most likely use it a lot on my desktop where I tend to have work and play stuff open at the same time. It's nice to be able to separate the programs/windows that are displayed. I also think it will be more useful once you get used to the keyboard shortcuts CTRL-WIN-LEFT/RIGHT so you can very quickly switch.

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

Tomimc, Have you looked into bind mounts to get around this issue? Bind mounts will let you work around rude applications that don't like symbolic links. Here is an example of my fstab on a nextcloud host (doesn't like symlinks and I don't take no for an answer) nas.local:/mnt/volsata01/nas/nextcloud /mnt/nas/nextcloud nfs rw,hard,vers=3,mountproto=tcp,_netdev 0 0 /mnt/nas/nextcloud/data/__groupfolders /var/snap/nextcloud/common/nextcloud/data/__groupfolders none bind,_netdev 0 0 /mnt/nas/nextcloud/data/firstname.lastname /var/snap/nextcloud/common/nextcloud/data/firstname.lastname none bind,_netdev 0 0 This was a lifesaver for me but I can't believe how rarely they're brought up when asking questions similar to yours. Basically this creates one nfs mount, then takes subdirectories in that mount, and mounts them as if they were local filesystems. You can use the same logic for a local filesystem as well, but in this instance I used NFS. It's not as clean as symlinks for sure, but it gets the job done and is fairly manageable. Hope that helps!

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.

I don't think it's so much about the info on the pages but subtle things like not aligning if you put a grid over it like with the red borders which show how some things are too far right or things that should be flush left or flush right aren't. Think "snap to grid". That and if you saved the position of things on one page in movies but then went to TV Shows it's different yet, then music is yet again different. It's not consistent in position when it can be for different parts of the clients. Obviously different parts of the system have different needs but some things should be the same but aren't. That's my interpretation of what was said.

Both are still maintained. We've never been listed in flathub or snap's store yet but we're working towards that. For now you'd need to install the downloadable packages.