ConnerVT

Could be a lot of things - corrupted database, bad mapping, incorrect file permissions, bad characters in file names, something wonky with a download client. Start here: Google Search

Per the release docs, 7.1.3 uses the 6.12.24 kernel.

Glad to see I'm not the only one who does this.

Because arrays are cool.

A follow up, as I had some time this morning to play with this. I have a list of 20+ artists I wished to add to Lidarr. By doing the following, I was able to add about a dozen of them: Search for the artist in Musicbrainz Copy the ID part out of the URL (looks like 56cd15a1-0d74-438b-8244-c96ffe1cae03) In the New search, add this: lidarr:56cd15a1-0d74-438b-8244-c96ffe1cae03 I was having about a 50% success getting the needed hit on the search. The other 50% was the error that it has been reporting for a while now. Repeated search of the same ID was never successful (in my short time testing) so I suspect it hasn't been cached yet in the app's database. So hopefully this is a sign that there is a light at the end of the tunnel. Fingers crosses.

Yes, I saw the same. Happens both with the text search and when using the lidarr:<MusicbrainzID> in the New search. In the Github discussion about this, three days ago they said the new database was rebuilding, and they are routing around 60% of the requests to the new server as the cache builds. So we can only hope this resolves itself in the next few days.

Plex doesn't use GPU for creating thumbnails. Hardware transcoding video is the only task which Plex uses the GPU. And if you are transcoding something which uses burned-in subtitles, that will fall back to the CPU as well.

What JorgeB writes is correct (He almost always is). But for torrent, there is other things to consider, as everyone has different work loads, depending on what they are doing: How many files will be active at one time? How much data (total storage size) will be actively downloading/seeding? How fast is your up/down WAN speed? Are the files you are torrenting recent/popular, that there will be many requests for them? I no longer torrent, but I did in the past. It can put quite the burden on your system, depending on the answers above. Many files, actively seeding, and a fast pipe will have a lot of disk activity. As files tend to be more fragmented on the drive (due to being written in segments as downloaded), spinning array drives will be thrashing around when reading data to upload. If you are planning on a lot of torrent activity (or seeding for a period of time) it may be best to have the torrent files on a dedicated pool SSD (or NVMe) while they are actively seeding, then moving them to your array once they are completed (and you no longer wish to seed). This prevent the spinning drives in your array from being busy all the time while active torrents exist. It also will defragment the files when copied from the SSD to the array. Most torrent clients have some sort of function for managing the movement from the "download" drive to the final drive location.

Also, are you sure that it is actually that hot? For it may not be reporting the correct temperature. I have a Leven JPR700 NVMe in my server that reports it is 48C all of the time, regardless of how much it is being accessed. There are 2 SSD drives that are almost always around 21-27C, and the spinning HDD mainly sit in the low 30C. The Leven has a nice heat sink on it, which was used for years on other drives successfully. Looking at the drive's Attributes tab in Unraid, I have 3 sensors reported. When I stress the drive only the last one, which sits at a more expected 35C, rises in temp in a normally expected behavior.

Another thing you can consider: Plex can be configured to have multiple folders in a Library. As you migrate from one server to another, it can pull media files from both servers to play.

High jacking binhex's thread a bit, but as an application's user base increases in size, it is understandable that user's expectations will also increase. Write a plugin used by a few hundred users on a niche application? Don't expect much. Write an application that has tens of thousands of users across a number of platforms? Expectations get much greater.

He can't. I've been following this for months, and many people have offered to help. The issue is with a proxy service written for Lidarr, which goes between the Lidarr program and makes API calls to search Musicbrainz. This code is not open source. It is held by a few (perhaps one person?) and is closed source. Unfortunately the issue effectively makes Lidarr useless. If you have an existing Lidarr installation, it still searches/downloads what you had already asked for, but you can't add/update artists. So useless for anyone wanting a new install or for adding anything new that someone may have a liking to.

The procedure from the Unraid docs assume a healthy array. I suggested a potentially safer alternative - Getting all of the array data backed up (utilizing a simple "copy everything" strategy) first. This limits the amount of work your aging array drives need do. Added benefit is if there are any issues, the old array drives still contain your data if needed. Recreating the array with just the new data drive eliminates Unraid needing to clear/zero/format the drive. Then adding the Parity drive just requires rebuilding parity, which you can then be confident is correct, as it was just done with two new, healthy drives.

I just did a quick search, and it looks as the prices for A400 have dropped to about the same as T400 here in the US. Something to keep an eye on moving forward.

I'm not 100% sure what I'm going to write is correct, so I'm going to tag a few experts to confirm I'm not just blowing smoke: @JorgeB @itimpi @ChatNoir This should be possible. Once you have all of the data copied from the existing array to one of the new drives, you would first recreate your array (using the New Config utility in the Tools tab). Add ONLY the new data drive at this time, and remove all of the current drives from your array (including your current Parity drive). You will not need to clear or format the new drive (and obviously should not, as it now has all of your data which you copied on it). At this point, you should be able to start your array and see the one new drive in it. All of your data should be accessible. Now shut down your system, remove the drives you no longer need, and add the second 12TB drive you will use for parity. When you start the server back up, you should now be able to add the drive as Parity from the Main tab (array need be stopped). When you restart the array, parity rebuild will start.

Do you have a backup of the data currently on your array? If not, I would suggest adding one of the 12TB drives as an Unassigned Device and back up everything. After you have everything safely backed up, you can then reconfigure your array as you would like.

Yep. Pretty disappointing.

That would require some dev to code and publish. Not a simple undertaking, so I wouldn't expect we would ever see it.

Did you start the CoreFreq Daemon? The plugin is in the Settings menu.

The Realtek drivers won't help, it has an Intel E5000.

I doubt a 24/7 test would be required to make a determination.

Then try it both ways, and see which is more energy efficient. If they are basically the same, then it doesn't matter which you use.

This one.

Correct. Without knowing your network, can't give exact instructions. But looking at the IP leases in your router you should easily find the newest one for the server (once you give it time to boot fully). Alternatively you should be able to access the server by entering tower.local (or more correctly, <your_server_name>.local if you have renamed your server) instead of the IP address.