[Slow Docker updates, extracting slow on new hardware]

I've got a thread with this same issue over on reddit and that's led to me discovering I have a high iowait time when the extraction is happening, around 30-50 wa when watching top in the console. I have an SSD as cache, and I've benchmarked it to around 250-300 MB/S write in my old hardware, and watching the write speeds in the Main tab UI I can see it's capable of 150-180 MB/s when copying a file over the network to the server, but the UI display seems choppy; it would show values less than 1 MB/s for a few seconds, then spike to 80-150 MB/s, then drop down again. Is that expected behavior? The same thing happens when I'm extracting, very low write values, then a spike of a fast value, then low again.

docker.cfg cache.cfg SanDisk_SSD_PLUS_240GB_210802A00E89-20230117-1305 cache (sdb).txt

[Slow Docker updates, extracting slow on new hardware]

9 hours ago, JorgeB said:

You can do a quick CPU test and compare with the old board/CPU if still available to rule that out:

 

simple CPU speed test:

time $(i=0; while (( i < 9999999 )); do (( i ++ )); done)

(this will return the the time required to crunch the integers between 0 to 9999999)

Unfortunately my old motherboard died. I was originally only going to upgrade the processor, but the new Xeon overstressed thee old motherboard and blew a couple CPU power mosfets, apparently a common failure point for that board. I don't believe I can use the i5 in the new board to compare, as it doesn't support registered ECC RAM.

 

The result of that test was 32.6 seconds, which probably doesn't mean anything without comparing to the old processor value. The CPU load on the dashboard showed around 35% usage during the test.

[Slow Docker updates, extracting slow on new hardware]

27 minutes ago, Squid said:

And where is the docker image located?  On the array or on the cache drive / pool?

Located on the Cache drive. In the docker settings:

/mnt/user/system/docker/docker.img

Which I can find by navigating from the Main tab and browsing the cache disk. Appdata is also set to cache only

[Slow Docker updates, extracting slow on new hardware]

I recently upgraded my motherboard, ram, and CPU in my unraid server. Now it seems like docker updates take a long time to extract.

 

Previous Hardware:

• Gigabyte H55M-S2V Motherboard
• Intel Core i5-660
• 8GB G Skill DDR3 1333

 

New Hardware:

• Supermicro X8SIE-LN4
• Intel Xeon X3470
• 16GB Samsung DDR3 1333 ECC Registered

 

It's the same processor generation and socket (LGA1156). The Xeon is about the same clock rate, but double the cores. I have boost enabled. Any ideas why extracting would take longer? Maybe a bios setting I set incorrectly for the CPU? The processor usage when extracting will use 10-20% of the CPU, jump to 60-80% for a moment, then drop down again. 2-3 of the 8 cores will be around 100% when that happens. For an example, I just updated my home assistant core docker, and the 250 mb piece took 2-3 minutes to extract.

 

On current unraid 6.11.5

[Plex Audio Transcoding Causing Volume Jumps and Glitches]

I've started having issues with transcoded audio on Plex. First noticed it when transcoding from TrueHD files to EAC3 5.1. It also happens transcoding from 7.1 AAC to EAC 5.1. The audio will jump ~6-8db, but it seems like it only happens on one or two channels, so the L/R channels, but not the center. It's most noticeable in action scenes, or scenes where the score has a consistent orchestral part, you can hear the constant string section dropping out or jumping back in several times in a few seconds. The audio is not stuttering or missing parts, its just the volume is not consistent. I've also noticed the overall volume is lower than it should be; on files where I can direct play a 5.1 track from inside the container, the volume is much louder overall than the transcoded audio.

 

I am running the official Plex docker on Unraid 6.9.2, the client is Plex on Roku on my TLC TV, HDMI ARC to a Yamaha TSR-700 with 5.1 speakers, set to straight.

I've tried toggling Normalize Multi-Channel audio, changing the transcode from high speed to high quality, and deleting the codecs folder in appdata. On the client, I've tried toggling the AAC Stutter Workaround and trying various direct-play and direct-stream options.

Any suggestions?

[[Support] Linuxserver.io - Jackett]

On 5/4/2021 at 5:31 AM, nekromantik said:

yeah got exactly like above but get 

 

Exception (ettv): The cookies provided by FlareSolverr are not valid: The cookies provided by FlareSolverr are not valid

 

on all indexers

 

EDIT: 

Ah I fixed it by routing flaresolvrr through VPN which is same as jackett

Could you please share how you routed through VPN? In Jackett I use the proxy setting, but with flaresolverr, there is no GUI. I've set up the container to route 8191 from app to 8191 host; I can't put the vpn port there, can I?

[[Support] binhex - DelugeVPN]

Sorry if this has been addressed, I didn't see anything in a search.

 

When I restart the DelugeVPN docker, it loses any torrents I had queued that did not have any download progress (0% progress). My torrents are added via Radarr/Sonarr, and they queue to the bottom, and don't actually download any torrent information until they get to the top and start.

 

I suppose I could solve this by queuing to the top, but I would rather have first in/first out. Is there another solution? Should I maybe have deluge save a copy of the torrent files to a folder? Or is this a Sonarr/Radarr issue?

Thanks in advance

 

EDIT: I actually see two torrents with 0% progress still in the deluge queue, but they have the file information available, so they have apparently downloaded the torrent information. Is there a way to have the torrent grab the information when it is added via Sonarr/Radarr?

[Share Your Banners]

On 5/17/2021 at 4:17 PM, tmeuze said:

First post, wanted to share. Made with the My Server plugin in mind.

I liked the look of these so I borrowed the idea, made it a bit darker and added the texture from the back of the new Apple Pro XDR display. I decided I had spent enough time on it today, but I'll probably keep tweaking it to make it a bit more polished.