binhex

To be honest, i dont see how that is possible with the settings you have, it would be of been transcoding to /dev/shm inside of the container, which for my containers is a measly 64MB in size, this MAY be the source of your disk space related issue.

Yeah so that is incorrectly setup, you have a host path /dev/shm that bind mounts to /transcode, that is all good, you then set TRANS_DIR to point at the host path /dev/shm, this is not right, it should be pointing at '/transcode'. Keep in mind env vars (container variables) are defined inside of the container, so you have to use container paths not host paths, the host path will not be accessible.

one thing i have spotted in your supervisord.log is this:- So using /dev/shm SHOULD be ok, do you have a bind mount for that, a screenshot of 'unraid webui/docker/plex/edit' container settings would help.

yes please

i could still do with those logs guys:-

The CRL issue is for VPN provider PIA only, AFAIK no other providers have this issue, so you should be fine with AirVPN.

try a force update, go to unraid web ui/docker click on toggle at top right to 'advanced view' then click on the link 'forced update' for the jellyfin container

OK so what i currently suspect is going on is as follows:- Plex release a new version that requires database modifications The user does not realise this and updates and notices no access to the web ui (due to the database upgrade being in progress), the user then restarts the container part way through the database upgrade User still cannot access the Plex web ui and looks at the logs and notices either the message 'database or disk is full' (i suspect this really means database is corrupt) or 'database disk image is malformed', which are a result of 2. User rolls back to previous version which does not reference the new database modifications and therefore is not aware of the database corruption until the user attempts upgrade of plex again. The only way for me to identify if this is the case is to look at the log file, please can you post both /config/supervisord.log and the plex log located at /config/Plex Media Server/Logs/Plex Media Server.log Note:- Please do keep this in mind.

just because your disk is not full does not mean your docker image isn't, take a look at the unraid webui/dahsboard/system and look at docker utilisation, what is this at? screenshot perhaps.

Disk is full, you need to sort that first

interesting!, initially i had this issue, but the image never got published as my smoketest picked it up, i corrected the issue and the test passed, i have also just downloaded the latest image and done a clean startup (no pre-existing config) and it started correctly, so im not sure how this is happening for you, what is 'repository' set to for the container?.

i have rebuilt the base recently, so i will kick off a rebuild of the image in the next few days and hopefully that will fix it up.

this is interesting, as that package is installed in the base and ALL images are built from the base image:- https://github.com/binhex/arch-base/blob/2cf699902bd1727a983c9957b8aafbede3dad0fb/build/common/root/install.sh#L110

ahh i see, that looks like a quoting issue, i have reverted back to my previous code for that section, i was attempting to keep the code DRY but it looks like its a PITA to do, pull down latest image and let me know how you get on.

Yep sorry that's my fault, coding issue, its now fixed and a new image has been created, please pull down latest image and you should be good.

OK that's fine, just double checking here as a lot of people get tripped up on port and volume bindings in docker. Hmm well the only other things you can try is attempt connection to the webui via different machine, different browser, try renaming your config folder and restart to recreate from scratch - see if you can access the webui then, if you can' then there is something fundamentally wrong with your networking stack, try a reboot of the host.

that is not the correct port, from your scrrenshot I see you have set it to 8083, so you should be attempting connection to http://192.168.1.2:8083 have you tried that?

at a guess without the seeing the plex log i would say database corruption ,see Q4:- https://github.com/binhex/documentation/blob/master/docker/faq/plex.md

there is nothing obviously wrong there, i see a database migration happened successfully (or at least no errors were shown), can you post a screenshot of the container settings (left click, select edit and screenshot all settings).

I have now switched the build scripts over to https://github.com/nzbgetcom/nzbget/releases next release incoming shortly will be from here and for the foreseeable future.

reserved

Overview: Support for Docker image arch-gonic in the binhex repo. Application: Gonic - https://github.com/sentriz/gonic Docker Hub: https://hub.docker.com/r/binhex/arch-gonic/ GitHub: https://github.com/binhex/arch-gonic Documentation: https://github.com/binhex/documentation If you appreciate my work, then please consider buying me a beer 😁 For other Docker support threads and requests, news and Docker template support for the binhex repository please use the "General" thread here

it would require the Arch package maintainer to update the package, but this MAY have some reliance on the Jellyfin team, it would depend on how its packaged. Yes, the images i produce are Arch Linux based, other developers tend to use other base images, such as Alpine. Is there a reason for the urgency in getting updated?, a specific issue you are trying to solve perhaps?

once the upstream is updated then the image will auto build

Please do not create support requests here:- @SpencerJ i thought this was locked down (it should be)? fallout from the upgrade perhaps?