Docker

[BAlGaInTl 279]

Ok, I found the proper way to update the Docker on OMV (OpenMediaVault)

 

Into OMV web interface go to dockers.

Stop the Docker container. (at the bottom of the Docker section)

Go to repository and click over the emby repository just for selection. (at the top of the Docker section)

Click on Pull Image and write:  emby/embyserver and in the tag space choose latest or beta (pick only the version that you are using without the colon )

Click ok and wait until the new image is downloaded. When is ready close the pull window.

 

Now you can see an empty name pull which is the old emby version. (leave it as it for now)

 

Go down again an click over the emby container (at the bottom of the Docker section) - (be careful because it lost the original name "emby/embyserver:beta"  for a simple / ) , select the unnamed container and click on Modify.

Leave all settings as it but save it. -Once that is saved it get "emby/embyserver:beta" name again- 

 

Note: (in my case I'm using beta) if you are using the latest non-beta release it will be "emby/embyserver:latest"

 

Done.

 

Now Emby is updated to the latest version.

 

To clean up, go up (at the top of the Docker section) to the docker images and the delete the unnamed pulled image.

 

That's it.

 

Hope helps.

 

When I was on OMV, I finally started using Watchtower to automatically update my containers.

 

I've since switched to unRaid which has a one button solution that essentially does what you outlined.

[Riggs 300]

When I was on OMV, I finally started using Watchtower to automatically update my containers.

 

I've since switched to unRaid which has a one button solution that essentially does what you outlined.

 

Oh yeah, unRaid is great, but is not free or open source (at least, not that I know). OMV is Open Source which is important to me. Watchtower sometimes is messy. Thank you!

[BAlGaInTl 279]

Oh yeah, unRaid is great, but is not free or open source (at least, not that I know). OMV is Open Source which is important to me. Watchtower sometimes is messy. Thank you!

 

Yeah.... I ran OMV for quite some time.  I never really had a problem with Watchtower, but then had to write a cron to clean up the orphaned containers.

 

When I decided to go to a pooled solution over a normal software raid, I evaluated doing it on OMV and unRaid.  The latter just made it much simpler so I paid for a license.

[Riggs 300]

Yeah.... I ran OMV for quite some time.  I never really had a problem with Watchtower, but then had to write a cron to clean up the orphaned containers.

 

When I decided to go to a pooled solution over a normal software raid, I evaluated doing it on OMV and unRaid.  The latter just made it much simpler so I paid for a license.

 

Yes, unRaid is great, there is no doubt, but even what I have can handle OMV well. Something similar and with an open license would be wonderful.

[BAlGaInTl 279]

Yes, unRaid is great, there is no doubt, but even what I have can handle OMV well. Something similar and with an open license would be wonderful.

 

Agreed.  You can still do everything that unRaid does with OMV.  It just takes a bit more attention and work.

 

I look at it this way... I've spent about $300 on my server in software.

 

Emby + 45 User License (That I don't really need, but wanted to support Emby development) + unRaid

 

The time I save now on managing all of that is well worth the money saved.  I certainly understand the desire to do it all with FOSS.  

[cnstarz 19]

To use NVENC/NVDEC, do we still need to use the deprecated nvidia-docker2 or can we use nvidia-container-toolkit?  

[alucryd 216]

@@cnstarz You should use nvidia-container-toolkit if you have access to it on your distro. That's the one I used on Arch Linux.

[Luke 37084]

@@cnstarz I moved your Nvidia hardware acceleration instructions to here because I think they will be useful for others:

 

https://emby.media/community/index.php?/topic/76937-docker-hwa-nvidia-instructions/

 

Thanks !

[screwattackthis 5]

Does logging in through Emby Connect have issues if you're using the bridge driver for networking?  It seems if I try to login through the app.emby.media, Android app, or Android TV app then it's attempting to connect to my server with it's docker container's IP and I have to manually connect to the server.  Anyway around that other than switching to the host driver?

Edited September 8, 2019 by screwattackthis

[D34DC3N73R 18]

Does logging in through Emby Connect have issues if you're using the bridge driver for networking?  It seems if I try to login through the app.emby.media, Android app, or Android TV app then it's attempting to connect to my server with it's docker IP and I have to manually connect to the server.  Anyway around that other than switching to the host driver?

 

You need to declare the ports in your docker run / docker-compose (which is essentially forwarding the ports from your container to the host) and then use your host ip to connect.

[screwattackthis 5]

You need to declare the ports in your docker run / docker-compose (which is essentially forwarding the ports from your container to the host) and then use your host ip to connect.

 

Yeah, that's been done.  Not the issue.  As I said, logging in with Emby Connect is trying to access the server with the container's IP as opposed to the host's.

[D34DC3N73R 18]

Yeah, that's been done.  Not the issue.  As I said, logging in with Emby Connect is trying to access the server with the container's IP as opposed to the host's.

 

Have you set `Settings > Advanced > Bind to local network address` to the host ip?

[screwattackthis 5]

Have you set `Settings > Advanced > Bind to local network address` to the host ip?

 

I can give that a shot but if I wanted Emby to bind to the host's IP then I might as well just use the host network driver.  Also suspect this won't play nice with my reverse proxy.

[D34DC3N73R 18]

I can give that a shot but if I wanted Emby to bind to the host's IP then I might as well just use the host network driver.  Also suspect this won't play nice with my reverse proxy.

 

If you want to access the container from somewhere other than the host, you need to declare the ports, which you said you've done already anyways. Further down the advanced section you can set the external domain for a reverse proxy, and if you're using ssl, there's a section to set `Secure connection mode` to `Handled by reverse proxy`.

[D34DC3N73R 18]

For clarity, the only difference between the host and bridge network stack is that the bridge network stack only forwards the specified ports, whereas the host stack forwards all ports from the container to the host. Specifying the ip to bind to in the emby settings doesn't change any of that, it just tells emby itself what ip the software thinks it resides at. I've been using these same settings for about a year with a reverse proxy (using the LSIO letsencrypt nginx image) and emby connect hasn't had any issues. When it's all set up, your dashboard should look something like this:

 

EDIT: also remember to link your user account to the emby connect username or email address.

Edited September 8, 2019 by D34DC3N73R

[screwattackthis 5]

My dashboard is missing the "In-Home (LAN) access" portion.  Just displays the port.  I'm on stable but I doubt that's a new feature.

 

I've set the local bind IP to the host IP and restarted the container and still having the same issue.  I didn't really think this would help.  The container only has the one IP to bind to and being isolated from the host network makes it a bit tough to bind to it's IP.

 

Are you using the host or bridge network?

 

edit: I'm guessing this isn't really doable unless there's a setting for telling Emby what local IP/hostname to advertise through Emby Connect.  Plex uses an environment variable for this purpose.  

Edited September 8, 2019 by screwattackthis

[D34DC3N73R 18]

My dashboard is missing the "In-Home (LAN) access" portion.  Just displays the port.  I'm on stable but I doubt that's a new feature.

 

I've set the local bind IP to the host IP and restarted the container and still having the same issue.  I didn't really think this would help.  The container only has the one IP to bind to and being isolated from the host network makes it a bit tough to bind to it's IP.

 

Are you using the host or bridge network?

 

 

The thing is, it's not isolated from the host network. If you've specified ports, those ports are being forwarded to the host from the container. You should be able to access emby from http://HOSTIP:8096 anywhere on your local network. I use bridge on ubuntu 18.04.3. The following is my docker-compose 

    emby:
        image: emby/embyserver:beta
        container_name: emby
        restart: unless-stopped
        ports:
            - 8096:8096
            - 8920:8920
        environment:
            - TZ=$TZ
            - UID=$PUID
            - GID=$PGID
            - GIDLIST=44
            - NVIDIA_VISIBLE_DEVICES=all
            - NVIDIA_DRIVER_CAPABILITIES=all
        volumes:
            - $HOME/.config/emby:/config
            - /media/Video/Movies:/media/Video/Movies
            - /media/Video/TV:/media/Video/TV
            - /media/Music:/media/Music

For what it's worth, I also have a second emby install on a remote dedicated server and don't have a bind ip set and can still use emby connect without any problems. Have you linked your local emby user account to your emby connect username or email address?

 

EDIT: Emby uses remote WAN access for emby connect. I don't have any ports forwarded in my router for emby (besides 80 and 443 for my reverse proxy set ups) and emby connect still works fine.

Edited September 8, 2019 by D34DC3N73R

[screwattackthis 5]

https://docs.docker.com/network/bridge/

 

 

 

In terms of Docker, a bridge network uses a software bridge which allows containers connected to the same bridge network to communicate, while providing isolation from containers which are not connected to that bridge network.

 

Yes, they're isolated.  It's two networks with a "bridge" between them hence the mapping of ports.  The important bit being that the container is hosted on a separate network from the host.  As far as Emby is concerned, it doesn't know what my host IP is and shouldn't be able to bind to it.  Unless Emby does something weird, "bind IP" settings for web servers are typically for use on a server environment with multiple IPs and you want the web server to only listen to a specific IP.  So if my container's IP is 172.17.0.x, how is it going to bind to 192.168.1.x?  It'd be like having Emby bind to another computer's IP.  I should only be able to bind to the IPs assigned to the container.  The bridge is basically doing the same thing as your router's firewall by forwarding requests from <external IP>:port to <internal IP>:port.

 

Yes, I've linked my local account to the connect account.  And every time I mess with a setting I unlink and then relink it.

 

I really appreciate the time you've taken to help but I don't think it's the right direction.  If I'm wrong, I'll let you give me a big fat "I told ya so"

 

 

EDIT: Emby uses remote WAN access for emby connect. I don't have any ports forwarded in my router for emby (besides 80 and 443 for my reverse proxy set ups) and emby connect still works fine.

 

 

I believe that's only if you're accessing from an external network.  But if you don't have the LAN Networks settings set then I can see how it's working for ya.

Edited September 8, 2019 by screwattackthis

[D34DC3N73R 18]

https://docs.docker.com/network/bridge/

 

 

Yes, they're isolated.  It's two networks with a "bridge" between them hence the mapping of ports.  The important bit being that the container is hosted on a separate network from the host.  As far as Emby is concerned, it doesn't know what my host IP is and shouldn't be able to bind to it.  Unless Emby does something weird, "bind IP" settings for web servers are typically for use on a server environment with multiple IPs and you want the web server to only listen to a specific IP.  So if my container's IP is 172.17.0.x, how is it going to bind to 192.168.1.x?  It'd be like having Emby bind to another computer's IP.  I should only be able to bind to the IPs assigned to the container.  The bridge is basically doing the same thing as your router's firewall by forwarding requests from <external IP>:port to <internal IP>:port.

 

Yes, I've linked my local account to the connect account.  And every time I mess with a setting I unlink and then relink it.

 

I really appreciate the time you've taken to help but I don't think it's the right direction.

 

 

Containers not on the same docker network are isolated from eachother, not the host network. You can still access emby from http://HOSTIP:8096 from anywhere on your local network, even when using the bridge network stack as long as the ports are specified. Emby doesn't know what the host ip is, until you bind it in the settings, but that is irrelevant as far as emby connect is concerned. Emby connect uses whatever is set in the remote WAN access settings, so that is where I would check if I was you.

[D34DC3N73R 18]

One other thing I didn't ask about, Did you confirm the account link in your email after setting up emby connect? See #3 here: https://github.com/MediaBrowser/Wiki/wiki/Emby-Connect#guide-for-administrators

[screwattackthis 5]

I didn't really want to argue semantics over the word "isolated".  All I meant was you can't bind to the host IP because the container is on a separate network.  Like I said, unless Emby is doing something weird with that setting that's contrary to any other "bind IP" setting for a webserver I've ever seen, it simply doesn't make sense to put anything but the container's IP there.  I really don't want to waste time arguing over this so let's just agree to disagree.

 

 

Emby connect uses whatever is set in the remote WAN access settings, so that is where I would check if I was you.

 

Is that documented somewhere?  That doesn't really make sense to me.

 

Here's the server list app.emby.media gets after logging with Emby Connect:

AccessKey: "*******"
Id: "*****"
LocalAddress: "http://<docker IP>:8096"
Name: "Emby"
SupporterKey: ""
SystemId: "******"
Url: "http://<external IP>:8096"
UserType: "Linked"

When you select a server it makes two calls.  One to the local address, one to the external.  In my case both fail.

 

e: And I'm guessing in your case it's working out for ya cause you have your domain configured in your internal DNS.  I could do the same (and it does work) but I use a different domain for external access vs internal so it's not a great solution for me.

Edited September 8, 2019 by screwattackthis

[D34DC3N73R 18]

I didn't really want to argue semantics over the word "isolated".  All I meant was you can't bind to the host IP because the container is on a separate network.  Like I said, unless Emby is doing something weird with that setting that's contrary to any other "bind IP" setting for a webserver I've ever seen, it simply doesn't make sense to put anything but the container's IP there.  I really don't want to waste time arguing over this so let's just agree to disagree.

 

Emby can and does bind to my host ip with no problems, without that set, the container ip is used. With it set, the host ip is used, which is accessible from anywhere on my local network.

 

Is that documented somewhere?  That doesn't really make sense to me.

 

Same link I provided earlier: https://github.com/MediaBrowser/Wiki/wiki/Emby-Connect

 

 

Emby Connect is a free service that makes it easy to sign into your apps when away from home, and manage connections to multiple servers.

 

Why does your remote link fail? Are you really using ip:port to connect externally?

 

 

e: And I'm guessing in your case it's working out for ya cause you have your domain configured in your internal DNS.  I could do the same (and it does work) but I use a different domain for external access vs internal so it's not a great solution for me.

 

My domain isn't configured in my internal DNS.

Edited September 8, 2019 by D34DC3N73R

[screwattackthis 5]

I'm not sure why you're so adamant about arguing over this but at this point I'm just going to stop responding to anything regarding binding to the host IP.  It simply does not make sense.

 

That link doesn't say it only uses your external address.  Why would Emby try to route internal traffic externally?  That would just be incredibly wasteful and break a lot of things for a lot of people.  As I just showed you, it tries your local connection first.  If you really don't believe me, feel free to try it yourself.  Go to http://app.emby.media and hit F12 and watch your network requests.  That's exactly how it works.  It tries your local address first, then tries your WAN settings.  It's not ONLY relying on your WAN settings.

 

 

 

My domain isn't configured in my internal DNS.

 

Then it only works with your remote server and not locally.  Either way I'm pretty convinced you have a pretty odd setup that just happens to work.

 

e: Honestly at this point it's just getting off topic and unproductive and a bit spammy.  I appreciate your time trying to help but I'm calling it a night and probably won't respond back to you.  Take care.

Edited September 8, 2019 by screwattackthis

[D34DC3N73R 18]

Bottom line is Lan access needs to be set to a local ip:port that's resolvable on your local network. Remote wan access needs to be set to a wan ip/ domain that's resolvable outside your network. If you set both those things up, emby connect should work for you.

[Riggs 300]

Hi.

Some news, just in case.

 

OpenMediaVault version 5 is out from two weeks now.

 

 

Now for docker you can use Portainer or Cockpit.

 

Portainer is my recommendation for a WebUI 'cause has more features.

 

 

That's all.

 

Have a nice day.

Edited September 19, 2019 by HRSCR