Should Plex and Emby be moved over to docker rather then jails...thoughts?

Status
Not open for further replies.

Magnus33

Patron
Joined
May 5, 2013
Messages
429
Though the jails are fairly low over head which is great for the likes of sickrage..transmission or sickbread its less then ideal for plex and emby.


The others are simpler and come with a auto update feature which means you can basically install , setup and forget.

Plex and Emby are constantly being updated at a faster rate then every which eventually causes issues between the newer clients and the outdated servers.
At present updating is dependent on a dev porting them over which tends to only happen if its reported in the bug hub or he/she notices.

Unlike with docker which is much more widely used and updated constantly.

Methinks that the media servers would be better served by docker then in jails.


Thoughts...arguments..world domination tips?
 

warriorcookie

Explorer
Joined
Apr 17, 2017
Messages
67
I like that docker has resource allocation and a very wide base of support. But it is certainly not as mature as jails, especially on FreeBSD where it's still experimental, and everything is run as root. For the near future, on a production system, I'm still going to opt for VM's for anything that's not suited to a jail.

Also, I was under the impression that Docker on FreeBSD has much more overhead than running on a Linux distro as there's a Linux compatibility layer.
 

Magnus33

Patron
Joined
May 5, 2013
Messages
429
True there more overhead.

At this point though jails are certainly more mature they have quite a small user base compared to dockers so updating and development is much slower.

As for plex and emby its seemed more then stable enough for the job.

As things are i don't think plex or emby in jails is going to remain feasible do to the increased updating they are doing.
Without a auto update feature or constant porting over by a dev it gets rapidly outdated.

With the clients being updated almost weekly now this is causing issues with outdated servers in plex.

The possibility of a autoupdate feature is unlikely at best since that's normally built in by the makers and not something freenas itself does.

Last time it was five versions behind which is hardly the fault of the dev's as its not there job to sit there and monitor it but a sign that the present system of updating it just isn't up to the job anymore.
 
Joined
Apr 9, 2015
Messages
1,258
Honestly for updating I'm not super worried about being on the bleeding edge for something like Plex. I have a plexpass so I do get some new features sooner than others but my install from FreeNAS 9.3 is still on something like 1.3.3 and it doesn't bother me other than it's a little slower. There are also scripts that can be setup to auto update the jails or just plex on it's own but then it's probably a good idea to snapshot the jail ahead of time so you can roll back if and when issues pop up. And trust me they can and will happen. That added with the increase resource usage of docker along with needing to run it in a vm and I will stick with the jails unless something comes around with the same resource footprint or better with the same functionality or better and honestly docker is not it.
 

garm

Wizard
Joined
Aug 19, 2017
Messages
1,556
You aren't stuck with the plugin jails either. Nothing stop you from running a standard jail and installing what ever you want. The ports tree is usually up to date on plex. Then you can have Crontab do the updates for you if you want "auto" updates.

I was also stuck on docker from the Corral but the inability to attach a dataset with a VM in 11 is a deal breaker for me. Sure it can be done with NFS but still..
 

Magnus33

Patron
Joined
May 5, 2013
Messages
429
Bleeding edge isn't really the problem these days but rather the gap between the various clients and server end.
Before the last update the server was 5 or 6 versions behind and that eventually starts causing issues with the updated clients.

The clients are being updated so often that they require the server to be also or issues start popping up in playback and the like.

Yes i agree there is nothing stopping installing running a standard jail and doing as we wish but for the average joe that's really not a feesable alternative.

I think at this point docker is the likely future for stuff like the servers that require themselves to be reasonably up to date with the clients.

Though it does remain to be seen how docker is going to work is at all in freenas 11.1
 

danb35

Hall of Famer
Joined
Aug 16, 2011
Messages
15,504
I understand that the new iocage jail system should result in the plugins staying much more up to date. Dockers are inherently going to run inside a VM, which means they'll be resource-constrained. For something like Plex, that doesn't sound like a good idea.
 

Magnus33

Patron
Joined
May 5, 2013
Messages
429
They could also add a option to have the plex update be linked to say the plex update script.

Plex is going to pop up and tell people there a new version anyway.

All that would be required is that they would be to have the version in the installed plugins reflect this.
 

Magnus33

Patron
Joined
May 5, 2013
Messages
429
You aren't stuck with the plugin jails either. Nothing stop you from running a standard jail and installing what ever you want. The ports tree is usually up to date on plex. Then you can have Crontab do the updates for you if you want "auto" updates.

I was also stuck on docker from the Corral but the inability to attach a dataset with a VM in 11 is a deal breaker for me. Sure it can be done with NFS but still..


I did always did wonder why they didn't go the script route for updating plex.

Having a script run at a set time to check for a update directly from plex and then downloading it would allow for auto updating .
A option for the user to set a time during the day to check so as not to cause media interruption would be ideal.
This would remove the need for a dev to have to port things over for updates.

I imagine they had reasons for not doing so.
 

danb35

Hall of Famer
Joined
Aug 16, 2011
Messages
15,504
I imagine they had reasons for not doing so.
I expect so. A likely candidate for the reason is that having a script make untracked changes to the jail's contents isn't exactly consistent with the concept of a plugin.
 

Magnus33

Patron
Joined
May 5, 2013
Messages
429
True but requiring a dev to port it over is not a long term solution at this point.
 

Magnus33

Patron
Joined
May 5, 2013
Messages
429
That i think people need to ask for a change as they are the ones who fuel things.

Just like plex recently found out you have to keep the consumers happy.

While FreeNAS is free it fuels development for the business end of things.
 
Last edited by a moderator:
Joined
Apr 9, 2015
Messages
1,258
That i think people need to ask for a change as they are the ones who fuel things.

Just like plex recently found out you have to keep the consumers happy.

Will freenas is free it fuels development for the business end of things.


So here is where we are at then. The FreeNAS project does not control the pkg or ports system nor do they control the docker system. So honestly if you want things to happen on a faster schedule you have three options.

  1. Complain to the pkg and/or port maintainer
  2. Complain to the docker maintainer
  3. Build it yourself
  4. Plus who knows how many other options I just don't feel like thinking of.
FreeNAS is just able to use these resources as the OS is based off of FreeBSD. Honestly the vast majority of people are happy with things the way they are and have been. I along with many others would prefer functionality and stability over pretty and bleeding edge. I sync things with my Plex install that is version 1.3.3 to android apps that are the latest and greatest version and have ZERO issues. I also stream from the same server to a smart TV based plex app with zero issues. And while I am on FreeNAS 11 and have a jail setup with the latest version I have not switched over since when the change to iocage happens I may have to rebuild yet again and don't feel like futzing with a bunch of stuff to have to do it over again in a month especially since it all works.

Right now your argument seems to be the sort of a "Hey this free cake isn't up to my standards so put some more into it so I am happy about it and by the way I will eat this piece too while I wait for the better one." If you really think there is a better way of doing things then by all means feel free to head over to the bugtracker and submit how it should be done and work on the project while you are at it. But just make sure another "Corral" isn't in the making.
 

zhnu

Dabbler
Joined
Aug 24, 2017
Messages
19
Though the jails are fairly low over head which is great for the likes of sickrage..transmission or sickbread its less then ideal for plex and emby.


The others are simpler and come with a auto update feature which means you can basically install , setup and forget.

Plex and Emby are constantly being updated at a faster rate then every which eventually causes issues between the newer clients and the outdated servers.
At present updating is dependent on a dev porting them over which tends to only happen if its reported in the bug hub or he/she notices.

Unlike with docker which is much more widely used and updated constantly.

Methinks that the media servers would be better served by docker then in jails.


Thoughts...arguments..world domination tips?

In my experience docker is easier to setup maintain and keep your configurations clean and detect problems example: https://forums.freenas.org/index.php?threads/how-to-docker-setup-examples.53975/#post-402640

Although bhyve misses one feature I really want (VGA passthrough) for hardware acceleration on transcoding I run all my "plugins" now via a bhyve VM running ubuntu with docker-ce and a nfs share to my data.
Jails are a nice concept but part of the problem is that the bsd ecosystem doesn't get as much support as the linux counterpart.
Having said that beware docker as anything else has problems, (I have manage several times to get containers "stuck" and the only way around was to restart the daemon not a problem for home services but a problem in production environments that don't run in a swarm cluster) and some containers still need system settings to be tweaked to work properly (ex: elasticsearch), but in the end of the day after many years using multiple solutions for home (native/VM, jails, docker) I prefer docker to all the rest and overhead can be ignore simply because this are not critical services that require all the maximum performance 24/7 (like a db).
 
Last edited:

Stux

MVP
Joined
Jun 2, 2016
Messages
4,419
It basically comes down to:

Plex for Linux and thus Docker has more features than Plex for FreeBSD.

Plex in a Docker on FreeNAS, requires a Linux VM to host docker.

Plex in a jail runs in the same process space as everything else.

The docker encapsulation is cleaner.

The jail means Plex has full access to all the CPU and RAM resources of the host system. Where as plex in a VM has only access to the resources which are allocated to the VM.

On the one hand, that means Plex in a jail could be more performant, but on the other hand, it means if plex runs out of control it could starve the rest of the system of resources (say a memory or cpu process leak)

But on the grabbing hand, memory allocated to a VM tends to get wired down...

Swings and Roundabouts.
 

zhnu

Dabbler
Joined
Aug 24, 2017
Messages
19
It basically comes down to:

Plex for Linux and thus Docker has more features than Plex for FreeBSD.

Plex in a Docker on FreeNAS, requires a Linux VM to host docker.

Plex in a jail runs in the same process space as everything else.

The docker encapsulation is cleaner.

The jail means Plex has full access to all the CPU and RAM resources of the host system. Where as plex in a VM has only access to the resources which are allocated to the VM.

On the one hand, that means Plex in a jail could be more performant, but on the other hand, it means if plex runs out of control it could starve the rest of the system of resources (say a memory or cpu process leak)

But on the grabbing hand, memory allocated to a VM tends to get wired down...

Swings and Roundabouts.

A couple of points:

You can limit a jail resources with rctl, the memory used by a VM is not always hardwired (you can setup a max limit and is allocated dynamicaly Xen hypervisor does this for some hosts), and in the very near future the transcoding process will most likely depend alot on offloading the hard work to a GPU (4k/8k etc very demanding on the cpu, piece of cake on a relativity inexpensive gpu ex: Nvidia p400 can transcode 4k/8k Hvec/H264 as per Nvidia nvenc SDK chart, costs only 130e occupies single slot and only consumes 30w).

So personally I would go for docker because I trust that bhyve will have sooner or later VGA passthrough and offers something others don't portability, clean configurations and more support.
 
Joined
Apr 9, 2015
Messages
1,258
Too bad that even after a year hardware encoding for Plex is still in the Alpha stages. In two or three years when 4k is mainstream and 8K is starting to get some content available that may be worthwhile. But by that point in time it may be just as easy to do it with a jail.

For now I will stick with simple tried and true. Not to mention that the whole point of 4K or 8K is for quality and a hardware device like a video card has a decent potential to come out looking a little worse for the wear. Right now when I DO have 4K content (which is basically the same thing I do for 3D content) is build a library just for that content and transcode something permanently in 1080p for the rest of the devices to use. I can watch 3D stuff on my phone with a viewer but there is really no point in using my phone, tablet or 1080p tv for 4k content just to burn power to transcode on the fly. I also have to guess that as the cpu's get more powerful/more parallel applications that transcode will be compiled to handle more threads along with microarchitecture additions, by the time we are actually working with 8K on a regular basis it may be irrelevant worrying about hardware encoding.
 

zhnu

Dabbler
Joined
Aug 24, 2017
Messages
19
Hardware encoding is here to stay, on plex or emby works well (although still green) I don't know if you notice last couple of years the core count on mainstream CPU's hasn't been increasing exponentially, plus intel solution to video transcoding Quicksync requires dedicated hardware for it just like nvidia nvenc, and it's kind of pointless to waste CPU power transconding when you can do the same cheaper and with a dedicated solution. The quality difference on the transconding part depends more on the profile used than anything else, and it's kinda pointless replicating the same video on different resolutions if you're only going to watch it occasionally, you can already use multiple threads to encode stuff and both emby and plex have done it for years (both use ffmpeg for this) but just do a simple test encode hvec (this saves you alot of space and bandwidth) and them tell me how your cpu did against a 130e GPU.
 

Magnus33

Patron
Joined
May 5, 2013
Messages
429
There are good points for both but i think having media servers in dockers makes more sense then in jails.

There are two other reason besides the ones mentioned.

Docker have way more development going on behind them so things improve faster where as jails have basically stalled compared to it.
This is of course due in large part to the environment that they are in with linux getting for more development.

Updates for plex come far faster for docker then they do for jails.
Jails tend to be only updated if its mentioned in the bug area or it gets noticed since its one guy doing it.
Its not like he sitting there waiting for this since he got a life like the rest of us ;)

The points in favor of moving them to docker are quite a bit more then having them remain in jails.

There is more overhead but frankly unless your running a low power system that's not going to matter much with today's hardware.
 
Status
Not open for further replies.
Top