ZERØ
-
Posts
13 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by ZERØ
-
-
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.
-
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
-
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
-
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?
-
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?
-
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 advanceEDIT: 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?
-
Slow Docker updates, extracting slow on new hardware
in General Support
Posted
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