betaman

Visa Checkout promo at BB expired already.

yeah, I was surprised to see there was a container update since I was on the latest stable release already?!

Ok, that was my next thing to try. However, I noticed the container id was a lot longer than what I was trying to use to kill the container so when I used the full id, it finally worked!

I've tried the stop, kill and remove container commands from command line to no avail. Stop and kill just hang and remove says it removed image. Force update fails as shown in attached jpeg from previous post.

So I had a notification for an update but the update failed and now I think the docker service thinks the emby docker is running but it doesn't seem to be since the stop and kill commands (even from command line) do nothing. Now the webui shows the docker is running but doesn't know which version (see attached). I probably need to reboot the server but I'm in the middle of a preclear and would like to get my emby server running again before the long weekend is over (and my preclear)!

I fixed my post above. Just reporting back on my findings related to delayed reboots and shutdowns.

What information would be useful? Mine seems to hang since I no longer have Powerdown. Still on 6.2.2 while I wait for a parity rebuild and check to finish. Are any logs/diagnostics preserved now on reboot? First I'd upgrade to 6.2.4. Then try a shutdown and see if it works okay => if it hangs, it's now supposed to generate a log file that will provide some feedback for LimeTech to review so Tom can continue to improve the shutdown process. LimeTech's goal has been to eliminate the need for the PowerDown plugin ... and dlandon is no longer supporting versions beyond 6.2 You may want to read this thread: https://lime-technology.com/forum/index.php?topic=51983.90 Just wanted to report back that shutting down my Windows 7 VM prior to executing a shutdown (or reboot) dramatically reduces the time it takes. I'll start doing this as best practice.

What information would be useful? Mine seems to hang since I no longer have Powerdown. Still on 6.2.2 while I wait for a parity rebuild and check to finish. Are any logs/diagnostics preserved now on reboot? First I'd upgrade to 6.2.4. Then try a shutdown and see if it works okay => if it hangs, it's now supposed to generate a log file that will provide some feedback for LimeTech to review so Tom can continue to improve the shutdown process. LimeTech's goal has been to eliminate the need for the PowerDown plugin ... and dlandon is no longer supporting versions beyond 6.2 You may want to read this thread: https://lime-technology.com/forum/index.php?topic=51983.90 Thanks for the link. I should qualify my original post by saying the Powerdown plugin was active on my server during these delayed shutdowns. I was aware about some issues with this plugin and 6.2 but I wasn't entirely sure if we should keep using it or not? Based on what I read in the link you provided, should I remove it now in 6.2.4 or should I wait for 6.3 final (no plan to use an rc or beta at this point)?

This was an issue with experimental branch, but the master branch should be ok. Can you make sure you're on the newest image? If you're on the newest image, can you post the rest of your configuration so I can replicate? You can leave out the username/password. FWIW, I had a similar issue but it could've just been the VPN_Protocol env variable was missing. I think binhex defaults to nl.privateinternetaccess.com with his vpn dockers so I just switched to it with nzbgetvpn as well.

I haven't noticed that. Are you sure you don't have any files open? I don't think so but it's a good question. Is it best practice to shutdown any running VM's manually prior to reboot? Unless I know it's doing something (like downloading), I usually let the shutdown script take care of it. Perhaps something was running in the background?

Same here. But is it just me or does it seem like reboots are taking longer since 6.2.2? Unmounting drives seems to take forever now. EDIT: Just wanted to add that I do have the Powerdown plugin active on my server during these delayed reboots.

Can't help with the issue, but I'm genuinely curious if switching to nzbget would fix the problem? I'm still using SAB, so if nzbget doesn't suffer from the same problem, it may be another reason to switch. Yeah, good question. Let me know if it works for you! Haha, seriously though, if I get some free time then I'll try installing nzbget and will report back. Ok, so I had some time and configured nzbgetvpn. It uses a function call Par_rename to handle obfuscated titles. As luck would have it, I haven't come across any yet but I can see in the log file where it checks for the rename.par file. So far so good. Only issue I need to figure out is cleanup of the tmp download directory. Edit: Cleanup issue was from SAB pulling same nzb file before I switched off docker and download client in Sonarr. Seems to be working very well thus far with less manual intervention required.

Well, I've never installed an instance of nzbget so the default template was missing the VPN_PROTOCOL env variable and the typo was part of the template. I just figured you never updated the default template for the docker? Maybe try deleting the docker and the template and doing a fresh pull?

Indeed! Bungy are you able to do this? Thanks, and so far I have been loving the NZBGETVPN Docker you've provided. I put a bit of time into it, but didn't get very far. I ran into a self-signed cert issue, and I ran out of time to work on it. I'm a bit swamped with work at the moment, so I can't quite do this right now, but maybe over the weekend. I want to switch to binhex's baseimage and use his awesome openvpn setup, but I'll have to postpone until things calm down a bit. Totally understand, and I'll look forward to when you can. Thank you sir! I was able to update the docker to use binhex's openvpn as the baseimage. You'll need to update your docker to include these environmental variables VPN_ENABLED=yes VPN_PORT=1198 (if using PIA) LAN_NETWORK=192.168.1.0/24 (or whatever your home lan network is) VPN_PROTOCOL=udp (if using PIA, may be tcp for other providers) Let me know if you have any issues. The build should be done in a couple of minutes. Thanks Bungy for this vpn version of nzbget. Just an FYI that this docker is still missing the VPN_PROTOCOL env variable. Also, VPN_ENABLED has a typo (VPN_ENABED).

Can't help with the issue, but I'm genuinely curious if switching to nzbget would fix the problem? I'm still using SAB, so if nzbget doesn't suffer from the same problem, it may be another reason to switch. Yeah, good question. Let me know if it works for you! Haha, seriously though, if I get some free time then I'll try installing nzbget and will report back.

Thank you, that did the trick, I'll have to remember that! Had a similar issue with server version 3.0.8300.0 and the update to 3.0.8400.0. Anyway, just a couple of points for anyone upgrading via command line. Docker must be running and the update takes significantly longer than you'd expect if comparing it to an update via the gui. Worked well though...just be patient. Thanks.

to modify the startup settings for sonarr , exec into the container docker exec -it <container-name> bash and modify the file /etc/service/sonarr/run Ok, I am completely new to messing around with mono and editing stuff in Docker containers so bear with me. This is what is in the run file: XDG_CONFIG_HOME="/config/xdg" exec /sbin/setuser abc mono /opt/NzbDrone/NzbDrone.exe -nobrowser -data=/config so would I just append the debug switch here? XDG_CONFIG_HOME="/config/xdg" exec /sbin/setuser abc mono --debug /opt/NzbDrone/NzbDrone.exe -nobrowser -data=/config Or just put it at the end of the line? XDG_CONFIG_HOME="/config/xdg" exec /sbin/setuser abc mono /opt/NzbDrone/NzbDrone.exe -nobrowser -data=/config --debug Is it possible to get a little more detail on adding the --debug to mono? I've never used docker exec so I'm looking for some detailed steps on how to enable and disable this option. Something broke when I updated the docker to v2.0.0.4374 of Sonarr. I did reach out for help in the Sonarr forum as well which is why I'm trying to figure out debug mode for mono. Thanks! EDIT: Still interested in how to add the --debug attribute to mono but I did resolve my issue. Somehow my media share got set to cache only and wouldn't allow Sonarr to move the files.

Yeah, just noticed that. Would it make sense to use different ports as defaults for each docker?

The Host Ports on my binhex VPN dockers match yours (the first two ports) but neither is using 8118. Is it mapped as an additional port? Maybe try deleting your config and pulling the latest docker. Just take a screenshot or something of the advanced view tab for each.

Looks like you have port 8118 defined in both dockers? Did you try changing one of them? I think you only need the first two for each anyway.

I know this is an SABnzbd issue but I was hoping someone here could help. There seems to be an issue with obfuscated filenames not being renamed because of how SABnzdbd handles par files. I've seen quite a few nzb's lately where a separate par file called rename.par plus an obfuscated file are left in the download directory. I'm using Sonarr for post processing and it will fail on these files because the obfuscated file name isn't the right format. From here there's two options, manually execute the rename.par file or manually rename the file so Sonarr picks it up and processes correctly. From what I gather, the folks running SABnzbd don't really want to change how it handles par files (i.e. It only uses par files to repair damaged files, not rename them), so other Linux build users have written custom scripts to manage a workaround. I'm wondering how to implement such a solution with my current setup of SABnzbd and Sonarr? Does anyone else have an "automated" solution to this problem? EDIT: Here's a link to a detailed description of the issue.

Is this plugin working in 6.2.2? I can't get past the MakeMKV drop down screen?! EDIT: Restarted the docker and it seems to be working now.

Settings - Scheduler no Something like this appears in the syslog Oct 27 00:02:00 Server_A root: /mnt/cache: 101.5 GiB (108977012736 bytes) trimmed Awesome, thanks for the tips!

Should be fine, if you don't have one consider buying a UPS to avoid power cuts, in my experience they are the cause of most file system corruption cases. Thanks. I actually have a UPS hooked up to my UnRAID server and it's functioning correctly. You should be trimming it, or write performance will degrade (it will also wear out faster), fstrim should work on most onboard SATA ports, it will work on any Intel onboard SATA port in AHCI mode. So I have the SSD Dynamix Plugin installed but I can't seem to configure anything?! Unlike other plugins, hovering over the icon isn't a hyperlink to anything. Looks like the only parameter to set would be the duration between trims but how would I know if a trim operation is ever being performed? Should I just add a line to my go script? Same question though, how would I know it completed?

Just bumping this to see if there's any recommendation on further action required? Server has been stable since using XFS_Repair. I'm just not sure if this is something I need to monitor or take further action with or chalk it up to a one-time upgrade issue? Also, any insight on whether I should be "trimming" this SSD cache drive is appreciated. The trim plugin available wasn't working at first because I had my SSD cache on a SAS/SATA card. I moved the drive to one of the SATA ports on my MB but that didn't seem to fix it. I wanted to avoid further investigation if it's not warranted in this case.