neoeny152

I'm sure this is related to the beta. Occasionally when I go into a plugins settings page since upgrading to RC3 (rc4 when I get a chance), it hangs on this page and crashes the entire webgui. Just sits there spinning, and at this point all I can do to get out of it is reboot the whole server. Not sure if this is an issue with your plugins or specifically with the beta itself. Should I post somewhere that a dev knows this is going on? Haven't tried it with RC4 yet, will do that tomorrow. Wanted to post here just to mention it and see if anyone else is experiencing it. Oh snap, I 'fixed' it. I went into htop and killed what I'm going to call a 'sub script' for emhttp. Looks like there was two that indicated it was checking on the sonarr version, I sent a kill command to each of those and it freed everything up and the webgui is working again. - I'll leave this here in case this is worth mentioning.

What is strange though is that I can copy at expected speeds if I bypass the user share. Have you tried a copy from user share to user share to see if it happens to you? It seems like to me that it will act the same on all unraid instances but I'd like to confirm that. My drive's SMART tests come back fine and parity check comes back fine with 0 errors. Is there further checking I can do on my disks?

It's really frustrating that it takes 2.5 hours to copy 150 gb internally. Am I really the only one this happens to? Could someone please try to reproduce this and at least let me know I'm not alone. Reproduce by copying a large file from a user share to another place on the same user share. Take note of transfer speed and compare with expected transfer speed (drive to drive). I get 100 to 200 MB/s drive to drive and only 10 to 20 MB/s share to share. All internal.

Is anyone else able to reproduce this type of slowness? Try copying a file that is 3gb or more from one place on a user share to another place on the same user share with mc. I only get 12 to 20 mb/s when I do a copy this way. Disk to disk is 100 to 200 mb/s. -NeoenY152

Ok, SSD cache is out of the picture and a large copy is moving at about 12 MB/s. This is when I copy from one place on a user share to another place on the same user share. From one drive to another it flys.

Yeah I was simply doing that for test purposes, generally I always copy to the user share and never directly to disks. Yes, raid 1 Only using 6gb right now. - I'll run the move right now and pull the cache from the user share in question and see how a copy goes then, that way I can rule out or pin it to the cache. I didn't allow the copy to finish during the test, maybe that's why it didnt show in the log.

Cache is two 128gb ssd drives, same model, BTRFS. Everything else is XFS. New diag attached. tower-diagnostics-20160331-1925.zip

Well, that was interesting. I tried a copy of a large file from the user share to each disk directly and each one copied at 100 to 180 MB/s, including to the cache drive. When I switched to the user share to user share it cut down to 25 MB/s. Thoughts?

I'll check, but even without cache I would think it would copy faster than 20 MB/s. Thats not even usb 2.0 speed I'll check to see where the files are landing and report back.

I'm copying from one folder in a user share to another folder in the same user share (which has a cache set up on it) I never copy anything to a specific drive. A move is instant but sometimes I need to copy instead of move.

When I initiate a copy on midnight commander, from one internal location to another internal location, I peak out at about 20 MB/s. It seems like it should move along quicker than that when it's from one internal drive to another, especially with an SSD cache set up on the share in question. Not sure what info will be needed, let me know if any additional logs need to be added to help troubleshoot. Model: Custom M/B: ASRock - C2750D4I CPU: Intel® Atom™ CPU C2750 @ 2.41GHz HVM: Enabled IOMMU: Disabled Cache: 448 kB, 4096 kB Memory: 16384 MB (max. installable capacity 64 GB) Network: eth0: 1000Mb/s - Full Duplex eth1: not connected Kernel: Linux 4.1.18-unRAID x86_64 OpenSSL: 1.0.1s tower-diagnostics-20160331-1525.zip

Strange, I had it set to /tmp/plextranscode before, but along the same lines as your advice here I added /tmp/plexctranscode/1 and now it's working! Thank you

Sweet, I can also verify that it now validates my credentials properly. On the ram, I have 16gb and I'm only using 28% as of right now.

Awesome good to hear. Any thoughts on the /tmp transcoding? Seems like it may be perms to the /tmp folder. Are there any logs that I can sift through to figure out where/why it's failing? When I have it set to using a normal hard disk it transcodes.

Glad to see I'm not alone on the plexpass authentication issue. - I'm also having an issue with transcoding on /tmp. It seemed to work at one time but now I cannot get it to work for the life of me. It's not that big of a deal but I like the idea of transcoding to ramdisk, is anyone else able to do this successfully? for google (Unable to login to PlexPass with above credentials)