binhex

Hi, sadly i had to archive the medusa image, i was having some issues building it at the time and as this support thread was dead (last post ws over a year ago before yours) i called it day, i would encourage you to make the switch over to Sonarr, it really is pretty good, not perfect but still pretty solid. p.s. thanks for the donation.

This has now been done and is included in the latest image, please pull down at your convienience.

what is the url you are going to in your web browser?

Ah excellent!, I love a good ending to a story :-) Sure, it is highly tailored to what i want, which is the following: no porn whatsoever i am into emulation, so i classify rom file types. no unknown torrents, if bitmagnet cannot clasifiy it i don't want it. Gistbitmagnet classifier.ymlbitmagnet classifier.yml. GitHub Gist: instantly share code, notes, and snippets.This gives me a pretty clean library of just what i want.

It most probably will do, yes, because bitmagnet process will not be present, i should be able to add some code in to pass a flag to the healthcheck script i wrote to turn off healthchecking if a vacuum/reindex/backup/restore process is in operation. p.s. I was not aware of the docker image autoheal.

OK so do you know if there is any chance of a release from the develop branch any time soon (assuming that is what you mean by the separate branch)?, if not then i will switch to clone from develop branch until things stabilise.

duplicated my postgres directory in case of issues and ran vacuum on it (by setting the env var ) and it took around 10 minutes and finished successfully for me, here is a snipet of what i see in my log: 2025-12-27 14:28:44,192 DEBG 'start' stderr output: 2025-12-27 14:28:44.192 GMT [402] LOG: checkpoint complete: wrote 8355 buffers (51.0%); 0 WAL file(s) added, 1 removed, 32 recycled; write=5.614 s, sync=0.094 s, total=5.885 s; sync files=5, longest=0.029 s, average=0.019 s; distance=540652 kB, estimate=543696 kB; lsn=1C1/3D400280, redo lsn=1C1/1E3FED20 2025-12-27 14:28:44.192 GMT [402] LOG: checkpoints are occurring too frequently (6 seconds apart) 2025-12-27 14:28:44.192 GMT [402] HINT: Consider increasing the configuration parameter "max_wal_size". 2025-12-27 14:28:44.192 GMT [402] LOG: checkpoint starting: wal 2025-12-27 14:30:00,540 DEBG 'start' stderr output: 2025-12-27 14:30:00.540 GMT [402] LOG: checkpoint complete: wrote 3520 buffers (21.5%); 0 WAL file(s) added, 0 removed, 33 recycled; write=76.104 s, sync=0.167 s, total=76.349 s; sync files=22, longest=0.165 s, average=0.008 s; distance=544701 kB, estimate=544701 kB; lsn=1C1/58E8E438, redo lsn=1C1/3F7EE510 2025-12-27 14:30:15,915 DEBG 'start' stderr output: 2025-12-27 14:30:15.915 GMT [402] LOG: checkpoint starting: wal 2025-12-27 14:30:22,463 DEBG 'start' stderr output: 2025-12-27 14:30:22.463 GMT [402] LOG: checkpoint complete: wrote 1011 buffers (6.2%); 0 WAL file(s) added, 0 removed, 33 recycled; write=6.394 s, sync=0.077 s, total=6.549 s; sync files=6, longest=0.047 s, average=0.013 s; distance=536757 kB, estimate=543907 kB; lsn=1C1/7ECAADE8, redo lsn=1C1/6041BB30 2025-12-27 14:30:24,821 DEBG 'start' stderr output: 2025-12-27 14:30:24.821 GMT [402] LOG: checkpoints are occurring too frequently (9 seconds apart) 2025-12-27 14:30:24.821 GMT [402] HINT: Consider increasing the configuration parameter "max_wal_size". 2025-12-27 14:30:24.821 GMT [402] LOG: checkpoint starting: wal 2025-12-27 14:30:28,905 DEBG 'start' stdout output: VACUUM 2025-12-27 14:30:28,906 DEBG 'start' stdout output: [info] FULL VACUUM completed successfully It did has some effect, disk space cosumed for the postgres directory went from 23GB to 20GB after the vacuum.

I really wish there was, but sadly there is no slick way to do this, you could look at the template and then copy in the missing env vars into your existing user template on your flash drive, but that is not the most easiest operation. Really your options are manually add them in, or stop the old container, make a note of your settings and then create from CA and replace with your settings from the old template, then finally delete the old template.

I'm sorry to hear you had a rough time with this, it SHOULD work correctly, i will do some investigation into this and try running a vacuum myself, it is entirely possible the database has to be fully dumped out, re-arranged and then imported back in so it maybe that what you saw is normal behaviour and it just takes a very long time (and lots of space!). A unhealthly container will NOT restart unless you set the HEALTHCHECK_ACTION to be 'kill 1', by default that is not set and it will simply be marked as unhealthly awaiting the action from the user, so going unhealthly should not be the cause. This is the code that performs the vacuum: https://github.com/binhex/arch-bitmagnet/blob/14ecd5d440b235f40a4ca17ff86abec4aea3e011/run/nobody/start.sh#L232 As to what that a vacuum does i can point you at the official documentation: https://www.postgresql.org/docs/current/sql-vacuum.html

Yes, there is another env var to control this: Container Variable: POSTGRES_BACKUP_RETENTION_DAYS Number of days to retain database backups. Older backups will be automatically deleted. All env vars are visible in the latest template, so if you are unsure what it is available then go to CA, search for bitmagnet and 'install' (but cancel out if you don't want a new container creating), this will show you all env vars (ensure you click on 'show more settings...').

FYI i have reversed the defaults for POSTGRES_BACKUP_DB and POSTGRES_SCHEDULED_BACKUP, both are now set to 'false', so if not defined backups will be off.

I totally get that, no pressure from me on this, my only concern is that only one person has keys to the castle, perhaps promoting a trusted person just in case Cas gets run over by a bus might be wise :-) A simple function, it doesn't auto update in the background, it's only on start that it updates for now but i think it will suffce.

Hi ambipro, yes i believe from memory both are included in the latest image. Well i would assume you would need to remove pkg_resources from your source code or pin the version of pkg_resources in your next release (as stated in the warning), nothing i can do here and as you say it's a warning not an error so I'm not concerned, but users do see it an for whatever reason seem concerned over it (it's been mentioned multiple times).

Nope, that's down to the Deluge developers to sort that out.

I used the AUR seerr package here, which largets latest release from the seerr github repo:- https://github.com/seerr-team/seerr/releases

reserved

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

Apologies if it caused issues, i was in two minds as to whether to turn on backups by default, but as i had first hand experience of db corruption, along with other people in this thread i decided to err on the side of caution and turn it on. I am a bit surprised it knocked your pool out though, i am seeing db backup size of around 1.5GB for 2.5 Millions torrents, is your db backup significantly bigger than this?.

in a word, no, probably db corruption that's the normal issue, open the file /config/Plex Media Server/Logs/Plex Media Server.log and check for the word corruption or error .

Right now there is no gluetun support repo, or at least not one i have created as i have simply created a unraid template that points at the official image, what i might do is a create a generic templates support thread but for now you can post here.

OK so all of my images now include baked in Docker healthchecking, this performs the following: check you can connect to https over the internet check you can resolve names over the internet check the application process is running So if you set deluge 'extra parameters' to include '--restart=always' and set the 'HEALTHCHECK_ACTION' value to 'kill 1' then if any of the above fails then the contianer will be restarted, this should include loss of access to the vpn, and in fact unraid itself will restart all containers routed through another container if the container is rebuilt or restarted, the only caveart to that is that it does not handle manually spun up containers outside of unraid (docker compose). Having said all of the above, you may want to consider coming over to my solution instead :-), this involves setting up gluetun and using that to route network connectivity for all other containers, i have even included automatic port forwarding assignment for deluge which is especially useful for VPN proviers that use dynamic ports (PIA, ProtonVPN), i have also included monitorng of the port to ensure the incoming port is open, if the port is closed then gluetun vpn is bounced, if the port changes then the application is reconfigured to use the new port, all done automatically for you.

In case anybody is running Windows and would like a neat script to integrate the locking and unlocking of selected folders then let me know and i will share the code, i use this ALL the time now and it does reduce the pain of having your media immutable but wanting to change the odd file/folder, it's super quick as it only runs chattr for the selected folder, a quick demo: https://drive.google.com/file/d/1s4IJL4ofD58njFVre--vD8ZJzBYHAX1H/view?usp=sharing

If you run with lock-type='both' then you are stating you do not want to permit ANY modifications of any directories within the given share, so yes you will be unable to create new folders. So I would assume (i have not infected a machine to confirm this) if you set this to lock-type 'files' then certain (uncommon) ransomware strains would be able to encrypt the directory name but not the contents of any directory, so for example you may end up with something like: Share - GH%^&%$£"£%^" (encrypted dir name) - My.TV.Show.mkv (unencrypted filename)You should still be able to navigate to the path and the data should be accessible but it could be a bit messy trying to identify which directory contains which file, it's not a perfect solution all said and done but it does give you some protection, directory encryption is rare, most ransomware strains encrypt files only, so in this scenario no_ransom would fully protect you (assuming you lock all files). For me personally i run with lock-type='files', this gives me the flexibility to create new files/folders and rename folders without having to lock and unlock all the time.

I will create a seperate docker image, you can then shutdown overseerr container, start defining the new container config for seerr and point it at your existing overseerr config path and you should be set (assuming seerr is compatible with overseerr configs)

I have run this image using cache drive formatted as XFS and it seems stable enough, although indexing your shared media is EXTREMELY slow (can take 10-15 minutes) in comparison to something like nicotine+ (less than a minute). I can't really comment on whether ZFS and BTRFS cause problems, maybe somebody else will chip in.