Jump to content

snowboardjoe

Members
 View Profile  See their activity

  • Posts

    261

  • Joined

  • Last visited

 Content Type 

Everything posted by snowboardjoe

  1. snowboardjoe
    Confirmed the problem with disk location plugin and having a disk spun down blocks the dashboard tab. Just happened again this morning. As soon as I removed the plugin, the dashboard returned.
  2. snowboardjoe
    Disk location is installed. I just ran an update on that plugin and updated all Docker containers. The Dashboard came back. Not entirely sure which issue resolved the problem, but the Docker container update likely spun up all disks noting your issue that you found. I will keep an eye on this.
  3. snowboardjoe
    Just ran update assistant and it reports there are no issues.
  4. snowboardjoe
    Normally I use macOS/Chrome to access unraid. Tried to use Safari to access the dashboard and still get a blank screen, so this is not a browser/cache issue.
  5. snowboardjoe
    I upgraded to 6.12.2 last week and just noticed today I can no longer get the Dashboard tab to load. All other tabs load properly. The Dashboard is simply a blank screen when selected. No errors reported in log. The Main tab shows all resources and the array are healthy.
  6. snowboardjoe
    I'll do that and see what happens. However, none of the containers are items I have installed right now. Maybe they still cause issues?
  7. snowboardjoe
    There are just a few there...
  8. snowboardjoe
    I just upgraded to 6.12.2 this morning, selected Docker, clicked CHECK FOR UPDATES and then UPDATE ALL. The first pass updated about a dozen containers as expected. Then it looped through all of the containers again five times doing nothing but stopping, restarting and removing the previous container. I thought I was in an infinite loop, but glad it stopped after pass five. This has been happening for the past few versions. If this has continued looping, what would be the safe action to stop this process? This is becoming an unreliable process and I'm hesitant to do future updates based on this behavior. I suppose a workaround for now is just update on package at a time, but that's painful as well.
  9. snowboardjoe
    The problem is worse under 6.12.2. I'm in an infinite loop now. Going to create a new thread.
  10. snowboardjoe
    This was resolved by rebooting the UNRAID host. Unknown on root cause of this. HB now completes the post processing steps after successfully auto encoding a file. The workaround (until I rebooted) was to manually clear the watch folder, stage a few file and then restart HB to have it start encoding again. Guessing this is an UNRAID OS (v6.11.5) or Docker bug.
  11. snowboardjoe
    Using v1.6.1 and while auto processing of watch queues is working to encode files, it's no longer removing them from the watch directory on successful completion. Anyone else seeing this? It's worked great for years, but this is gumming up my process now and have to delete files manually (my script won't populate a new one until it's empty). AUTOMATED_CONVERSION_KEEP_SOURCE is still set to 0. I've also noticed as new items are added manually to the watch folder they are not getting processed. I have to restart the container to get it to start converting. Nothing in the logs showing any issues. Auto conversion process is pretty much dead at this point.
  12. snowboardjoe
    Just happened to me as well on 6.11.5. Most of my containers needed an update. Clicked Update All and followed its progress. When it got to the last one and started back at the top again trying to update all containers. There were no new updates, so I just found nothing new to download and restarted each and every container. Stopped on its own after pass 2.
  13. snowboardjoe
    Any logs from the Docker container or from the application logs themselves? Does it crash immediately or after some time? I would at least try to debug the situation a little bit to find root cause before trying to uninstall and restore.
  14. snowboardjoe
    Attached is a screenshot of my current configuration. I get notices for other things just fine--just not the UPS alerts.
  15. snowboardjoe
    Another update from SWAG and my configuration is broken again. Same error as before: nginx: [emerg] "stream" directive is not allowed here in /etc/nginx/conf.d/stream.conf:3 nginx: [emerg] "stream" directive is not allowed here in /etc/nginx/conf.d/stream.conf:3 nginx: [emerg] "stream" directive is not allowed here in /etc/nginx/conf.d/stream.conf:3 I renamed /etc/nginx/conf.d/stream.conf to a non .conf name, restarted and it's back now. Why is this offending file constantly injected and start producing errors every time I update?
  16. snowboardjoe
    All networking equipment on one UPS. unRAID server and all attached components on a separate UPS. No service or network interruptions for any service during a power failure.
  17. snowboardjoe
    I thought this used to work in the past, but I don't recall the last time I received a notification for a UPS event. This includes when the UPS goes on battery and back on AC. I recall getting email messages in the past, but it's been a long time since I've seen then. I assumed it would go to the agent where I have Pushover configured (and I do get other unRAID notifications for other events there like update notifications and sync operations). I did have several events today and all of those UPS events were detected and logged by unRAID (no notifications). Am I just missing something here in my config?
  18. snowboardjoe
    Ran another update all on my containers and it performed like usual this time. Only two containers needed updating. Did it one pass and it was done. Seems to be more of a post-upgrade issue I guess.
  19. snowboardjoe
    Just upgraded from 6.11.1 to 6.11.2 this morning. After reboot decided to update all containers. Hmmm, looks like it just resolved itself. That was weird. There were several containers that updated up 4X and freaked me out. Everything appears stable for now. Will leave this post out here in case others run into the issue and maybe verify the odd behavior if it proves to be a bigger problem.
  20. snowboardjoe
    Does it truly get to 100%? My schedule was interfering with the progress of the maintenance and had to let it run 24x7 to complete.
  21. snowboardjoe
    These maintenance processes are scheduled and they need to complete. If they don't it will keep trying over and over again. This will block routine backups as well. In general, CP is intended to run 24x7. How big is your server? Does it draw that much power? Daily shutdowns can cause more stress on hardware than leaving it on. I would measure your current draw and do the math. It may not be worth shutting it down every night. unRAID was designed to be low power (spinning down disks in particular). The work by CP should have a minuscule impact on resources.
  22. snowboardjoe
    It should be in your appdata share. In a typical install, it should be: /mnt/user/appdata/HandBrake/successful_conversions
  23. snowboardjoe
    Are you looking at the files from another computer or directly from unRAID itself (via web console or ssh session)? It's possible some other permissions are not set right and hiding them due to a permissions issue.
  24. snowboardjoe
    The typical permissions should be 755 and owned by nobody:users at the bare minimum (I think 777 is preferred). Of the movies that are missing, are you able to browse through your directories and actually find them?
  25. snowboardjoe
    I think I just figured out what was going on based on documentation. I'm using the High-water method. Disk 1 is only utilized 21%. Disks 3, 4, 5 are all utilized over 80%. So, as I understand it, unRAID will keep filling disk 1 to the 50% mark before it starts to fill any other disk. I assume it will just create those share directories on disk 2 when it eventually gets to that point.
×
×
  • Create New...