anethema

Latest completely wiped all plugins including the default installed one. Dropped back to an earlier tag fixed it

EDIT: Pinning to the 1.5.1 tag made it stop happening so it is definitely an issue in the latest update. Mine stopped working. invokeai just seems to do some reinstall loop then the container stops. Any idea? (I've made no other changes. My config is here: And here is the last log before the container stops:

Hey just looked at the issue and it appears that someone did make a few basic changes and got it working with the GPU. https://github.com/serge-chat/serge/issues/43#issuecomment-1792070396 Any idea if it would be possible for you to add that into your template etc to make it work ?

Well just reporting back that mounting as rclone works MUCH better. Restores at full speed. The checking files and anything folder related is pretty slow, but the transfer itself is fast. So it seems like its a problem with cloudberry itself, in their B2 implementation.

I'm not holding out hope for it to be much faster, as just the repository sync is on track to take two full days. I will see about the restore once the sync is done, but it really does seem like something is broken with cloudberry itself. Maybe some setting or something, but it DOES transfer for me, just horribly slowly, and I've now verified on the unraid machine itself that it works very quickly in unraid itself.

I'm actually trying another route now. I have my B2 bucket mounted as a folder in unraid using rclone. I can copy files out of the FUSE folder at full line speed of my network, so it is def not backblaze being slow. The folder structure is just synchronizing now in cloudberry so we will see how a restore works with that.

Maybe but it is taking like 5mins to download a 100kb .png file. It really seems to be just going very slow.

It does not even create a VM for me. I get this from the helper script after I got the notification it was ready: It does not create any VM for me. EDIT: Removing the entire macinabox appdata, app, and the /mnt/user/system/custom_ovmf folder fixed this for me.

I'm having absolutely abysmal speeds using cloudberry to pull from B2. Tried a download of files from the backblaze website myself and it goes full line speed of my internet. 2kb/s Anyone have any idea why this would be happening? Lost my plex folder but it will be a long long time restoring at this pace heh.

Just wondering if the steamcache is using an odd region? I am only getting 3-4MB/sec rather than the normal 16 on the first download(to SSD). My Steam is set to Canada - Edmonton on the downloading machine. When I download for the first time through the steamcache i get: 10.3.3.171 / - - - [14/Nov/2019:15:25:49 -0700] "GET /depot/583952/chunk/6fe88c8bc485c906703424d6dc8be0f20168823b HTTP/1.1" 200 103152 "-" "Valve/Steam HTTP Client 1.0" "MISS" "cache1-sea1.steamcontent.com" "-" So using a seattle server rather than the one I have set in steam?

My filebot has also long ago stopped scanning for folder changes. Is there any way to fix this?

I tried installing it with no luck. The following error happened: root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name='telegraf' --net='host' --privileged=true -e TZ="America/Phoenix" -e HOST_OS="Unraid" -e 'HOST_PROC'='/rootfs/proc/' -e 'HOST_SYS'='/rootfs/sys/' -e 'HOST_ETC'='/rootfs/etc/' -e 'HOST_MOUNT_PREFIX'='/rootfs/' -v '/var/run/utmp':'/var/run/utmp':'ro' -v '/var/run/docker.sock':'/var/run/docker.sock':'ro' -v '/':'/rootfs':'ro' -v '/sys/':'/rootfs/sys':'ro' -v '/etc/':'/rootfs/etc':'ro' -v '/proc/':'/rootfs/proc':'ro' -v '/mnt/user/appdata/telegraf/telegraf.conf/':'/etc/telegraf/telegraf.conf':'rw' -v '/mnt/user/appdata/':'/appdata/':'rw' 'telegraf:alpine' e61de4249ea43e396f7c28f26e28a357977118ad2e80763cafd8763d9fce51fd /usr/bin/docker: Error response from daemon: OCI runtime create failed: container_linux.go:348: starting container process caused "process_linux.go:402: container init caused "rootfs_linux.go:58: mounting \"/mnt/user/appdata/telegraf/telegraf.conf\" to rootfs \"/var/lib/docker/btrfs/subvolumes/bc257a35e85fcd9052cd8506e712ca66b6e3ef3c1d9a0eea3132ca5537ad630a\" at \"/var/lib/docker/btrfs/subvolumes/bc257a35e85fcd9052cd8506e712ca66b6e3ef3c1d9a0eea3132ca5537ad630a/etc/telegraf/telegraf.conf\" caused \"not a directory\""": unknown: Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type. The command failed. Any idea? EDIT: Ah, the default container config looks like it tries to map to /etc/telegraf.conf instead of /etc/telegraf. Fixed it.

Ya it just sits there. Nothing I can do seems to make it actually detect folder changes to run again. [2018-09-22 19:35:44] FileBot: Finished running command. Exit code was 0 [2018-09-22 19:35:44] FileBot: Waiting for new change

Run command: root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name='FileBot' --net='bridge' -e TZ="America/Phoenix" -e HOST_OS="unRAID" -e 'WIDTH'='1280' -e 'HEIGHT'='720' -e 'USER_ID'='99' -e 'GROUP_ID'='100' -e 'UMASK'='0000' -e 'INPUT_DIR'='/input/downloads/complete' -e 'OUTPUT_DIR'='/input' -p '3389:3389/tcp' -p '9898:8080/tcp' -v '/mnt/user/Media':'/input':'rw' -v '/mnt/user/appdata/FileBot':'/config':'rw' 'coppit/filebot' a444df103ad6a940c8b8f1c329a6062cb5e616388ff33db51b20e4efac596b71 When starting/restarting the container, it scans the input directory properly, then hardlinks the files over. When just letting it sit and monitor though, no changes are detected. This used to work and no config changes have been made since it stopped working. Thanks for the help! generalnasty-diagnostics-20180912-1826.zip

My filebot is mostly working fine, but unfortunately it has stopped detecting folder changes automatically. Any idea why that might be? If I restart the container to run it, it works fine.