Rick Gillyon

Members
  • Content Count

    150
  • Joined

  • Last visited

Everything posted by Rick Gillyon

  1. or 3. Try 6.7.3-rc3 where limetech thinks it's fixed.
  2. It's an intermittent problem, chances are if plexpass failed, plex will eventually fail too.
  3. Limetech posted this yesterday, which implies that they're not sure whether it is fixed by cache drive, and that it's not fixed in 6.8: Here:
  4. Do you have appdata on cache? That seems to avoid the problem.
  5. All my appdata is on cache pool, no corruption on 6.7.2 since release.
  6. Check Q5 in the following Github link:  https://github.com/binhex/documentation/blob/master/docker/faq/unraid.md
  7. You need to map them in Plex settings in manage channels. So you need an epg source too. You can specify the epg XML file in the telly config, and tell Plex to use the telly epg at http://<telly IP>/epg.xml
  8. Map /etc/telly to appdata/telly/ and put your m3u there. Reference the m3u in telly.congig.toml as M3U = "/etc/telly/xxxxx.m3u" If I was starting now I'd use the xTeve docker though.
  9. I have a new(ish) Seagate 8TB IronWolf HDD in my server, precleared fine, but I'm seeing some SMART numbers that I don't get on my other drives, i.e. Raw read error rate 31460368 Seek error rate 49357490 G-sense error rate 2744 Hardware ECC recovered 31460368 The SMART extended test passes, and the hits I get searching for these counters are mixed: some sources (i.e. Wikipedia) say don't worry, the counter isn't a counter but some weird raw value; other sources (especially for read error rate) say that the drive is failing. I'm still in RMA period for this drive, so I'm really just look
  10. Mylar stopped working properly for me sometime in April. Prior to that it worked like a champ, since then I've had maybe 5 downloads total. Logs attached, any ideas? Sab seems fine, Mylar has just stopped finding stuff, but can be found manually from my indexers no problem. Sonarr etc. still working fine with Sab. Thanks. UPDATE: For others getting this same issue, I've found a solution. Edit Mylar's config.ini and remove the provider_order line completely. Sometimes this gets screwed up. So far I'm back to working again. Funny that @CHBMB replied to this just as I was
  11. I think this is an unrelated Plex issue. I sorted this by rolling Plex back to 1.14.1.5488-1-01
  12. Thanks for that. I always assumed Prefer and Only would move.
  13. It does not happen with a cache drive, mover will just do the initial move then it's there for good.
  14. Just set your appdata share to use cache, then mover will move it.
  15. Hit the Container Size button on the Docker page to see which Docker is the problem.
  16. Still root. Look at chown and chgrp. Even better:
  17. Plex is causing this. Roll back to a stable version.
  18. You need to wait for Binhex to release an update. Unless you have a version label specified in your docker, e.g. binhex/arch-plexpass:1.14.1.5488-1-01 - then you need to change the tag to latest to get updates.
  19. Monitoring memory, this seems to be a problem with recent versions of Plex eating up all available memory and grinding the system to a halt. Regressing Plex to an earlier more stable version seems to have fixed the problem (so far). Thanks for the help.
  20. Thanks, I already did that, it's fixed my problem so far. 👏
  21. Running the latest version on 6.7.0-rc5, Plex is constantly using over 40% of memory. That's over 6.5GB. Even when it's doing no recordings, plays or transcoding. Does this seem right or is there a problem? Edit: I've had my server maxing out CPU and memory and needing reboot every few days for the last few weeks, could this be caused by the new Plex version with the transcode problems?
  22. Okay, have sorted docker into cache. Would that cause recordings by a docker to write slowly to cache? If not, any hints why cache NVME drive (nvme0n1 nvme1n1) might be choking? Any related errors in the diagnostics? Thanks.
  23. Thanks. I'm pretty sure I know which container (OpenDCT), just no idea why. It looks like the cache NVME drive (nvme0n1 nvme1n1) isn't keeping up with recordings - the docker shows the buffer filling up and not writing fast enough. The diagnostics don't show cache/nvme errors do they? I'm not sure what the mover line is telling me. I have mover set up to move recordings from cache to array, why would that affect docker.img?
  24. Every few days my system pegs CPU at 100% with the process "app" and becomes unresponsive. Background processes still run, but using the front end is difficult and at least one of my dockers (OpenDCT) shows as stopped. This only started a few weeks ago, while using 6.6.6, but the update to 6.7.0-rc5 didn't help. I have to reboot the server to recover. Can anyone spot anything causing the issue in the attached diagnostics? Thanks. unraidpvr-diagnostics-20190301-2230.zip