binhex

it was not, it is now, new image built, please pull down at your convenience.

im not sure where the links are stored, my guess would be the sqlite db, perhaps raise a support request on the filebrowser quantum repo issues? if it is stored in sqlite then you MAy be able to extract the links from the old db and import into the new db, useful tool i use for sqlite manipulation is this:- https://github.com/sqlitebrowser/sqlitebrowser

you can stop trimarr and yes that will obviously interrupt the remux, so you would then need to manually delete the partial remux (it does not remux the media file, it creates a new temporary file). nope, it will never delete backups for obvious reasons, so yes you will need to remove them manually.

Tis done:- https://forums.unraid.net/topic/201068-support-binhex-filebrowser-quantum/ All Users: With that now in place i am marking this container as deprecated - what this means is there will be no further builds (upstream has archived filebrowser), i will give a grace period of 1 year from now before the unraid template is deleted, I would encourage everyone to make the switch over to Filebrowser Quantum.

Reserved

Overview: Support for Docker image arch-filebrowser-quantum in the binhex repo. Application: Filebrowser Quantum - https://github.com/gtsteffaniak/filebrowser Docker Hub: https://hub.docker.com/r/binhex/arch-filebrowser-quantum GitHub: https://github.com/binhex/arch-filebrowser-quantum 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

you sure about that?, i thought the known vulnerabilities were patched in 1.43.3.10861 or later (already built a while ago):- https://forums.plex.tv/t/important-security-update-for-plex-media-server-v1-43-2-and-earlier/942319/3 in any case 1.43.5.x was built automatically 2 hours ago.

Im working on filebrowser quantum, i shall post back here when its ready.

You didnt answer this question directly, what is the ip address of the machine?, i want to ensure LAN_NETWORK is defined correctly (a very common trip up), keep in mind if your machine is on a different VLAN it will be blocked irresepective of your VLAN ruleset. Can you also tell me is the network for the container is set to bridge?, i have a feeling its not, if not please switch it to bridge then try again.

well it's definitely there:- https://github.com/binhex/arch-plexpass/pkgs/container/arch-plexpass My guess would be internet connectivity or DNS issues.

you should be pointing your router at caddy NOT immich, set caddy to listen on port 8080 and then set immich to listen on another port (otherwise it will conflict with caddy), my suggestion set it to 2283 (standard immich port), then set the caddy file as i detailed above.

I do not support alpha/beta/pre-releases, when v5 drops as stable then it will be automatically picked up and built.

Are you talking about CA here when you say 'apps'? i assume so but it's not clear, thus screenshots would of helped here, as well as the 'tag' you are on about, again i assume this is the tag shown in CA right?. If my assumptions are correct then i cannot explain why a container that exists and was installed via CA would suddenly not be marked as installed, that sounds like a possible CA related issue, i can confirm only one VERY minor change to the template on my side, where i changed the webui link, but i very much doubt this would trigger what you saw. In any case i'm happy you got it resolved.

Nope it's not dead. But low effort posts like this are ignored by me, no logs, no screenshots, nothing!.

ok so the things you need in place: set your router to port forward to caddy container, port 8443 ensure immich is working and listening, if you have immich listening on port 8443 then you will need to change that as it will clash with caddy, the default port for immich is 2283, i would recommend using that. set your caddy config file like so (assuming you change the port for immich to 2283): <myname>.duckdns.org:8443 { import security_headers import log_settings <myname>.duckdns.org.2283 tls { dns duckdns {env.DUCKDNS_TOKEN} } reverse_proxy <unraid ip>:2283 }

This should now be fixed, please pull down latest.

yes you need to ensure that slskd is sharing the same network as gluetun, otherwise slskd will firstly (and most importantly) not be using a vpn and secondly you wont be able to get an incoming port.

So the portset.sh script (script used to talk to gluetun and get the assigned incoming port) will talk to gluetun using the loopback ip address (127.0.0.1), this is how the applications container can get an incoming port from the gluetun's container, so it has to use loopback as both containers must be in the same network, so its working as intended.

As promised, i have switched it over to direct pulls from jellyfin directly, so the latest image is now built against latest, which at the time of this post is 12.1, please pull down at your convienience. Note:- It is HIGHLY recommended that you copy your config folder for jellyfin before you perform the update, that way you can always roll back the container and configuration to the previous version if things go pete tong.

It's been marked as out of date, nothing more to do now other than wait. If nothing happens by the end of this week then i will consider doing a direct install from github jellyfin release, but i would rather not go down that route unless i have to (a fair chunk of work).

it's there, its fully automated so you dont need to nudge me.

That's your problem, unless you specify the user to exec into the container then root will be used, try this: docker exec -u nobody binhex-nzbget /usr/local/share/nzbget/nzbget -c /config/nzbget.conf -L H

It will be a corrupt database, extremely common sadly with plex, see Q4:- https://github.com/binhex/documentation/blob/master/docker/faq/plex.md

you got it, i dont have anything to do with the code if crafty, i simply package up what is supplied by the crafty dev's into a unraid user friendly format.

i would suspect the issue is corrupt configuration, but your best bet for support is to talk directly to the crafty dev's, raise a issue here:- https://gitlab.com/crafty-controller/crafty-4/-/boards#/ or if you prefer chat then talk to them on discord:- https://discord.com/invite/XR5x3ZM