sonofdbn

I found that I could ping the remote server via its IP address, but not by its name. After some digging around I found that the unRAID system was using my router and Pi-hole container for DNS services. So I manually added the remote server name and IP address (it's static) to my Pi-hole DNS list and now everything seems fine. I don't know if this is the optimal solution, but at least it's working.

Sorry, should have uploaded Diagnostics automatically. A quick look shows that UD found that the remote server was offline, but that server is definitely running. tower2-diagnostics-20230602-0002.zip

I'm trying to add an SMB remote share; the source is on another unRAID server. Adding the share was very straightforward: the UD GUI found the server and after entering credentials it listed the various available shares, and I selected Movies. After mounting this share, my Plex container can access it. But although I set the share to auto-mount, after restarting the server the share doesn't get mounted and in fact the Mount button is greyed out. (The source server is on the whole time.) I've set network delay to 20 seconds, if that's an issue. What should I be doing to get the share to auto-mount? If I remove the share and add it back as a new share, it works fine. (I'm on 6.11.5.)

It's been a long time since I last looked for a PSU. Having looked around, I now realise it's actually a little difficult to get the lower wattage PSUs, at least where I am.

A little further digging around - the manufacturer seems to be Changwang and their website has BIOS downloads here and other things. I had to use Google translate a bit.

That's a very interesting build - maybe I should try something like this rather than trying to add some horrible homemade DAS to my current server. So tidy as well, compared to my cable mess! Do you need a 750W PSU? I'm running 10 hard disks off a 650W Corsair PSU. Not criticising - just budgeting 🙂

I found a relatively simple way of finding the GUID of a flash drive in Windows: 1. Get USBDeview (free) from NirSoft here. 2. Run USBDeview and find the flash drive. 3. Double-click on the flash drive and a Properties window will pop up with lots of fields. 4. My GUID comes as 4 digits - 4 digits - 4 digits - 12 characters - first 4 digits are VendorID - next 4 digits are ProductID - next 4 digits and the 12 characters come from the last 16 characters of Serial Number (which is ridiculously long) (This information can also be extracted from just the Instance ID field.) This is basically from looking at just one flash drive, so it's certainly not extensively tested, but this might be one way of checking for useable GUIDs before trying to flash unRAID onto the drive.

I appreciate the suggestions, some of which I was aware of, but it comes down to cost. While maybe not technically server level, these are expensive solutions, including the (very interesting) AMD iGPU transcoding thread you linked to, which requires DD5 RAM. I do admit I didn't know that Ryzen 7000 series CPUs included iGPUs. While I know that ECC RAM is not an unRAID requirement, I do prefer it, if only to give me a little peace of mind. But it does seem to complicate and severely limit the range of options. I did look at older used Xeons, but then (of course) they generally don't support transcoding. The tech gods truly don't like ECC and transcoding being done on one CPU. I would prefer to keep everything in one box, but one alternative suggested elsewhere is to offload Plex onto a used small desktop PC with at least an 8th gen Intel CPU to do the transcoding (while keeping the media files on unRAID).

I'm planning a second unRAID server, and ideally I'd like to have ECC and be able to handle some Plex transcoding from 4K. But it seems incredibly difficult to find a straightforward solution that doesn't involve server level hardware and expense. If I want ECC, seems like an AMD CPU is the way to go, otherwise I have to go with Xeon CPUs. But Plex hardware transcoding doesn't support AMD CPUs, and Quick Sync on Intel seems to be the optimal transcoding solution. (Partly for noise and power reasons, I'd prefer to avoid getting a separate GPU just for transcoding.) Are there some good solutions to this? I rather hope I've missed something obvious. (I do have some other things I might want to do with the server, but I'm trying to tackle things one at a time.)

My 2 cents as a non-expert: If you want to reduce the risk of data loss as much as possible, then ECC RAM will help. How much it will help is the big question. I haven't seen any empirical evidence of the benefit of ECC RAM. I believe it's entirely possible that you could run your server for years with non-ECC RAM and never have an issue that ECC RAM could have avoided. It's a bit like travel insurance - you could fly many times and never have a problem. But if disaster strikes, you (or at least your beneficiaries) will be very glad you had travel insurance. If you have the budget and if you can get the components, then I would say go with ECC RAM. Personally I do have ECC RAM, but am not sure I would get it for a new server. But that's because where I am it's difficult and/or expensive to get motherboards that support it. And honestly I got tired of trying to work out which AMD CPU/motherboard combinations actually officially support ECC RAM. OTOH, Intel solutions seem to be very expensive.

Unfortunately I lost the network connection again. Running my untrained eye over the syslog, It looks like the same problem. I've attached a truncated syslog. Both VMs, Win 10 and Win 11 were running at the time. I'm going to try running just the Win 10 VM, which I've been running for a few years (without this problem). If the cause of the disconnect is indeed the Win 11 VM, the next question is how do I fix it? syslog-192.168.1.14.log

I think I was running two VMs at the time, one Win 10, the other new one, Win 11. Do you mean try with no VMs at all, or just one of the VMs? And if so, which one was the cause? (I should be able to identify by CPU number?) In any case, touch wood, hasn't happened again since rebooting.

Tonight I suddenly lost my network connection to my unRAID server. First time it's happened, and I haven't touched the hardware for at least a week or more. Only significant change over the last week was adding a Windows 11 VM and isolating some CPUs. I had to reboot to get the server back online. I've attached syslog and diagnostics. Would appreciate any suggestions about what went wrong and how to fix it. syslog-192.168.1.14.log tower-diagnostics-20230506-2305.zip

In the GUI only a few torrents were listed, but I have many more that should have been seeding, and on the docker page the container was showing some percentage of CPU activity (2%-3%), not consistent with no/minimal activity. Anyway, getting a bit desperate, I tried installing the libtorrentv1 version as a new container. I started the new container but although I had changed the GUI port I didn't get any login screen. Then I realised that the original container (4.3.9-2-01) was still running, and perhaps illogically thought that might be the problem. So I stopped it and went looking for differences in the appdata folders. There I found that I had messed up because although I changed the container name for the new version, I had forgotten to change the appdata folder; so it used the same appdata folder as my current problematic container. So I stopped the new container, gave it a new appdata folder and restarted. Same problem, couldn't get to the GUI. So stopped it, and started the old container to see what had been damaged by installing into the same folder. But miraculously the old container was now working! So problem solved, but no idea what fixed it. I realise there's zero interest in this from anyone else, but I leave this here in case it helps @binhex in some way.

I've done that a few times and the ports have always matched. Thanks for checking the log file. But there's some other weirdness going on that I've just noticed. Getting late here, will post later.