Emby Server

    • Offizieller Beitrag

    Emby have changed their repository for Emby and subsequently updating, the opensuse rep is now legacy, the only way to update this now is either, manually update which I have tried and failed even though I removed the 4 config files, or uninstall and purge then install the new version :(


    So having searched the forum it appears that Docker is the way I should do this, I already have Docker installed having followed @flmaxey pi-hole, so is there something similar for Emby or can someone help me out.....I've read the Docker Emby....'it seems' to make sense. :/


    I also need to remove the current installed version via the apttool, which I am guessing will need or should be purged if the removal doesn't do this.


    Thanks.

  • What have you done now? I think as well, that docker is the way to go (from reading the forums) but don't have any experiences with it yet. So I probably will have to do some reading first, backing up my emby data and then giving it a shot.

    • Offizieller Beitrag

    What have you done now? I think as well, that docker is the way to go (from reading the forums) but don't have any experiences with it yet. So I probably will have to do some reading first, backing up my emby data and then giving it a shot.

    At present nothing :) but I'm about to start today as I want to upgrade to omv 4, but someone had pointed to an excellent you tube video, albeit in German it was easy to follow :) if the upgrade goes well I shall follow that but I shall use WinSCP rather than install Midnight Commander.

  • What has happened?


    I used the repo and now just updated to 3.4.1 by downloading the den and just installing it.
    I personally find it easier to install nd less likely to have problem natively without docker

    • Offizieller Beitrag

    What has happened?


    I used the repo and now just updated to 3.4.1 by downloading the den and just installing it.
    I personally find it easier to install nd less likely to have problem natively without docker

    Well the upgrade is going pear shaped so I've not done Emby yet, but according to the Emby forum to update to the new version you have to uninstall then reinstall for the new version to work, hence the Docker option.

  • That's what I've done now. Created a backup, purged the old install, installed docker, then emby docker and watgchtower docker as described in the vid. However i added some more passthrough folders (for backup, metadata, ssl cert). Within 5 min all was done... piece of cake. I have just one little problem. Till now I haven't got ssl working (neither lokal nor remote -- that doesn't work at all).
    The rest is running smooth as butter.

    • Offizieller Beitrag

    That's what I've done now. Created a backup, purged the old install, installed docker, then emby docker and watgchtower docker as described in the vid. However i added some more passthrough folders (for backup, metadata, ssl cert). Within 5 min all was done... piece of cake. I have just one little problem. Till now I haven't got ssl working (neither lokal nor remote -- that doesn't work at all).
    The rest is running smooth as butter.

    :thumbup: That's good to know, gonna have to do mine tomorrow now as VBox was causing some issues after I shutdown to backup OMV to an image. I backup my Emby using remote mount on a Pi works well.


    I didn't watch the vid all the way through as I had no idea what watchtower was, so did a search and it just might be worth installing.....the only container I run at present is Pi-Hole which I want to update, but I can't do that unless I update to OMV4 as I'm using the dnsmasq plugin and the latest Pi-hole requires the latest dnsmasq in Stretch.

    • Offizieller Beitrag

    So for your scenario (as I understand the above), you need Emby in a Docker, using OMV4.0? (As I recall, I had Emby working in a Docker before.) Do you know if there's a huge difference between the paid Emby and the free version?

    • Offizieller Beitrag

    So for your scenario (as I understand the above), you need Emby in a Docker, using OMV4.0? (As I recall, I had Emby working in a Docker before.) Do you know if there's a huge difference between the paid Emby and the free version?

    Hiya :)
    The paid version gives you a number of extras/apps to use with tablets, smart tv's fire sticks, xbox, ps4, and loads more, basically what you see when you connect via chrome.....similar to Plex.

    • Offizieller Beitrag

    I configured an Emby Docker in OMV 3.X. All appears to be functional. If you're interested, you could backup your USB boot stick and give the following a try. Remember, Dockers are a non-invasive way to add a server function so if the following doesn't work, delete it.


    The image following is the official (supported) Emby Docker image for x64 hardware. While I don't know for sure, I believe this container will update in place. Even if it won't, much like Pi-hole, the configuration is on the host so it should be persistent even if a new image is installed.
    __________________________________________________________________________


    First you want to "pull image" with the following:
    repository------------------------tag
    emby/embyserver---------------latest



    The following is 2 screen captures for filling in the run image dialog.


    Notes for screen 1:


    - Bold entries require the shown edits.
    - The UID and GID are numbered so as not to conflict with existing Dockers.
    - For copy and paste purposes, for the device in Environment Variables:
    DEVICE /dev/dri/renderD128




    Notes for screen 2:


    - The first Host Path stores the Emby config so that your settings are persistent. The left side (at the root of the boot drive) can be anything but avoid selecting an existing location.


    - The second and third lines, /music and /videos folders, under Container path, are examples. You probably have more folders than the two shown. Create as many as you like. You'll find these folders, created on the container path side, inside of Emby when you set up media locations.
    - As you create the locations; /music on the inside of the container maps to a location on the outside of the container (on the left side below - Host Path). Use the folder icon (highlighted yellow), to navigate to your data drive and set it your music share. Remember, you have to click on the check box and see a new blank line, to insure the Bind point has been accepted.
    Repeat the process as needed for /Videos, /Movies, etc.


    -For copy and paste purposes put the following in Extra args:


    -p 8096:8096 -p 8920:8920




    ____________________________________________________________________________


    Since you know far more than I do about the function of Emby server, let me know how it works for you. If all is well, I suppose I could write up a How-To. (I have to say, it looks good enough to where I'm considering adopting it.)


    I don't think an Emby/Docker build will care about whether OMV 3 or 4 is in use. (Dockers have all dependencies built in.)


    Again, you can test this with a cloned boot stick with no consequence. BTW: you could do an OMV version upgrade to 4.0 with an extra stick as well, just to see how it goes.

    • Offizieller Beitrag

    Notes for screen 1:


    - Bold entries require the shown edits.
    - The UID and GID are numbered so as not to conflict with existing Dockers.
    - For copy and paste purposes, for the device in Environment Variables:
    DEVICE /dev/dri/renderD128

    Ok, the above is not added in the You Tube Vid I found.....so here's the dumb question what/why?


    - The first Host Path stores the Emby config so that your settings are persistent. The left side (at the root of the boot drive) can be anything but avoid selecting an existing location.

    Again that is different to the Video as it stores the config (I assume) inside the container.


    - The second and third lines, /music and /videos folders, under Container path, are examples. You probably have more folders than the two shown. Create as many as you like. You'll find these folders, created on the container path side, inside of Emby when you set up media locations.

    So by doing this you are creating a symlink to the folder outside of the container, is that necessary? why not just map the data volume.
    One of the options in Emby is the 'cache path' which holds the cache, metadata and transcode temp folder.
    Also by adding the host path and container path they will have to be the same, i.e. Movies>>>Movies not Movies>>>>movies otherwise (if now Linux) this will not work.


    For copy and paste purposes put the following in Extra args:


    -p 8096:8096 -p 8920:8920

    I wondered where those went.


    In reference to the Host Path>>>>Container Path there would be nothing stopping you from just adding the data volume where everything for Emby is stored as the configuration is done once you login to Emby and provided Emby can 'see' the volume that's all it needs.

  • most is explaned here
    https://hub.docker.com/r/emby/embyserver


    If you want to let emby run under its own user (as I do), you need to create an emby user first and find out its uid (id -u emby).
    My emby user is in the users group. Its gid is 100. If you want a dedicated group 'emby', you need to create it and add the emby user to it. Now find out the gid (getent group). Keep in mind that your user/ group should have access to your media.
    Now you have the uid and gid to enter into the docker emby-server container setup.


    The gidlist should be the video group gid (as described in the above link).

  • After writing about uids and gids I checked my certs permissions and guess what... now my remote connection works, too.
    My extra args look as following
    --publish 8096:8096 --publish 8920:8920
    but I'm sure -p xxxx is working as well. Last thing I have to check if working is the transcoding. Maybe someone has an idea how to do that... cause I think on demand transcoding never has worked here before.

    • Offizieller Beitrag

    My extra args look as following
    --publish 8096:8096 --publish 8920:8920
    but I'm sure -p xxxx is working as well.

    In Linux -h = --help. In this case -p is the same as --publish.


    Given the network mode I used "HOST", ports are published 1 to 1 by default, so it might not even be necessary to publish ports. However the Docker author recommended it and adding them to Extra aug's is no big deal.


    Ok, the above is not added in the You Tube Vid I found.....so here's the dumb question what/why?

    I didn't look at the youtube video. The video might not be configuring the same Emby Docker. Also, where it's important, I go with what the Docker author recommends.


    As stated above, when Docker containers are created from images and they need a UID (user ID) or a GID (group ID), they usually assign the first available numbers (UID 1000 & GID 100). While my numbers were arbitrary, using 1111 and 111 respectively would prevent a conflict if another Docker is in use, or if another one is added, that requires a UID and GID. (The defaults are usually 100 and 1000.)


    On the DEVICE statement - it's required by the author of the Docker -> emby/embyserver The Docker might work without it but the VAAPI rendering function may not work.



    Again that is different to the Video as it stores the config (I assume) inside the container.

    It will work without mapping the /config folder to the outside (which makes it persistent). The problem is, if the container is restarted, all your configuration work is gone. Without the mapping, a container restart means it's a new day zero install.



    So by doing this you are creating a symlink to the folder outside of the container, is that necessary? why not just map the data volume.One of the options in Emby is the 'cache path' which holds the cache, metadata and transcode temp folder.
    Also by adding the host path and container path they will have to be the same, i.e. Movies>>>Movies not Movies>>>>movies otherwise (if now Linux) this will not work.

    Dockers are designed to isolate the container from the host.
    (This is something I wrestled with when learning to configure Dockers.)


    If you want to get files in and out of the container, Volumes and Bind points are necessary. They're, in essence, a type of symlink. They map an inside folder (on the container side - you'll be able to find this folder inside Emby) to a location outside of the container, on the HOST side. That data itself actually "exists" on the HOST side. If the container dies, the data is still there on the HOST side.


    If you have media folders on your server, on the data disk, simply set the location on the Host side and they'll map into the container to a folder name of your choice. (When the container is saved, the inside folder is created, if it doesn't already exist.)


    If you use RemoteMount, to mount a remote filesystem, the outside media source on the Host side doesn't even have to be local. It can be on another PC.
    __________________________________________________________


    The cache path folder is inside the container which is still on your boot drive. Depending on the size of your media collection - it might make sense to map the temp folder to a location on the data drive (I.E. not on your somewhat small boot drive). That might need some followup. What's the default cache path?

  • As stated above, when Docker containers are created from images and they need a UID (user ID) or a GID (group ID), they usually assign the first available numbers (UID 100 & GID 1000). While my numbers were arbitrary, using 111 and 1111 respectively would prevent a conflict if another Docker is in use, or if another one is added, that requires a UID and GID. (The defaults are usually 100 and 1000.)
    On the DEVICE statement - it's required by the author of the Docker -> emby/embyserver The Docker might work without it but the VAAPI rendering function may not work.

    From what I've seen till now: the UID and GID are the user and group ids the docker is accessing data on the hds and have nothing to do with avoiding docker conflicts.
    Therefore they should match existing user and group ids defined within OMV config. Otherwise you may lack permission to access your movies or (if you chose so) writing metadata to a separate folder. As mentioned above, my previous setup was running emby-server with user:group emby:emby. My content also was saved as emby:emby. That's why I looked up the uid and gid of the emby user and group and these I took for UID and GID in the emby-server docker config. If you just chose some random number this may work with the users group (100) as GIDLIST, if your content was saved with the users group. So I recommend to use the user:group ids the content is saved with (read the link I posted above - the emby-server docker install instructions recommend the same).


    When you have a look at your emby config folder, then you see there the user:group you've chosen in UID and GID. It's the number you've chosen, if you don't match an existing user:group. If numbers match, it shows the name representation of the number.


    DEVICE statement gives access to ffmpeg and is also covered in the install instructions. Afaik it's necessary to create movie thumbs. Don't know if that's possible if one uses a hardware accelerated encoding method.

    • Offizieller Beitrag

    From what I've seen till now: the UID and GID are the user and group ids the docker is accessing data on the hds and have nothing to do with avoiding docker conflicts.

    Users rarily use only one Docker. With that in mind, what if a user has a Docker that is already using UID 100 and GID 1000? And since it's a common default, what if a new docker configures 100 and 1000? A conflicting condition like that might take one or both Dockers down. Leaving settings at their defaults can often have negative consequences.


    (BTW: On my test system, a netdata Docker is using 100 and 1000.)


    In any case, as noted in the following, the default installed permissions by the container (using 111 and 1111) are working fine.

    • Offizieller Beitrag

    I followed up on the cache, transcoding-temp, and metadata files location. They're stored in "/config". Fixing that was easy enough.


    I changed the first line in Volumes and Bind points to the following:


    Host Path -------------------------------------------------------------------------- Container Path
    /srv/dev-disk-by-id-md-name-OMV-VM-RAID5/embyconfig/config----------/config


    (I actually copied the contents of the old Host Path to the new location first, then changed the line in Volumes and Bind points and saved the container. The save automatically restarted the modified container with the new settings.) It didn't miss a beat.


    This also seems to indicate that it might be possible to restore existing settings, to a newly built container.
    _______________________________________________________________


    More importantly for your use case:
    By locating the Host side of the /config line on a data drive; as Emby metadata grows with your media library, it won't fill up your USB boot drive.

    • Offizieller Beitrag

    Thanks @flmaxey and @Stramm I think I now have OMV running V4, I've turned the Emby service off so tomorrow I'll uninstall and start on Docker, I'm still not convinced of having to add the Volumes and Bind options other than for the config file. Emby has always updated without the need for re enabling the paths to each content folder as it is stored within it's own config....anyway I'll see what happens....got to catch up on what you've posted. :)

    • Offizieller Beitrag

    @geaves;


    I just finished giving my wife a demo of Emby. As I've mentioned before, I haven't used media centers ut to this point but she doesn't get my method of organizing media. So,, given that it seems to work fine, the container updates in place and metadata (actually all configuration data) can easily be exported to data disk, I think I'm going to adopt Emby in a Docker.


    The only differences from the above would be:


    - The GID will be 100 - the standard users group. (As it turned out 111 is the GID for the ntp system group.)
    - The UID will be 1100. (I noticed that standard users on my live server started at 1001 and ran sequentially to 1003. Using a UID of 1100 would leave an additional 97 UID's for additional users. That should be enough. :) )

    • Offizieller Beitrag

    I'm still not convinced of having to add the Volumes and Bind options other than for the config file. Emby has always updated without the need for re enabling the paths to each content folder as it is stored within it's own config....

    I admit that I don't know the internals of Emby - that's your area. In my case, I have segregated media shares so individual paths to each share seemed to be in order. In any case, there's more than one way to do it. Overall, I'm satisfied that it works well.


    I'm going to work with OMV4.0 to see how that goes.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!