• Posts

  • Joined

  • Last visited

Recent Profile Visitors

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

Boyturtle's Achievements


Apprentice (3/14)




Community Answers

  1. Thanks very much for the insight, this worked for me too. If only I'd found this thread and your post earlier, my partner would not be so upset with me for losing half a day trying to find a fix!
  2. Schoolboy error. I had my firewall rules in the wrong order on pfSense; the open port rule was below on the list and it ran after the block VLAN rule. Moving it above the block VLAN rule resolved the issue I was having.
  3. I can't get Direct Play to work across VLANs, on the server dashboard I have a little exclamation mark and the play is listed as indirect. The Plex server resides on the subnet and the the clients that I would like to access the service are on VLAN, both are on the same LAN. I have port 32400 open on my pfSense router and am able to transcode the films to the clients, but not Direct Play. If I put the same client on the same subnet as the the server, it Direct Plays. I have this problem if I'm playing 720, 1080 or 4k content. In Settings>Network>LAN Networks I have added, I have no subtitles set that I can see in Settings>Languages (I have enabled and disabled Automatically select audio and subtitle tracks, to no avail and have Subtitle mode set to Manually selected). For good measure, I have also added the 2 subnets to the List of IP addresses and networks that are allowed without auth area too, but this did not make any difference so have now removed it. Have I overlooked a setting somewhere?
  4. No errors in the syslogs from 4.40 am and beyond yesterday, after I made the changes described above 😃
  5. My only weekly scripts are the cleaning up of plex cached files and ClamAV scan, nothing apcupsd related. Installed Dynamix Schedules, runs at 4.30 on Sunday and exportrotate, logrotate, run daily at 4.40. My output from cat /etc/logrotate.d/apcupsd is the same as @SimonF /var/log/ { rotate 4 weekly notifempty missingok postrotate /etc/rc.d/rc.apcupsd restart 1>/dev/null || true endscript } As I'm not using unraid's apcupsd, am I safe to edit /etc/logrotate.d/apcupsd and comment out the line /etc/rc.d/rc.apcupsd restart 1>/dev/null || true? Should this stop the daemon restarting?
  6. Thanks for your reply and apologies for not replying sooner nor making my earlier post clearer. My preference is to run the UPS management on a device that sips power (hence the Pi) and my unraid server is much more power hungry. Doing it this way allows me to shut unraid down before other devices on my network. What I'd like to achieve here is to disable the apcupsd 3.14.14 (31 May 2016) slackware startup, but have no idea how to to stop this. Effectively, I'd like the deamon to revert to how it was before I made the initial changes when adding the UPS. As I stated in my earlier post, there is nothing in cron to indicate that there is anything in place to start at 4:40 every Sunday morning. Do I need to make changes in unraids /etc/apcupsd/apcupsd.conf file, /etc/rc.d/rc.apcupsd or an altogether different file?
  7. I was using the built in UPS settings in Unraid, but this was not sufficient for my needs as it didn't support other item on my network, so I installed NUT server on a Raspberry Pi, connected the UPS USB cable to it, added the NUT docker to Unraid and connected it all up to the Pi NUT server while switching the UPS Settings> Start APC UPS daemon to No. Everything seems to be working with the NUT server, all my devices see it and are set up accordingly, including Unraid. Unfortunately, every week on a Sunday at approx 04:40 I get a notification apcupsd 3.14.14 (31 May 2016) slackware startup succeeded Communications with UPS lost these errors continue to be logged until I manually switch off the daemon Settings>UPS Settings. When I go to the Settings>UPS Settings tab, the status is showing as running, despite the Start APC UPS daemon showing as no. The way to switch this off is to click the default button which resets it. FWIW, I have ran cat /etc/cron.d/root and nothing is listed as running around 4am on a weekly basis. Has anyone else experienced this or can anyone give me an idea on how to apply a correct fix other than setting a cron job a few minutes after the daemon starts to switch it off?
  8. Did you ever get to the bottom of this? I have exactly the same issue, even down to the time of 4.41 a.m every Sunday!
  9. Did you get this to work? If so, can you share please?
  10. I was running the unraid UPS daemon for some time, but due to adding more devices that needed UPS support, I decided to move to a NUT server running on a Raspberry Pi. Moving the Unraid server and adding all the other devices to the NUT server went smoothly and everything seemed to be working well, until after 1 week when I got an error that Unraid had lost connection with the UPS daemon. At first, I thought it was a one off, but then it started to happen every week and usually at the same time (04:41) and I'm now concerned that something more serious might be causing this. FWIW, the settings are --- Start APC UPS daemon: No UPS cable: USB Custom UPS cable: Blank UPS type: USB Device: Blank Battery level to initiate shutdown (%): 10 Runtime left to initiate shutdown (minutes): 10 Time on battery before shutdown (seconds): 0 Turn off UPS after shutdown: No Looking at the logs, I've got this entry just before the warning notification: apcupsd[29559]: apcupsd 3.14.14 (31 May 2016) slackware startup succeeded apcupsd[29559]: NIS server startup succeeded apcupsd[29559]: Communications with UPS lost. It seems that on other instances on the logs where "apcupsd[29559]: apcupsd 3.14.14 (31 May 2016) slackware startup succeeded" is logged but doesn't cause any problems, there is a further 2 entries "apcupsd[29559]: apcupsd exiting, signal 15" and "apcupsd[29559]: apcupsd shutdown succeeded". I have no idea why this command sometimes triggers and not others. The workaround is easy, I just click the default button and everything goes back to normal, until the following week, I would prefer that it didn't do this, but I've no idea where to start looking, can someone please give me an idea where to look?
  11. I've just had a 'Doh' moment. I'd got another share that I should've set to use this pool, but hadn't enabled it. I've fixed that now and it seems to be moving files across now.
  12. My original pool works just fine, but a few months ago I added another pool dedicated for my download share. When Mover is invoked manually or via the schedule, only the original pool data is moved across. I'm not running the Mover tuning tool. Cache is set to Yes in the share. There is plenty of space in the destination. I have enabled mover logging and looking at syslogs and invoked the process manually; it appears that data is only moving from the original pool and the second pool (Download_cache) isn't even coming up on the logs. I've attached my diagnostics