Everything posted by matthawkp
-
HDD Auto spinup on Plex container activity
I'm not really sure how to tell, I stopped all the containers and my overall CPU from the main page shows as fluctuating between 1-2% and this doesn't change whilst the script is running. I wouldn't expect the script to use much at all though. The other idea I had considered was using tail to watch the 'Plex Media Server.log' file (which on my setup is on a separate SSD) use this in conjunction with grep to find entries of 'Signed-in Token' and at that point redirect the log to the storage array to wake it up. It felt a bit more messy even though it could probably be done in one line of code if you knew what you were doing (which I don't!). I understand now I should probably be using a plug-in to run the scripts so will probably wrap the above script in a while loop with a 2s wait rather than using the watch command. I have a bigger problem in that my drives don't actually spin down and I think it's because I'm using a yottamaster enclosure and that perhaps I need some custom firmware to make it happen. Just throwing in an edit here as I decided to give the other idea a go: tail -f Plex\ Media\ Server.log | awk '/Signed-in Token/' > /mnt/user/media/logs/wakemyarray.log This one line should watch the plex media server log for any user requesting a sign-in token and then redirect the log output to a file on the storage array which should hopefully wake it up.
-
HDD Auto spinup on Plex container activity
I was looking for a solution to this since moving from Windows Server to Unraid, I use to have a PS script that ran on a loop looking for connections on port 32400, it would change to ESTABLISHED as the user connects, the script would then simply write an entry to a log file on the hdd array causing it to spin up. Because the Plex DB lives on the SSD most of the time a user will still be browsing the interface whilst the script is spinning the disks up ahead of their selection. I'm pretty new to Unraid and haven't written anything in bash before but I think the below would result in a similar kind of thing... #!/bin/bash mystate=`lsof -i -P -n | grep 192.168.1.1:32400` current_time=$(date "+%Y.%m.%d-%H.%M.%S") echo [BEGIN LSOF OUTPUT] echo $mystate echo [END LSOF OUTPUT] if [[ $mystate == *"ESTABLISHED"* ]]; then echo "status=SOMEONE CONNECTED!" echo "write to logile on HDD array" echo $current_time > /mnt/user/media/logs/plextickle.log else echo "status=NO CONNECTIONS!" fi I've just tested this by using the web terminal on the host and running watch -n 2 ./scriptname.sh (-n 2 sets it to run every 2 seconds which seems aggressive enough). Obviously you need to adjust the IP and the path you want it to write to (you could add multiple paths if you want, or specific disks to spin up rather than all disks in a share)
-
Moving AppData Folder to Another Pool
I had this problem recently, as I wanted to move my appdata share to a different pool named nvme_cache, I noticed that the docker containers I had before switching the share location were still located on the array cache. (You can see this under the share tab by clicking on the folder next to the share name). I updated the appdata share to make sure its configured for the new pool location (nvme_cache). After stopping my docker containers I opened the terminal and just did the following. cp -r /mnt/cache/appdata /mnt/nvme_cache/ then rm -r /mnt/cache/appdata (to delete it all from the old location) When I checked back in the file browser for the share they all now show as existing on nvme_cache. When I started the docker containers up again they didn't care. I think everything is referenced via the share names so moving the files at the filesystem level doesn't matter. Hope this helps someone, as I didn't have any luck with restoring using the backup plugin as it remembers the original source location with the backup and I couldn't see an obvious way to change this.