Jump to content

Teixeira

Members
  • Posts

    10
  • Joined

  • Last visited

Posts posted by Teixeira

  1. On 6/5/2019 at 6:22 PM, testdasi said:

    ALL containers becoming unresponsive is a different problem. As I mentioned, when the CPU is waiting for the drive to respond, it will report 100% usage, regardless of how powerful your CPU is. A slow-responding drive will cause what you are seeing. In terms of why a drive responds slowly, it may be due to high IO (e.g. repairing + extracting + copying strain a HDD a lot due to repeated seek) or even a failing drive (that was what happened when my old Hitachi 3TB was about to kick the dust).

    I found the problem to this issue. I have my 'system' share set to cache only, but some data was still on the array. I moved it all to the cache with the 'unbalance' plug in. Now the containers don't become unresponsive anymore when the array goes to shit. The reason i'm still here talking about something that has nothing to do with the mover is that my problem is exactly the same as the original post. 

     

    The first 5 mins of the import makes the whole array unresponsive, meaning that nothing can be read from it. After 5 mins I gain access to it again but it is 

    noticeably slower (kinda expected). After some time it goes back up to 100% CPU and nothing can be done, until it is done.

     

    You said this is probably because of slow drives. I've excluded that one drive that contains all the data, forcing unRAID to write to the next one. Plex still can't play the media that is on the "idle" drive. 

  2. I am having a similar issue. I don't think it's related to the mover since my 'media' share doesn't use a cache drive. I use a seperate HDD outside the array for SABnzbd and when Radarr/Sonarr tries to import a file, everything becomes unresponsive (yes, not only plex but all the containers). Same thing happens when i copy a file from my PC to the server. I am aware that writing data to a parity protected array requires CPU power, but not 100% of my 2700X.

     

    I thought this was a problem with Radarr / Sonarr (Mono), but then i pinned them both to only 1 core and gave them each 500MB of RAM and this still happened. 

  3. On 12/4/2018 at 12:01 AM, Hoopster said:

     

    If you have made all the appropriate entries in Plex docker Extra Parameters, the go file, etc. and you have no /dev/dri directory, my guess is that you have not specified the iGPU as your primary graphics adapter in the BIOS. 

     

    Even if you have no other GPU, you cannot just have the BIOS primary graphics adapter set to AUTO.  That does not work.  You must specify the iGPU (it is the 'Onboard' selection in my BIOS) as the Primary Graphics Adapter.

     

    On 12/4/2018 at 1:50 PM, Teixeira said:

    Thanks for the quick response.  I'm 99% sure i did that but i'll have to check again. Will report back.

    So i checked again and the iGPU was selected as primary graphics. Still no /dev/dri :(

     

    My diagnostics are attached. Do you think i can get this working on this chip? 

    steelmountain-diagnostics-20181205-2001.zip

  4. 13 hours ago, Hoopster said:

     

    If you have made all the appropriate entries in Plex docker Extra Parameters, the go file, etc. and you have no /dev/dri directory, my guess is that you have not specified the iGPU as your primary graphics adapter in the BIOS. 

     

    Even if you have no other GPU, you cannot just have the BIOS primary graphics adapter set to AUTO.  That does not work.  You must specify the iGPU (it is the 'Onboard' selection in my BIOS) as the Primary Graphics Adapter.

    Thanks for the quick response.  I'm 99% sure i did that but i'll have to check again. Will report back.

×
×
  • Create New...