Closed diegomontanaduarte closed 2 years ago
Providing as much info as you provided us, https://ci-tests.linuxserver.io/linuxserver/emby/latest/index.html passes our tests.
@j0nnymoe could you please let me know what information can I provide to you?
@diegomontanaduarte it was in the template when you open the issue.
@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?
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.
@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
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.)
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.
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:
create standard docker run command per the linuxserver/emby Docker hub instructions (see details at end of bug report)
Try to load into emby, get 502 bad gateway
Load portainer to view logs
See the following logs:
$ ls -alh /mnt/video
. = drwxrwxrwx 1026:100
.. = drwxr-xr-x 1026:100
/mnt/video/tv = 777 1026:100
/mnt/video/movies = 777 1026:100
The paths listed above are mounted to my nuc from my nas using NFS in my fstab using the options nfs rw 0 0
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
@j0nnymoe @nemchik gents I have provided a full template response above. Can you please acknowledge?
@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.
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.
@nemchik issue resolved, thanks Eric!
After last release (4.7.6.0-ls129) that rebased the image from Ubuntu Focal to Ubuntu Jammy, Emby stopped working.