Docker

[alucryd 217]

Did you specify a mount point inside the container, as in "--volume /path/to/mount:/mnt" ? For some reason docker behaves strangely if you don't.

[mastrmind11 717]

Did you specify a mount point inside the container, as in "--volume /path/to/mount:/mnt" ? For some reason docker behaves strangely if you don't.

I didn't.  I literally copied and pasted the example and tweaked where necessary.  tbh I found it interesting I didn't have to specify an internal mount, thought it was a new feature or something.  I'll try again now.

 

Side note for the doc, you should mention that the entire config dir needs to be smoked if removing a container w/ the intent to install a new one w/ different params.  For some reason, some containers dont care, others do... this one just throws an "invalid address" if you try to access the server after removing/tweaking/reinstalling.

 

edit:  fyi that worked, so should definitely be put in the documentation (--volume /path/to/share/root \ # To mount a first share at root level)

 

edit2: the local ip address on the dashboard... is that what's actually being reported?  ie, is that something to consider when integrating the new changes coming down the beta channel when figuring out whether clients are on the local networrk?  if so, I suggest @@Luke adds the docker ip 172.17.0.1/24 to the default range or it's going to cause issues (even if the range is coded under the covers and transparent).  Just a thought.

Edited January 24, 2018 by mastrmind11

[TrainAss 22]

I reused my existing container, updated for the new method, and when I started it for the first time I found I had to let it sit for a few minutes as the connection kept being refused. After maybe 5min at most I started getting pushbullet notifications, and was able to access the server.

 

Not sure if there was a conversion going on (I assume maybe?). Either way, I've noticed that Emby is faster now than it was through mono. It's awesome.

[cyrenbyren 12]

@@cyrenbyren Could you give the beta tag a try? It should start fine now.

 

it starts INSTANTLY. very nice seems like the normal startup process is way faster now as well. (that is, since .70)

[cyrenbyren 12]

not sure of your linux version/specs so not sure whether it's on by default... used to be a few years ago, the switched it to sync since then.  Try adding the param and see if it makes a difference.

 

tried it just now with async, still takes a looong time. much less of an issue now though, with the uid/gid check before the chown. i very rarely do any meta operations over nfs anyway.

[Luke 37235]

Thanks for the feedback guys.

[cyrenbyren 12]

Thanks for the feedback guys.

 

thank you and @@alucryd for the fast response here! been using emby for years now, early premiere member and still in love.

[cyrenbyren 12]

why is the container named "focused_fermat"?  Please update your install instructions to include "--name emby-server" in the command.... it's a pain in the ass  to have to list containers and copy/paste container id when working with them.  

 

if you don't specify a name a random name is created for you by docker. also, you don't have to use the entire container id to reference it, just use the first few symbols (as long as they are unique among the running containers*). 

 

*actually running or stopped. existing containers.

Edited January 24, 2018 by cyrenbyren

[skurvy_pirate 2]

I am having a couple issues since upgrading to the latest Docker image as well. My scheduled config backups are failing with this exception:

2018-01-25 02:58:26.681 Info Server Configuration Backup: Backup of profile Default Started
2018-01-25 02:58:26.731 Error Server Configuration Backup: Error Copying /config/config/system.xml to /media/triforce/Media/Emby Backup - 2018-01-25 02.58.26 - Auto/system.xml
	*** Error Report ***
	Version: 3.2.70.0
	Command line: /system/EmbyServer.dll -programdata /config -ffmpeg /bin/ffmpeg -ffprobe /bin/ffprobe -restartexitcode 3
	Operating system: Unix 4.4.0.109
	64-Bit OS: True
	64-Bit Process: True
	User Interactive: True
	Processor count: 8
	Program data path: /config
	Application directory: /system
	System.UnauthorizedAccessException: Access to the path is denied. ---> System.IO.IOException: Operation not permitted
	   --- End of inner exception stack trace ---
	   at Interop.ThrowExceptionForIoErrno(ErrorInfo errorInfo, String path, Boolean isDirectory, Func`2 errorRewriter)
	   at Interop.CheckIo(Int64 result, String path, Boolean isDirectory, Func`2 errorRewriter)
	   at System.IO.UnixFileSystem.CopyFile(String sourceFullPath, String destFullPath, Boolean overwrite)
	   at System.IO.File.InternalCopy(String sourceFileName, String destFileName, Boolean overwrite)
	   at System.IO.File.Copy(String sourceFileName, String destFileName, Boolean overwrite)
	   at MBBackup.ServerEntryPoint.CopyFile(String source, String target, Boolean createDirectory)
	System.UnauthorizedAccessException
	   at Interop.ThrowExceptionForIoErrno(ErrorInfo errorInfo, String path, Boolean isDirectory, Func`2 errorRewriter)
	   at Interop.CheckIo(Int64 result, String path, Boolean isDirectory, Func`2 errorRewriter)
	   at System.IO.UnixFileSystem.CopyFile(String sourceFullPath, String destFullPath, Boolean overwrite)
	   at System.IO.File.InternalCopy(String sourceFileName, String destFileName, Boolean overwrite)
	   at System.IO.File.Copy(String sourceFileName, String destFileName, Boolean overwrite)
	   at MBBackup.ServerEntryPoint.CopyFile(String source, String target, Boolean createDirectory)
	InnerException: System.IO.IOException
	System.IO.IOException: Operation not permitted
	
2018-01-25 02:58:26.732 Error TaskManager: Error
	*** Error Report ***
	Version: 3.2.70.0
	Command line: /system/EmbyServer.dll -programdata /config -ffmpeg /bin/ffmpeg -ffprobe /bin/ffprobe -restartexitcode 3
	Operating system: Unix 4.4.0.109
	64-Bit OS: True
	64-Bit Process: True
	User Interactive: True
	Processor count: 8
	Program data path: /config
	Application directory: /system
	System.UnauthorizedAccessException: Access to the path is denied. ---> System.IO.IOException: Operation not permitted
	   --- End of inner exception stack trace ---
	   at Interop.ThrowExceptionForIoErrno(ErrorInfo errorInfo, String path, Boolean isDirectory, Func`2 errorRewriter)
	   at Interop.CheckIo(Int64 result, String path, Boolean isDirectory, Func`2 errorRewriter)
	   at System.IO.UnixFileSystem.CopyFile(String sourceFullPath, String destFullPath, Boolean overwrite)
	   at System.IO.File.InternalCopy(String sourceFileName, String destFileName, Boolean overwrite)
	   at System.IO.File.Copy(String sourceFileName, String destFileName, Boolean overwrite)
	   at MBBackup.ServerEntryPoint.CopyFile(String source, String target, Boolean createDirectory)
	   at MBBackup.ServerEntryPoint.<ExecuteBackup>d__61.MoveNext()
	--- End of stack trace from previous location where exception was thrown ---
	   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
	   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
	   at MBBackup.Entities.ScheduledBackupTask.<Execute>d__8.MoveNext()
	--- End of stack trace from previous location where exception was thrown ---
	   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
	   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
	   at Emby.Server.Implementations.ScheduledTasks.ScheduledTaskWorker.<ExecuteInternal>d__68.MoveNext()
	System.UnauthorizedAccessException
	   at Interop.ThrowExceptionForIoErrno(ErrorInfo errorInfo, String path, Boolean isDirectory, Func`2 errorRewriter)
	   at Interop.CheckIo(Int64 result, String path, Boolean isDirectory, Func`2 errorRewriter)
	   at System.IO.UnixFileSystem.CopyFile(String sourceFullPath, String destFullPath, Boolean overwrite)
	   at System.IO.File.InternalCopy(String sourceFileName, String destFileName, Boolean overwrite)
	   at System.IO.File.Copy(String sourceFileName, String destFileName, Boolean overwrite)
	   at MBBackup.ServerEntryPoint.CopyFile(String source, String target, Boolean createDirectory)
	   at MBBackup.ServerEntryPoint.<ExecuteBackup>d__61.MoveNext()
	--- End of stack trace from previous location where exception was thrown ---
	   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
	   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
	   at MBBackup.Entities.ScheduledBackupTask.<Execute>d__8.MoveNext()
	--- End of stack trace from previous location where exception was thrown ---
	   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
	   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
	   at Emby.Server.Implementations.ScheduledTasks.ScheduledTaskWorker.<ExecuteInternal>d__68.MoveNext()
	InnerException: System.IO.IOException
	System.IO.IOException: Operation not permitted
	
2018-01-25 02:58:26.732 Info TaskManager: Configuration Backup Failed after 0 minute(s) and 0 seconds

It is weird though, because it creates a new folder for the backup and it writes 3 files into it: packageruntime.dat, profile.txt, and system.xml. So it isn't like it doesn't have access to the location. Something else weird is going on.

 

The second issue is resuming doesn't seem to be honored. The file will start at the beginning. But this may just be related to Kodi because I just tried on my browser and it seemed to be working. I am going to try some more experimenting and gather more data before asking for guidance on that one.

Edited January 25, 2018 by skurvy_pirate

[alucryd 217]

@@skurvy_pirate There's an ongoing thread about your first issue: https://emby.media/community/index.php?/topic/55037-backup-plugin-throwing-permission-issues-confused/

[Luke 37235]

And as far as resume, please mention this in the emby for Kodi section of the community. Thanks.

[mastrmind11 717]

Will the container honor a manual port change from the Emby admin page?  I assume not but figured I'd ask.  I ask because I'm planning to switch to the docker version for a few days to test and would prefer to not have to change my apps/router/proxie to point to the docker port.  I'd also prefer to not have to spin up a new container just to change back to 8096.  Lemme know.

[Luke 37235]

@@alucryd will need to confirm but i imagine that may also require an adjustment to your startup command line.

[alucryd 217]

@@mastrmind11 The exposed ports are determined by the docker run command, if you change the port in emby you also need to change it in your run command.

[mastrmind11 717]

@@mastrmind11 The exposed ports are determined by the docker run command, if you change the port in emby you also need to change it in your run command.

Figured as much.  Thanks!

 

Side q:  If I spin up a new docker but leave the existing /config structure in place, will it just pick up where the previous docker left off?  My past experiences doing this has resulted in mixed results, so I'm looking for the easiest way to start a new one w/ the port change above but w/o having to set up libraries, etc and run a scan.  

[cyrenbyren 12]

Figured as much.  Thanks!

 

Side q:  If I spin up a new docker but leave the existing /config structure in place, will it just pick up where the previous docker left off?  My past experiences doing this has resulted in mixed results, so I'm looking for the easiest way to start a new one w/ the port change above but w/o having to set up libraries, etc and run a scan.  

 

if you spin up a new one with the same config volume mounted as the old one, it will pick up where the old one was. it will use the same database, same configs, same cache etc

Edited January 27, 2018 by cyrenbyren

[mastrmind11 717]

if you spin up a new one with the same config volume mounted as the old one, it will pick up where the old one was. it will use the same database, same configs, same cache etc

Good info. Wondering what you are doing since my other containers are a basic cluster f if I don't wipe the /config first. I'll give it a try tonight or tomorrow. Thanks again.

 

Sent from my SM-G950U using Tapatalk

[cyrenbyren 12]

Good info. Wondering what you are doing since my other containers are a basic cluster f if I don't wipe the /config first. I'll give it a try tonight or tomorrow. Thanks again.

 

Sent from my SM-G950U using Tapatalk

 

as long as you use the same /config-volume AND the same media-volumes (that is, the in-container mount points are the same. externally it doesn't matter, as long as the content is the same) that you scanned earlier, everything else should fall into place. i can imagine a problem occurring (as in, your library will be wiped) if you mount the same config-volume but then you move the media-volumes. is that what is happening?

Edited January 27, 2018 by cyrenbyren

[mastrmind11 717]

as long as you use the same /config-volume AND the same media-volumes (that is, the in-container mount points are the same. externally it doesn't matter, as long as the content is the same) that you scanned earlier, everything else should fall into place. i can imagine a problem occurring (as in, your library will be wiped) if you mount the same config-volume but then you move the media-volumes. is that what is happening?

Probably. I've been migrating all my standalones over to docker the past few months and manually copying stuff over to /config. Not sure I've ever tried a docker run w an existing *working* config dir. Keep you posted. Thanks

 

Sent from my SM-G950U using Tapatalk

[dcrdev 251]

Sorry to hijack the thread...

 

@@mastrmind11 what are the benefits your hoping to achieve by transitioning everything to docker?

 

Not that I'm arguing them, I'm just genuinely interested as I struggle to see how containerisation would benefit me personally.

[cyrenbyren 12]

Sorry to hijack the thread...

 

@@mastrmind11 what are the benefits your hoping to achieve by transitioning everything to docker?

 

Not that I'm arguing them, I'm just genuinely interested as I struggle to see how containerisation would benefit me personally.

 

i'm not @@mastrmind11, but i can give you my reasons

 

simplicity of management is my primary reason. i run a bunch of applications at home that aren't really that taxing io-wise. this allows me to use a primary storage pool that doesn't have to be on the same server as the app that is hosted, and i have several nuc:s that share the load so to speak. each app runs on one of the nuc:s, but due to how docker operates in regards to host settings (etc), it doesn't really matter where the app is located. i am using a dedicated "entry point" server (which is a vm) that really only hosts reverse proxies of the apps that i want to access. 

 

this is made easier (in my case, at least) by orchestrating everything via rancher. you just add hosts that can participate, and rancher has support for the reverse proxies (even load balancing really) and storage drivers for the volumes.

 

the main difference with using docker instead of dedicated vm:s, aside from easier configuration, is resource allocation. a vm needs dedicated memory, regardless of whether it is actually used by the applications running. docker does not. docker only uses what the container needs, and there is no limit (aside from physical) to how many containers you can run on a single server. you get the benefit of a separate environment for your application, with any customization you need, but without having to reserve physical resources that is not used.

Edited January 31, 2018 by cyrenbyren

[mastrmind11 717]

Sorry to hijack the thread...

 

@@mastrmind11 what are the benefits your hoping to achieve by transitioning everything to docker?

 

Not that I'm arguing them, I'm just genuinely interested as I struggle to see how containerisation would benefit me personally.

Similar to what @@cyrenbyren said, ease of management.  One of the benefits, and actually the main reason I even started using docker, is the ability to run multiple containers of the same app simultaneously.  eg, it's not possible to have more than 1 instance of sonarr installed on any given machine.  But with docker, you can have  as many as you want.  I like to keep my stuff vs my kids stuff as separate as possible, so I have 2 versions of sonarr w/ different out directories, which Emby treats as separate libraries.  Also, resource management/monitoring is easier with docker when using tools like Netdata where everything can be broken out by container.   And the ability to take a snapshot of a container's state, tar it up and send it somewhere is an amazing feature, especially when a server dies or a rollback is required.  Lastly, I like how tidy it keeps the filesystem.  I have a centralized docker location in /home/docker with a sub dir for each container's /config folder, so instead of having to remember where every app root folder is located, where their log files are, etc, now I know immediately.  Just to name a few

[mastrmind11 717]

What's everyone using to automate updating containers?  and how do you recommend doing it manually?  I'm fairly certain doing an update from the "update" button from inside a container is pretty frowned upon.  Thanks

[cyrenbyren 12]

What's everyone using to automate updating containers?  and how do you recommend doing it manually?  I'm fairly certain doing an update from the "update" button from inside a container is pretty frowned upon.  Thanks

 

i'm just stopping the container and starting it up with the latest tag and the same startup arguments.

(with rancher, this is done simply with an "upgrade" feature)

[mastrmind11 717]

i'm just stopping the container and starting it up with the latest tag and the same startup arguments.

(with rancher, this is done simply with an "upgrade" feature)

interesting.  I'll have to read up on Rancher.  Thanks