binhex

done, please pull down image in an hour from now.

new image built, it turns out the upstream issue was a non issue in the end, i had forgotten i had switched over to using emby compiled ffmpeg as opposed to arch ffmpeg due to a bug in seek in later versions of ffmpeg. In any case i have now fixed it up and from my very brief poke around it looks ok, please pull down the latest image and let me know if its working ok for you guys.

ok i did manage to take a look and it looks like a broken ffmpeg installation, i have flagged it as a bug upstream, link to bug report:- https://bugs.archlinux.org/task/74691

so are you saying all sessions in that file can safely be deleted on startup? there are no cases where previous session info in the web.conf need to exist?, just asking as i dont actively use deluge any more so need somebody with first hand experience of this. if this is the case then i can put in some code to clear session info down on startup.

Hi guys I will take a look at this tonight Sent from my CLT-L09 using Tapatalk

always use udp wherever possible for vpn connections, it will always be faster than tcp (unless your isp throttles udp)

Q5:- https://github.com/binhex/documentation/blob/master/docker/faq/unraid.md

indeed!, all files and folders in the /config folder should be set to owner nobody group users, the ONLY exception to this is the supervisord.log files, which are written as root, as supervisor is running as root user. im quite surprised it was file permissions in the end, as it still doesnt explain why it worked on the rollback to the previous version, that makes NO sense to me whatsoever! as you arent rolling back any files in /config, maybe the previous version doesnt need to write to the db and thus doesnt actually care its read only *shrug*.

i would assume there is some database corruption going on here, probably the later version has attempted to upgrade the database by inserting objects into the sqlite database and failed leaving your database in a bad state. When you rollback to the previous version its unaware of the corruption as it doesn't reference the new (corrupted) inserted objects and thus works fine, this is all guess work here btw. so i can confirm the latest version does work fine, im using it myself with no issue, so im happy the issue you are seeing is not a sonarr issue. So onto the fix, you can attempt to recover your database (https://wiki.servarr.com/useful-tools#recovering-a-corrupt-db), or simply rename the sqlite database file and then restart the container to force the database to be created from scratch, this will of course result in configuration loss.

its simple enough, you left click the icon, select edit and then click on 'advanced view' then scroll to the bottom and click on ' Add another Path, Port, Variable, Label or Device' and then 'Config type' is 'path' set' container path' to /<name of your choice NOT media> and then set 'host path' to /<path to your unassigned disk> e.g.:- container path /backups host path /mnt/ud/backups

contacted the upstream dev and he fixed it up, new image was built last night, please pull down.

yep, just waiting for upstream to fix the package:- https://aur.archlinux.org/packages/code-server

Not saying that's not true, but that has not been my experience to date. Sent from my CLT-L09 using Tapatalk

looks like you are not alone:- https://github.com/qbittorrent/qBittorrent/issues/16916 if you simply want a fix then roll back to the previous version, see Q5 here for how to do it:- https://github.com/binhex/documentation/blob/master/docker/faq/unraid.md EDIT - for me last know working is 4.3.9 and im sticking on that version until all the bugs in the 4.4.x releases have been fixed, if you want a stable experience you may want to do the same.

you are probably best off getting the crash report read by somebody who knows the internal workings of minecraft (not me) so you might want to post on the minecraft support forum (assuming they have one). if i were to guess though, i would simply assume that your server hardware is not able to keep up with the minecraft players demands and this is causing minecraft to crash, but yeah try somebody more competent than me. EDIT - worth a look at some suggestions here:-

I'm running both myself, no crash for me, perhaps you are running out of memory and OOM killer is kicking in. Sent from my SM-T970 using Tapatalk

if you are using vpn provider PIA then simply delete that file and restart the container, if you are using another provider then please re-download the wireguard config file from the vpn providers website.

sounds like a screwed up wireguard config file, check the file /config/wireguard/wg0.conf i suspect you will find the PublicKey value is empty and thus invalid, it should look something like this (fake data):- PublicKey = fghgfh/vnL0vcSADFASDFSD343423DFGEZGarVm6gB0=

when you say 'it' im asuming you mean your lan internet connection right?. so everything on your lan suddenly drops to 1Mb/s or there abouts?

you realise you are running this with the vpn disabled right?, so no protection, from your log:- 2022-04-17 03:28:38.281269 [info] VPN_ENABLED defined as 'no' 2022-04-17 03:28:38.303147 [warn] !!IMPORTANT!! VPN IS SET TO DISABLED', YOU WILL NOT BE SECURE as to the cause of the slowdown, its possible that your isp is throttling your torrent traffic as its visible, and/or you havent setup port forwarding correctly.

reserved

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

Authentication failure, from your log:- 2022-04-14 18:45:31 SIGTERM[soft,auth-failure] received, process exiting Check your username and password Sent from my CLT-L09 using Tapatalk

you shouldn't really need to change the ul rate that much, i have mine set at ul of 45 KB/s and i max my line out at times on dl at around 4MB/s, having said that bittorrent has always had a tit-for-tat system so you maybe rewarded with faster download rates by simply uploading faster - just ensure you dont max out your upload rate, otherwise this will start to negatively effect your download rate.

have a look at Q6 for some possible causes:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md