KernelG

In my case, it was definitely specific to Unraid 6.8.x, even in Mojave. I had held off upgrading both for a while and did the Unraid 6.8 upgrade first.

Switching Case-Sensitive Names to 'Yes' on my Time Machine user shares seems to have solved most of it here. My large (~2.6 TB) backups are completing normally again. No other changes. Unraid 6.8.3 + macOS Catalina 10.15.6 (just updated, same in Mojave)

I've been using authenticated SMB since the start, and also created a completely new share (again). Time Machine will write a few hundred GB of its initial backup, but seems to get slower as it goes. By the time it reaches 1 TB, after 4-5 days, it's crawling. It had been working perfectly with 3 TB until Unraid 6.8, which I only recently upgraded to after waiting for any issues to show up. Heh. The only difference I can think of is that I'm using my main user to authenticate, same as for other shares. Did you create a new user just for Time Machine?

ControlR is cool for mobile, but I'm using Margarita for some desktop specific things like quick/auto-mounting volumes, notifications, etc.

Indeed, the new login page authentication in Unraid 6.8 seems to have stymied Margarita (or something else in 6.8 has). I messaged Pixeleyes via their website last week. No response yet.

I love that Unraid has a legit ecosystem built around it that I didn't even know about 2 years ago, and that it "just works" with all the hardware I've (carefully) thrown at it so far. In 2020, I'd like to see continued development of remote access either via the new built-in VPN or a la Plex style for remote admin, mobile apps, etc.

I just ordered an Unraid T-shirt and sticker sheet. Nice deal with that current promo code! Also, I've been following on Twitter since I don't know when, as @GlennGutierrez.

I did the same thing, attempting the latest new build and reverting to v19.x, only to find a 404 error where the web UI used to be. I also tried editing the .conf file, but had no luck. I ended up pulling a copy of the .conf file from the previous week's backup, and now all is well again on v19. If it helps, my line 64 of that file is currently: WebDir=/usr/share/nzbget/webui

Another unscheduled parity check here w/6.6.1. I have it set Custom: 07:00, Wednesday of the first week in Mar, Jun, Sep, and Dec. It started up this morning at 7, which is all correct except for the month. I toggled a couple of the variables and re-Apply'd. (EDIT: I changed the time to 10:00, saved, and it just started up again at 10 even though it's still the wrong month. So it doesn't seem to be a saved data format issue.) Aside from this, it's been very smooth sailing. The new UI looks great on a color calibrated display.

No luck here. I switched binhex-nzbget back to "latest", version 20.0-1-02 was installed, and the first file it handled was downloaded, underwent a quick repair, then seemed to get stuck on unpacking. Back in binhex-sonarr (latest, 2.0.0.5228-1-01), activity showed a pause icon on that file. Things remained that way for at least 15 minutes (usually takes seconds on this machine) before I paused the remaining downloads and reverted NZBget to 19.1-1-02. That same file was then almost instantly handed back to/processed by Sonarr and seems perfectly fine. Subsequent downloads were also processed normally. Anything I can test, specifically?