Vynce

I have one 32GB DDR5-4800 module (Kingston KSM48E40BD8KI-32HA). I'm currently only using ~10GB, so 32GB is plenty for now. I didn't get anything faster since the i5-12600K only supports up to DDR5-4800 and I don't have any interest in overclocking 🙂.

Unraid 7.0.0 is working better for me on the mATX board because I no longer have the AST GPU blacklisted and the BMC/AST GPU and iGPU work concurrently now. i.e. I had previously followed this post and now I deleted /boot/config/modprobe.d/ast.conf. I don't have any additional PCIE GPUs installed. Asus Pro WS W680M-ACE SE (mATX) Intel Core i5-12600K One 32GB DDR5-4800 ECC module (Kingston KSM48E40BD8KI-32HA) BIOS 4101 (released on 2025/01/14) BIOS Settings (optimized defaults with these changes) Advanced Platform Misc Configuration Native ASPM: Enabled CPU Configuration CPU - Power Management Control Intel SpeedStep: Disabled System Agent (SA) Configuration Graphics Configuration Primary Display: PCIE iGPU Multi-Monitor: Enabled PCH Storage Configuration * Hot Plug: Enabled APM Configuration Restore AC Power Loss: Power On Power On By PCI-E: Enabled Onboard Devices Configuration HD Audio: Disabled Q-Code LED Function: Auto SlimSAS Configuration: SATA Boot Boot Configuration Fast Boot: Disabled Boot Logo Display: Disabled Tool Armoury Crate Download & Install ARMOURY CRATE app: Disabled

I'm also running into this issue with HAProxy on pfSense forwarding to Unraid and I think I've found a solution. The weird thing is this issue seems to be intermittent for me. I also sometimes get HTTP 503 errors when doing docker container updates. The live progress UI will stop updating and I can see 503 errors in the browser inspector. TL;DR: set the HAProxy client and server timeouts to 60000. Seems to work for me so far. The HAProxy logs show that the client connection (cD--) is timing out after 30s (0/0/24/1/30028). See this page for details on the HAProxy log format and the timers, and this page for the session termination state descriptions. Internal~ Unraid_ipvANY/Unraid 0/0/24/1/30028 101 369 - - cD-- 4/4/1/1/0 0/0 "GET /sub/dockerload?last_event_id=1696795636%3A0 HTTP/1.1" So I bumped up the client timeout in the HAProxy frontend config from 30s to 60s. But then I started getting server connection (sD--) timeouts after 30s: Internal~ Unraid_ipvANY/Unraid 0/0/36/1/30039 101 369 - - sD-- 5/5/1/1/0 0/0 "GET /sub/dockerload?last_event_id=1696795636%3A0 HTTP/1.1" So I bumped up the server timeout in the HAProxy Unraid backend config from 30s to 60s. That seems to work. My guess is that the Unraid console sends a keepalive packet every 30s. With the HAProxy default timeout also at 30s, HAProxy will often end up killing these connections. I have no idea if a 60s timeout is optimal or if Unraid is doing something unusual that doesn't play well with HAProxy. Client timeout: pfSense -> Services -> HAProxy -> Frontend -> Edit Unraid frontend -> Client timeout -> 60000 Server timeout: pfSense -> Services -> HAProxy -> Backend -> Edit Unraid backend -> Server timeout -> 60000 https://serverfault.com/questions/504308/by-what-criteria-do-you-tune-timeouts-in-ha-proxy-config https://delta.blue/blog/haproxy-timeouts/ https://www.papertrail.com/solution/tips/haproxy-logging-how-to-tune-timeouts-for-performance/

That sounds exactly like the issue I saw. Try moving all albums that include jpg artwork to another folder temporarily and see if that fixes the Remote app issue.

The default username/password for forked-daapd seems to be admin/unused, but there's no actual web interface there in 25.0. A lot of the commits since 25.0 look like they're related to adding a web interface, so the web interface instructions must be for that or maybe from a previous web interface that was removed from this fork (?).

Just as a heads up for anyone else trying to get this working, forked-daapd 25.0 seems to crash repeatedly when the iOS Remote app requests album artwork and the artwork is stored in jpg format -- artwork in png format works fine. It doesn't matter if the artwork is embedded in the audio files or stored as a separate artwork.jpg file in each album folder. I don't see any obvious issues in the logs after turning on debug logging and I haven't been able to find any crash logs anywhere in the docker container. I tried rolling back to forked-daapd 24.2 by pulling the 115 tag, but I couldn't get remote pairing to work there. The work around I eventually came up with was to export each album's artwork and save it as artwork.png in each album folder. This works because forked-daapd looks for an artwork.png/jpg file in the folder before trying to extract any embedded artwork from the audio files, so the audio files can still contain embedded jpg artwork. There have been a few artwork-related changes in forked-daapd since 25.0, so I was wondering if it's possible to build the latest source inside the container to test it out? I didn't want to open a new issue in the forked-daapd project without first checking if the issue is still present at the tip of master.

What I was seeing is that the main Crashplan port was getting set to 0 and the service port set to 1 by 01_config.sh whenever the container was started. This would not occur if you set the TCP_PORT_4242 and TCP_PORT_4243 variables in the docker config. I did not have those variables set. grep -nHE '(location|servicePort)' /mnt/cache/appdata/crashplan/conf/my.service.xml /mnt/cache/appdata/crashplan/conf/my.service.xml:9: <location>0.0.0.0:0</location> /mnt/cache/appdata/crashplan/conf/my.service.xml:18: <servicePort>1</servicePort> I launched a bash shell in the container: " docker exec -it CrashPlan bash " and made the edits to 01_config.sh as described in my previous post. This allows Crashplan to start with the correct default ports and I'm able to connect to it again now.

There are a couple of errors in the sed commands in 01_config.sh which are causing Crashplan to be configured with bad ports and makes it unreachable. ${TCP_PORT_4242} on line 46 needs to be replaced with ${SERVICE_PORT} and ${TCP_PORT_4243} on line 47 needs to be replaced with ${BACKUP_PORT}

Thanks, that fixed it for me.

VNC appears to be broken with the most recent update: # docker exec -it CrashPlan bash root@unRAID:/# /etc/service/tigervnc/run [...] Sat Oct 1 17:34:27 2016 vncext: VNC extension running! vncext: Listening for VNC connections on all interface(s), port 4239 vncext: created VNC server for screen 0 XKB: Failed to compile keymap Keyboard initialization failed. This could be a missing or incorrect setup of xkeyboard-config. Fatal server error: Failed to activate core devices. root@unRAID:/# /etc/service/novnc/run Must have netstat installed

2GB in both servers. (didn't vote because 2GB is missing) voted