linuxserver / docker-emby

GNU General Public License v3.0
120 stars 40 forks source link

Ubuntu Jammy base image issue #57

Closed diegomontanaduarte closed 2 years ago

diegomontanaduarte commented 2 years ago

After last release (4.7.6.0-ls129) that rebased the image from Ubuntu Focal to Ubuntu Jammy, Emby stopped working.

image

j0nnymoe commented 2 years ago

Providing as much info as you provided us, https://ci-tests.linuxserver.io/linuxserver/emby/latest/index.html passes our tests.

diegomontanaduarte commented 2 years ago

@j0nnymoe could you please let me know what information can I provide to you?

j0nnymoe commented 2 years ago

@diegomontanaduarte it was in the template when you open the issue.

diegomontanaduarte commented 2 years ago

@j0nnymoe it's an Unraid OS, so the most of information required in the template is irrelevant in my opinion. Can you please check the CI Tests for the 4.7.6.0-ls129 tag?

j0nnymoe commented 2 years ago

https://ci-tests.linuxserver.io/linuxserver/emby/4.7.6.0-ls129/index.html

Again, still working and with all due respect, there is a reason why we ask for this data so the fact you think it's irrelevant, it's not. we need as much info as possible to figure out what could be causing the issue.

And just testing emby on unraid myself, it works fine.

nemchik commented 2 years ago

@j0nnymoe it's an Unraid OS, so the most of information required in the template is irrelevant in my opinion. Can you please check the CI Tests for the 4.7.6.0-ls129 tag?

Your opinion of whether our template is relevant or not does not change that we ask for the information so that we can avoid this exact back and forth of us not having enough information and needing to ask you for it before we can begin to understand what's happening so we can offer guidance on resolving the issue.

Without the full issue template completed, we don't truly know what is going on in your environment.

In case you have issues locating the template, you can copy it from here https://raw.githubusercontent.com/linuxserver/docker-emby/master/.github/ISSUE_TEMPLATE/issue.bug.md

srd424 commented 2 years ago

This looks like it's related to #51 - previously (trying to) chown /data was an annoyance, now the init script seems to actually fail if /data (the user's media) is read-only. (I presume the script is now run in a shell with -e set or similar.)

nemchik commented 2 years ago

This looks like it's related to #51 - previously (trying to) chown /data was an annoyance, now the init script seems to actually fail if /data (the user's media) is read-only. (I presume the script is now run in a shell with -e set or similar.)

So far we think this is pretty close. We believe the issue is that with s6 v2 the init script would silently fail, and other init scripts would then not run, but services would still run. With s6 v3 if an init script fails the services also fail. We could just add some |true to the bash scripts, but we're reviewing why the failure happens in the first place (the folder doesn't exist) and if we need to bother with the chown at all.

Edit: we are guessing that this is the issue based on other issues, we'd love to have more information (which we ask for in the template) to confirm things like what volumes are mounted, which could tell us if that folder exists (because it's a volume). If it does exist (because it's a volume) then or current assumption (failing init script) might be way wrong.

lateparty commented 2 years ago

I went to open a dummy new bug report so that I can help by providing the info you're after.

Expected behaviour: emby starts normally, I can open the web interface and watch videos from all my libraries

Current behaviour: emby fails to start, 502 Bad Gateway, can't access web interface, can't watch video from any library

Steps to reproduce:

  1. create standard docker run command per the linuxserver/emby Docker hub instructions (see details at end of bug report)

  2. Try to load into emby, get 502 bad gateway

  3. Load portainer to view logs

  4. See the following logs:

    Screen Shot 2022-09-26 at 21 33 57
  5. $ ls -alh /mnt/video . = drwxrwxrwx 1026:100 .. = drwxr-xr-x 1026:100 /mnt/video/tv = 777 1026:100 /mnt/video/movies = 777 1026:100

  6. The paths listed above are mounted to my nuc from my nas using NFS in my fstab using the options nfs rw 0 0

  7. Repeat ad infinitum.

Environment: OS = Arch - pacman -Syu to the latest sync database CPU Arch = x86_64 (Intel NUC i5) Docker is synced from official distro repos

Full docker log = screenshot above. I have recreated the service (and can do so quickly again, and again) to replicate.

Here's a copy my run script (extracted from a .sh I have for) docker run \ -d \ --name emby \ --restart always \ --network="bridge" \ --device /dev/dri:/dev/dri \ -p 8096:8096 \ -e PUID=1026 -e PGID=100 \ -e TZ=[Country]/[City] \ -v /containers/emby:/config \ -v /containers/emby/transcoding-temp:/transcode \ -v /mnt/video/tv:/data/tvshows \ -v /mnt/video/movies:/data/movies \ lscr.io/linuxserver/emby:latest

lateparty commented 2 years ago

@j0nnymoe @nemchik gents I have provided a full template response above. Can you please acknowledge?

nemchik commented 2 years ago

@lateparty thank you for providing the information.

A fix has been applied. Please update to the latest image and let us know if you still experience the problem.

nemchik commented 2 years ago

Closing for now. If anyone tries the new image (released roughly 30 minutes ago) and still has issues, feel free to comment requesting reopen, or open a new issue if this one is not reopened already.

diegomontanaduarte commented 2 years ago

@nemchik issue resolved, thanks Eric!