NNate 10 Posted February 10, 2017 Share Posted February 10, 2017 I understand the extra subfolder. The issue was it's giving me a double path substitution. "/metadata" substituted to "\\Tower\metadata" was showing up in my nfos as "\\Tower\metadata\\Tower\metadata\..." Link to comment Share on other sites More sharing options...
Luke 37230 Posted February 10, 2017 Author Share Posted February 10, 2017 What do you mean substituted? where is this substitution set up? Link to comment Share on other sites More sharing options...
anderbytes 139 Posted February 10, 2017 Share Posted February 10, 2017 What do you mean substituted? where is this substitution set up?He must be talking about the volume mapping in Docker (Host -> Guest) Link to comment Share on other sites More sharing options...
NNate 10 Posted February 10, 2017 Share Posted February 10, 2017 (edited) I'm talking about the optional Network location beneath where you can enter the custom metadata location in the Emby UI. Just like for any other Library path. I don't have the emby in front of me right now, but off the top of my head... Library -> Metadata?? Perhaps the Emby code is doing a "replaceAll" vs a "replaceFirst" when plugging that Network location over the local path? "/metadata/metadata" ending up as "substitution/substitution" instead of "substitution/metadata" Or have I just confused things more... I can grab screenshots when i get home if it helps. Edited February 10, 2017 by NNate Link to comment Share on other sites More sharing options...
skurvy_pirate 2 Posted February 15, 2017 Share Posted February 15, 2017 I just put together a new server and installed Ubuntu and Docker. I want to get Emby up and running in a container but I am having some troubles getting it to autostart with systemd. I have run: docker run -it --rm -v /etc/systemd/system:/target \ emby/embyserver instl service and then: sudo systemctl enable embyserver@${USERNAME} but I get "Failed to execute operation: No such file or directory". There is no emby file in /etc/systemd/system either. So I am not sure where it is going wrong. It looks like the instl service command executes fine as far as I can tell: [s6-init] making user provided files available at /var/run/s6/etc...exited 0. [s6-init] ensuring user provided files have correct perms...exited 0. [fix-attrs.d] applying ownership & permissions fixes... [fix-attrs.d] done. [cont-init.d] executing container initialization scripts... [cont-init.d] 01-conf-onetime: executing... [cont-init.d] 01-conf-onetime: exited 0. [cont-init.d] 02-user-onetime: executing... [cont-init.d] 02-user-onetime: exited 0. [cont-init.d] 03-upgrade-onetime: executing... [cont-init.d] 03-upgrade-onetime: exited 0. [cont-init.d] done. [services.d] starting services [services.d] done. instl exited 0 [cont-finish.d] executing container finish scripts... [cont-finish.d] done. [s6-finish] syncing disks. [s6-finish] sending all processes the TERM signal. [s6-finish] sending all processes the KILL signal and exiting. Link to comment Share on other sites More sharing options...
hurricanehrndz 149 Posted February 15, 2017 Share Posted February 15, 2017 There is a setup portion for the volumes, you need to run the wrapper script first without systemd Sent from my ONEPLUS A3000 using Tapatalk Link to comment Share on other sites More sharing options...
skurvy_pirate 2 Posted February 15, 2017 Share Posted February 15, 2017 I think I have done that. I specified the volumes and they are there in .emby-server.volumes and my Emby server is up and running fine. I think I am missing something else or missed a step. Link to comment Share on other sites More sharing options...
hurricanehrndz 149 Posted February 15, 2017 Share Posted February 15, 2017 Can you verify that embysever@service file exists in /etc/system/systemd Sent from my ONEPLUS A3000 using Tapatalk Link to comment Share on other sites More sharing options...
skurvy_pirate 2 Posted February 15, 2017 Share Posted February 15, 2017 Can you verify that embysever@service file exists in /etc/system/systemd Sent from my ONEPLUS A3000 using Tapatalk Sorry I forgot to mention that, it does not. I am not sure why it isn't getting created with the instl service command. Link to comment Share on other sites More sharing options...
hurricanehrndz 149 Posted February 15, 2017 Share Posted February 15, 2017 Oh, cool. I will look into it and try and find a solution. You can find the template here for now https://github.com/MediaBrowser/Emby.Build/tree/master/docker-containers/base/root/var/cache/systemd Sent from my ONEPLUS A3000 using Tapatalk 1 Link to comment Share on other sites More sharing options...
skurvy_pirate 2 Posted February 15, 2017 Share Posted February 15, 2017 Oh, cool. I will look into it and try and find a solution. You can find the template here for now https://github.com/MediaBrowser/Emby.Build/tree/master/docker-containers/base/root/var/cache/systemd Sent from my ONEPLUS A3000 using Tapatalk Perfect! That did it. Thanks! Link to comment Share on other sites More sharing options...
matejz 0 Posted February 16, 2017 Share Posted February 16, 2017 (edited) Oh, cool. I will look into it and try and find a solution. You can find the template here for now https://github.com/MediaBrowser/Emby.Build/tree/master/docker-containers/base/root/var/cache/systemd Sent from my ONEPLUS A3000 using Tapatalk I had the same problem. It looks like you have a typo in your install script. The service file in cache folder is named template@service, but in the install script, you are calling template@.service. if [[ -z "$1" ]]; then install_app else if [[ "$1" -eq "service" ]]; then if [[ -f /var/cache/systemd/template@.service ]]; then install_service fi fi fi Another thing: do you think it would be better to update the container as well when issuing emby-server update? Right now, if a new version is released and you update it via emby-server update, emby will get updated, but on the next restart of the container, it will revert back to old version. I'm not sure if this is intended to work that way or not. In some cases, if there are breaking changes between version changes, this can lead to non-working emby after container restart. How often are new containers build on Docker Hub? 3.2.1 is already out, but the last stable container was build 5 days ago with 3.2.0. Do you manually run the build command or is that automatic? Edited February 16, 2017 by matejz Link to comment Share on other sites More sharing options...
hurricanehrndz 149 Posted February 16, 2017 Share Posted February 16, 2017 The builds are automatic, it should have already been built. Thank you for reporting the issue. I think there is also a flag to enable updates on start. Sent from my ONEPLUS A3000 using Tapatalk Link to comment Share on other sites More sharing options...
matejz 0 Posted February 16, 2017 Share Posted February 16, 2017 Is a new version is built when new version is released on GitHub? If that is the case, then maybe the new package wasn't in the repo yet when docker container was built? There is an option to set EDGE parameter to 1, for docker to update the container on start. This and with docker container rebuild process working, I think we are covered. We can update current instances for testing with 'emby-server update' and update the container with 'docker pull' for permanent upgrade. Link to comment Share on other sites More sharing options...
hurricanehrndz 149 Posted February 16, 2017 Share Posted February 16, 2017 Yes and no, the chain of build processes is triggered when the GitHub release occurs Sent from my ONEPLUS A3000 using Tapatalk Link to comment Share on other sites More sharing options...
skurvy_pirate 2 Posted February 19, 2017 Share Posted February 19, 2017 (edited) I have another question related to upgrading Emby. I am still new to Docker and learning so I might be missing something, but I thought upgrading the image and then restarting the container would upgrade the Emby container. I looked at the documentation and running: docker pull emby/embyserver Says I have the latest version, but after stopping and starting emby-server, it is still on version 3.2.0.0. If I run: emby-server update It will update my Emby instance in the container to 3.2.1.0, but after restarting the container or machine, it reverts back to 3.2.0.0. I know that I can set the EDGE parameter so that the container updates on start, but I thought if the image was updated, it should be running from that image? What am I missing? Also, what is the best practice here? Updating the image, or setting EDGE variable to 1? I feel like to be more Docker-like, updating the image should be the route to go. Edited February 19, 2017 by skurvy_pirate Link to comment Share on other sites More sharing options...
hurricanehrndz 149 Posted February 19, 2017 Share Posted February 19, 2017 Updating the image would be the best, unfortunately the last autobuild failed and I have been to sick to do a manual build. I will try and get something going tonight. Our build system will be overhauled soon. Sent from my ONEPLUS A3000 using Tapatalk Link to comment Share on other sites More sharing options...
matejz 0 Posted February 19, 2017 Share Posted February 19, 2017 Yes and no, the chain of build processes is triggered when the GitHub release occurs Sent from my ONEPLUS A3000 using Tapatalk So it's possible when a new release is out, packages are not yet available, so docker builds with the old packages in this case? Link to comment Share on other sites More sharing options...
hurricanehrndz 149 Posted February 19, 2017 Share Posted February 19, 2017 The way the build system is designed no. Sometimes though the docker build service just has build failures for no apparent reason. Sent from my ONEPLUS A3000 using Tapatalk Link to comment Share on other sites More sharing options...
hurricanehrndz 149 Posted February 19, 2017 Share Posted February 19, 2017 So packages are available but for whatever no good reason thr hub labels the build as a failure and then doesn't publish the builds. Sent from my ONEPLUS A3000 using Tapatalk Link to comment Share on other sites More sharing options...
matejz 0 Posted February 19, 2017 Share Posted February 19, 2017 Oooo, that makes sense:) Thanks for explaining:) Link to comment Share on other sites More sharing options...
hurricanehrndz 149 Posted February 19, 2017 Share Posted February 19, 2017 Yeah it's really frustrating and stupid. We will switching to local builds and will then proceed to push the builds on the hub ourselves soon Sent from my ONEPLUS A3000 using Tapatalk Link to comment Share on other sites More sharing options...
matejz 0 Posted February 19, 2017 Share Posted February 19, 2017 Smart:) Docker is a really nice solution for things like that, until you need some firewalling in front and you don't have a designated appliance in front of it. I was forced to ditch the solution, because securing it with iptables is just... ugh, no good solution.. Link to comment Share on other sites More sharing options...
skurvy_pirate 2 Posted February 19, 2017 Share Posted February 19, 2017 Updating the image would be the best, unfortunately the last autobuild failed and I have been to sick to do a manual build. I will try and get something going tonight. Our build system will be overhauled soon. Sent from my ONEPLUS A3000 using Tapatalk Oh ok, so I do have the latest Docker image, but it is just still 3.2.0.0? That makes sense why it wasn't behaving as I expected. Is there a way to label or see what build is included in the Docker image? Link to comment Share on other sites More sharing options...
hurricanehrndz 149 Posted February 19, 2017 Share Posted February 19, 2017 In the future we can definitely label, right now the only way is to look at the build log on the hub Sent from my ONEPLUS A3000 using Tapatalk Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now