Leaderboard

It looks good interwebotech, so your problem is not the line i noticed had changed. After I sent the message I noticed I completely had missed pulling all the changes from the release-repository of the plugin. I found the bug causing the plugin not to start, which was surely also Fireballs problem. I didn't have that bug in the plugin I attached above to Fireball, so that's why it suddenly worked, with regards to being started on reboot. I have pushed a change request to the repository, so the new plugin should be released when bergware gets around to it. Best Alex

The 'tss' user and group does not exist. Must be something recently added to libvirt/qemu. We'll keep an eye on it. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904787

Personally, I would think that this would be your priority here 😁

Well, you have already written it with your advice to me and xman. Just take several of your posts in this thread, put it in book form with a few pictures of kittens, babies and dancing bears (to appeal to the non-technical crowd) and it will be an Internet sensation! 😀

Ok I see what's happening. Thanks for the report, I guess it got lost among all the other posts in that topic at that time. There's an easy way to fix, and a hard way. The easy way is to prevent any of the SMART buttons from being enabled if the device is spun down, thus requiring user to spin up device first. The hard way is to determine if the device is currently spinning or not. Believe it or not, this is not that easy to work out an algorithm that works across all device types and interface types (eg, SATA vs SAS). At present 'emhttp' keeps track of spinning status based on "last I/O time" along with knowing when a device is explicitly spun down via an emhttp api call. The bug you're seeing is that webGUI issues a SMART command out-of-band from emhttp, meaning emhttp doesn't know this command has been issued, and the command is not counted as an I/O command. So we'll have to think about what's the best way to solve this.

I fought the macvlan call traces for a very long time. In my case, they only happened with custom IP addresses on br0. I created a docker VLAN and assigned the dockers I wished to have their own IP address to br0.3 (the docker VLAN). Since then, I have had no macvlan call traces. I got them more frequently with pihole, but, the call traces are not generally related to a specific docker. Again, for me, they only occurred on br0, and for a couple of other users, br1. Since creating the docker VLAN, I have had no call traces for months on br0.3 A couple of times, I went several days without call traces, but, sometimes I would get several in a day and they would completely lock up the server and only a hard reboot would work.

Why do you want to format it?

Why?

PSA: If anyone happens ever happens to look at the Statistics section, it will wind up being out to lunch on some items. In an effort to ensure a consistent experience for users and to stop from having to issue an update to CA the next time one of the authors / maintainers makes a mistake in a new and novel way that has adverse effects on CA, most of the fixes / security checks / etc on the applications are being moved over to the application feed itself. These changes should only manifest itself by throwing the stats out to lunch. Once the process is complete, a new ver of CA will be released that will be Leaner Faster More secure Lower bandwidth usage Lower update frequency

If you don't really know where to start with unraid i recommend that you look at SpaceInvaders Youtube channel. That guy has a lot of guides how to configure stuff or tweak things in unraid.

Exactly. If you wanna isolate them you can find the setting under settings >> cpu pinning all the way on the bottom. As you can see, i isolated 8 cores and it's threads so only my Gaming VM are able to access them. Keep in mind core 0 will always be used by Unraid itself to manage stuff. You can't isolate this core and pin that one is also not a good idea because unraid always is doin some stuff in the backgroud which can hurt your performance.

If you pin 2 cores to a VM you only tell unRaid which cores are allowed to be used by the VM. As long as you don't isolate the cores on top of pinning them, Unraid, Docker, Plugins and other VMs can be using the same cores at the same time. If you isolate single cores they won't be used for anything until you specific pin them to a Docker Container or a VM. A real good explanation how it works and how to configure it you can find at Spaceinvader One's Youtube Videos.

No worries, I’ll run it again tomorrow am using the older script

you got that right hoopster

I'm not very knowledgeable on the subject, but I do know that you can run into issues with file system repair and other nasties if there isn't enough slack space for the file system to do its thing. Just recently there was an update in the XFS format, where disks formatted after a certain date reserved a much larger percentage of the total file system size, so if you had a disk filled to the brim with the old format, and tried to do a disk to disk copy to a newly formatted disk of the same size, you would be out of luck as there isn't as much free space available on the new format. I'd try to keep some portion free just to avoid headaches later. How much? Who knows. 512MB is probably safe, but I'd rather keep as much space free as my largest typical file. YMMV, IANAL, yada-yada, etc.

Just converted to Medusa w/ a backup/restore of configuration files. Once you've done the restore in Medusa, go into appdata\binhex-medusa\restore and rename the .db file to main.db and then restart the container. That was the only one off I had to do to get my DB restored. After that, I just checked all my settings and corrected anything that didn't convert over correctly. Shutdown and deleted Sickrage once I got that all fixed. Everything seems to be working well now.

I hope you mean uninstall

I am two states away from Texas, so, I cannot help you with physically building your server, but, perhaps I can help you decide what hardware you may need. If your primary use for Unraid will be as a Plex server then the biggest decision is how many simultaneous transcoded streams your server will need to handle. Depending on what clients you will have on your network and the video formats they support natively, you may or may not need much transcoding. If the clients can support H.264/.mp4, .mkv, .mpg, etc. natively transcoding is not really an issue. If you are streaming to an nVidia shield, it will do the necessary transcoding, thus alleviating your server of that burden. There are several ways for Plex to prepare your media so your clients can display the content: 1 - Have Plex optimize the content (basically pre-transcode so it plays natively on your clients) 2 - Transcode on the fly in software 3 - Transcode on the fly in hardware (requires an intel CPU with Quick Sync Video support) 4 - Stream to a client (Nvidia Shield, HTPC, NUC etc.) that will handle any necessary transcoding on the client side Options 2 and 3 require you to anticipate needs and choose the appropriate hardware for your use case. Option 2 - Transcode on the fly in software. This puts the most load on the server CPU while streaming. For this option, assuming you want to stream 1080p content (4K, HEVC/H.265 is a completely different discussion and requires even more thought regarding hardware choices), you need to look at the passmark score for the CPUs you are considering. You need 2000 passmarks for each simultaneous transcoding stream plus an additional 2000 or so for Unraid overhead and server functions. https://www.cpubenchmark.net/cpu_list.php The CPU in my main server (see my signature) is a Xeon E3-1245 V5. It has a passmark score of ~10,400. This means it can handle up to four simultaneous software transcodes plus the Unraid overhead. Option 3 - Transcode on the fly in hardware. This relieves the CPU of much of the transcoding burden and offloads it to the integrated GPU. For this, an Intel CPU with built in graphics and Quick Sync Video support is required. The CPUs in both of my servers meet this requirement and I have them configured to do hardware transcoding when needed. Many more simultaneous streams can be supported with hardware transcoding. I could probably do 8-10 on my main server. Fortunately, I don't need that. I stream from my server to local and remote clients (iOS phones and tablets, desktop and laptop PCs, TVs) The downside to hardware transcoding is that video quality is lower than with software transcoding at any resolution lower than 720p at ~4 Mbps. 720p 4 Mbps is the resolution I have set for streaming to remote clients over the Internet and my remote family members who have access to my Plex server report good video quality at this setting https://en.wikipedia.org/wiki/Intel_Quick_Sync_Video (scroll down and look at the hardware encoding and decoding table) When you decide what you really want to accomplish with Plex, we'll continue the discussion. 1 - How many clients will be simultaneously accessing the server? Local clients? Remote clients? What type (phones, tablets, laptops, TVs, HTPCs, NUCs, etc.)? 2 - Will you have Plex optimize content or do you need on-the-fly transcoding? Software transcoding? Hardware transcoding? 3 - Do you want to stream 4K content? If so, your hardware requirements just increased. 😀 Determine as far as possible the answers to those questions and that is a good starting point.

i would guess you have a mismatched completed downloads location, so deluge and sonarr (or radarr) are different, see below link Q9.

I think I have this sorted. It's simple, but not very spelled out for a newbie like myself. To target the plexpass tag, you just need to append ":plexpass" to the end of the repo name in your settings. I'm attaching an image to illustrate. Hope it helps!