• Content Count

  • Joined

  • Last visited

Community Reputation

10 Good

About SelfSD

  • Rank


  • Gender
  • Location

Recent Profile Visitors

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

  1. I never solved it. Turned everything I could off, back on, back off and so on. No change. With 6.9 since Beta 25 it became less frequent like you are seeing but still happened. Now I'm on a new build so I can't comment further on the issue unfortunately.
  2. Go to Setting > VM Manager > Vm shutdown time-out. Set the timeout to what you feel is reasonable, depending on how long you want to wait for a VM to power down. Same for Settings > Disk Settings > Shutdown time-out. This should be longer than the VM option so all the virtual machines can be shut down properly or killed before powering down. In my Xubuntu VM I had to create a file that makes the OS shut down when the power button is pressed. Otherwise it would just wake the 'screen' and never shut off, resulting in a forced shutdown. This worked for me and might wo
  3. Does 6.9.0 rotate logs now? Fix Common Problems just notified me that log was 100% full (Still struggling with this issue from time to time) but when I went to check it it shows 29% used.
  4. 6.9.0 stable makes it possible to write to the array at gigabit speed but reading from the array is still just as slow. Does anyone else use AllwaySync, GoodSync or Free File Sync between a Windows PC and their Unraid server?
  5. Hi guys! I'm currently on 6.9.0-RC2 and I've been trying out a couple of different backup tools in hopes of getting faster backup speeds, but all of them (AllwaySync, GoodSync, Free File Sync) were limited to about 30 MB/s copying to and from the array. Now the funny part is that I can run 3 backup sets in parallel to utilize my network fully, but that doesn't help much for single files that are rather large. Copying files to and from my array using Windows explorer does so at full gigabit speeds. Win10 Pro 20H2. What could cause this? No single core on
  6. My server got a call trace 2 days ago but has run fine until today. I was unable to stop my docker containers in an attempt to change network settings. This usually happened after getting a call trace on 6.8.3 and ended in a forced reboot. The call trace and docker issue might be completely unrelated but my server did not shut down properly either when I tried to reboot it. After attempting and failing a graceful shutdown (I was watching the connected display) it did a force shutdown and created the diagnostics attached below. After 10 or so minutes of waiting for it to power off I
  7. No problem! I have been running 6.9.0 beta 30 for just over a week now without any problems. I had some issues on 6.8.3 and 6.9.0 beta 29 which seems to have all been solved in beta 30 as it has been rock solid with an uptime of almost 9 days now, which is a new record for my old AMD system in a long while now lol.
  8. That's exactly your problem problem. Driver version 440.59 is not supported after PMS 1.20.2. You need at least driver version 450.51 on linux. If you don't want to update to a beta release (thanks @MowMdown 😄 Didn't notice that he had a non-beta prebuilt!) head on over to the link below and get the "Unraid Custom nVidia builtin v6.8.3" version and copy the 8 files from the ZIP onto your flash drive. Don't forget to make a flash backup before doing so! You might have a new GPU UUID after upgrading but you can still get that from the LSIO Nvidia plugin page,
  9. So I have absolutely no idea where to start reporting this problem or what to give out as I can't see anything in the Plex debug logs, docker logs or Unraid logs. I thought it might be a disk I/O issue but it's not. Maybe someone else can test this and confirm if it's a isolated issue for me or something that's more widespread. When running the LSIO Plex container on a separate VLAN, it struggles to send out the next buffer segment to any devices on the LAN, causing the video to stop and wait until it catches up. Sometimes it manages to send out the next segment before the playback
  10. Everything is still running smoothly! I feel confident that beta 30 fixed what ever happened to my server in beta 29.
  11. Heads up to anyone running 6.8.3. Plex Media Server was just updated to 1.20.2 on the public side, so your GPU accelerated hardware encoding will stop working if you update.'s beta 29 and @ich777's custom beta 30 build has a newer driver that is compatible with this latest release of Plex Media Server.
  12. Upgraded to beta 30 and the problem has not appeared again yet, even after hammering the shares hard. If the SMBD process stays good for another day or two I will close the issue.
  13. I've upgraded from 6.8.3 to try to squash some other bugs my system had and so far beta 29 seems to have solved the problems I had, but with it another problem has come up. Whenever I'm trying to access a share or copy data to and from a share, /usr/sbin/smbd -D is using 100% of a single core, slowing down file transfers to a crawl, around 20 megabytes per second. If I attempt to open another explorer window and browse to a share, any ongoing file transfers completely stop and it takes over a minute to open the share. This issue seems to affect a single computer at
  14. It got stuck on "turning off swap" even though I did not have a swapfile enabled. It generated a diagnostics file which I have attached. I'm gonna give 6.9.0 beta 29 a try. Hopefully it will solve these weird issues.