Jump to content

Xaero

Members
  • Content Count

    257
  • Joined

  • Last visited

  • Days Won

    2

Xaero last won the day on July 19 2019

Xaero had the most liked content!

Community Reputation

72 Good

About Xaero

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. There's a secondary reason for not using devices with motors on a UPS. UPS have brownout protection; this brownout protection will trigger anytime the input line drops between nominal load voltage. (Usually somewhere around 105-112v, varies on component age and manufacturer's specifications) The UPS enters "Buck mode" and uses the battery charge to supplement input voltage. Normally this occurs infrequently due to outside circumstances. A motor on the other hand constantly hammers both ends of the AC line with current spikes. This will frequently force the UPS into buck mode and WILL be detrimental to the lifespan of the UPS batteries and the buck mode circuitry. Source: I replace around 50 UPS per year due to external interference killing them (APC, TrippLite, CyberPower) In every single case, a refrigerator, fan, heater, or vacuum is connected to the UPS day-to-day. Another 50-100 UPS have premature battery failure (less than 1yr old SLA) in the same circumstances. Nice stable loads are fine for UPS. Also that's just me, in my area alone there are 15 other technicians who have similar numbers at our company.
  2. Interesting; if traceroute works that would imply that dns resolution is working which means ssh <hostname> should work. On that note; does ssh 37.48.xx.xx work? If so; ssh -vvv box.seedbox.eu may provide useful information. EDIT: Also I feel like nslookup should be in the default package list? Am I wrong on this?
  3. What is the output of: nslookup box.hostname.eu and traceroute box.hostname.eu I have a feeling whatever local DNS unraid is using is unable to resolve that hostname.
  4. https://gitlab.freedesktop.org/bolt/bolt It's part of the `bolt` package. Not sure if there are any slackbuilds of it currently.
  5. Follow the instructions in the Unraid-Nvidia plugin thread's original post, and the instructions on the Linuxserver.io Plex docker's config page. It's pretty straightforward.
  6. Thanks; I knew it was possible just couldn't recall off-hand for it. Was not in front of a computer so searching is cumbersome haha.
  7. Start with a diagnostics.zip before the crash. If possible, capture one during/after the crash. You might be able to get it to capture to the flash drive automatically on crash. Also, make sure you aren't passing through the same USB you use for your unraid flash drive; for obvious reasons.
  8. Correct. nvdec and nvenc are now natively supported by Plex, rendering this script effectively useless.
  9. Ah, I see. I just got a Samsung Q60R and the HTPC box I was using for Plex on the old TV is... staying with the old TV, as it's not needed with the new one.
  10. I've finally solved my issue with the rutorrent process being deadlocked in IOWAIT. If this is your problem you will see all of the below symptoms: rutorrent will load, but you will get an error 500, 504, or 502 on getplugins.php and the queue will not load when the queue does load you will rarely get updates and "the request to rtorrent timed out" will be your most common response. torrents will get stuck in checking status torrents that are downloading/seeding will get abysmal performance. all of the above will be intermittent and will usually occur after adding new, large torrents, or several smaller torrents Checking "iotop" when the above is occuring will have the rtorrent process listed at the top, with 99.99% IOWAIT and very low read/write speed. I had previously attempted many things to fix this problem: changing nginx scgi buffer size. increasing rtorrent memory allocation changing php-fpm workers and memory allocations changing php-fpm and nginx timeout to allow rtorrent more time to respond to requests. The final nail in the coffin was switching IO Schedulers. I swapped from mq-deadline to BFQ and the problem has entirely gone away. Not entirely sure why internally this was the fix - but immediately upon switching to BFQ the problem is completely gone and I can actually watch checking progress on a 200gb torrent while data is moving on the other torrents in the queue.
  11. The encoder can only do so much transcoding at once. Chances are streaming that many sessions will be the limit, rather than the PCI-E x8 slot. And you'll probably hit other limits before you hit the session limit; For example, https://www.elpamsoft.com/?p=Plex-Hardware-Transcoding Shows that this card (P2000) should handle ~17 1080p to 720p streams simultaneously (real world use shows it can handle a bit more depending on other factors) Assuming a 10MBit input stream, and a 4MBit output stream (their numbers, not mine) That's 14MBit/s per stream, 17 streams at that rate comes out to 238MBit/s - PCI-Express is measured in megabytes not megabits, so we need to divide that by 8: 29.75MB/s. PCI-Ex8 should have a bandwidth ceiling of around 7880MB/s. So you aren't even getting close to scratching the surface of PCI-E lanes there. A dedicated transcoding card could probably live in a x1 slot and not be impacted for most consumer use cases without 4k being prevalent.
  12. The GPU will still work in a x8 slot. Total bandwidth between the GPU and the CPU will be limited to 8x bandwidth; You will probably run into the encoder bottlenecking before x8 will be the bottleneck.
  13. What TV did you get? A lot of the SmartTVs on the market have Plex available for them natively now.
  14. Note that the Quadro 4000 (Released 2010) and the Quadro P4000 (Released 2017) are two entirely different products several generations apart from one another.
  15. Well, for one - this script is now useless. Plex ships with nvdec and nvenc on Linux now. (At least for Plex Pass users, not sure if its hit mainline Plex but probably) That said, its just a power management thing. So, by working around the bug I can get the card to stay in an "idle" P8 state. Which means the card is only consuming 3-5W of power. With the bug present (it still is) the card latches to a P0 state - which is the highest power state, and will consume 25-40W. The above power figures are observed from my P2000 - other cards will consume more, or less depending on their power requirements.