deusxanime

In your custom cron entry, you have a "*" character in the first slot which makes it so it is set to try to run at every minute during the 3:00 AM hour. * * * * * * | | | | | | | | | | | +-- Year (range: 1900-3000) | | | | +---- Day of the Week (range: 1-7, 1 standing for Monday) | | | +------ Month of the Year (range: 1-12) | | +-------- Day of the Month (range: 1-31) | +---------- Hour (range: 0-23) +------------ Minute (range: 0-59) So it kicks off at 3:00 AM and runs and then if it completes before 4:00 AM (so any 3:XX time) it tries to run again. If you want it to only run at 3:00 AM you need this for your custom cron entry: 0 3 */3 * *

Thanks, I'm going to give that a try to start with. I'll have to resolve to do more backups of my containers and VMs, but otherwise hopefully the performance improvement will be worth it.

So, I'm at a point where I can make some changes to my server drive layout and trying to decide what the best move forward plan is for now. I currently still have 2x Samsung 850 EVO 1TB drives in BTRFS RAID1 for my cache pool. Pretty much the worst case scenario it seems after reading back through this thread again. (And let me tell you that my ~$600 investment is really chapping my hide that unRAID people seems to not care about these issues at all, rendering it crippled.) Should I just split up the pool and reformat one of the drives in XFS to use as my new cache drive/pool, and then I can just do whatever with the other in Unassigned Devices? If I do that, what is the issue with alignment on Samsung SSDs and will that still cause problems? Or is that only an issue with BTRFS and not a problem with XFS? In which case the only solution to get the max performance out of them would be to use a tool to fix the alignment, rendering them both only usable in UD since unRAID won't work with them that way? Or should I just say screw it and buy a new SSD to use as cache to avoid the above issues? Thought I still can't use BTRFS RAID1 since that is not a manufacturer specific issue right? Ugh, where is the "just works" I wanted when moving to (and paying for) this product...

There's been a few releases since the last post, but I don't think anything has been fixed yet correct? Any idea if/when that will happen? Debating whether to keep chugging away with my BTRFS RAID1 cache pool or just split it and format as XFS.

Yeah I've been meaning to switch over to Medusa or Sonarr eventually. This might be the final nail in the coffin for SickRage.

So I figured out the URL for direct XMLRPC is http://<server_IP>:9080/RPC2 and you use Digest authentication with your username and password. Using that in SickRage I was able to get it to give me the "Success: Connected and Authenticated" when pushing the Test Connection button in settings. But I still end up with the same errors when it tries to send the magnet link over to rTorrent. Just wondering if anyone else is seeing that with the new version of this container or what others are using as their settings in SickRage (or SickBeard or Medusa I think are the same) to get stuff over to rTorrent?

Anyone else using SickRage to send to this rTorrent container? Mine was working ok previously (occasional failures to send, but would work the next time, or would add in stopped state), but since the last update things are failing to send over completely now. SR tries to send magnet links via scgi to rTorrent and I just get this error every time now it tries to send over: 2018-06-15 09:03:07 SEARCHQUEUE-DAILY-SEARCH :: Error while sending torrent: 2018-06-15 09:03:07 SEARCHQUEUE-DAILY-SEARCH :: rTorrent: Unable to send Torrent I double-checked my rTorrent connection settings in SickRage and everything is still the same as before (basically just put in the scgi address and leave other stuff blank/default) and pushing the Test button gives me a Success message saying it is working. But everything SR tries to send over just fails now with above error message. Not sure if something has changed in the way rTorrent handles/accepts magnet links or what, or yet another parameter change that needs to be updated from the old version, but it has been a couple days trying to figure it out and no luck. I tried switching to Black Hole method in SR instead, but it is horrible at grabbing actual torrent files to send to a watch directory, so that doesn't work either. edit: Is there a way to use XML/RPC method with rTorrent in this docker, rather than direct scgi? Wonder if that would work better?

Yeah I couldn't believe it even started for me as it was. I pretty much had to fix and/or redo every line of my file.

I noticed that my watch/import directories weren't working, even after I got rtorrent going again from my previous startup issues. Upon investigation, it seems that there are tons of updated commands and parameters (see the page I linked above) and I ended up having to basically rewrite/recreate my rc file from scratch! FYI in case anyone else is seeing things not working as expected since the latest update, you may have outdated parameters that don't work or aren't recognized correctly anymore. Here's the new "base" rc file example from github if you need to start from scratch like I did.

Thanks for the info. It appears that system.method.* was deprecated and I should now just be using method.* for those parameters. Had a few in there that I changed and got it to start up. They must have fully removed them now in this release. Found the info here for anyone wondering (under the Method section). Also, I tried what you said and clicked the container and opened the console (when it still wasn't working), but when I put in and try to run "/usr/bin/rtorrent" I get a "no such file or directory" error. Was able to get it working luckily without needing that, but for future reference something that I might have done wrong? edit: Must have been some weird character coming over from copy-pasting from webpage, because if I type the "/usr/bin/rtorrent" in manually it works just as you said (and tab-completes yay!). Thanks again!

Here's my rc file. Hopefully it's something simple like that.

Updated rTorrent+VPN just now (not sure when the update came out, but only got a chance to do the update today) and now it won't start. Was running fine before. I see this in the log just repeating over and over now: 2018-06-12 21:04:06,902 DEBG 'rtorrent-script' stdout output: [warn] Wait for rTorrent process to start aborted 2018-06-12 21:04:37,030 DEBG 'rtorrent-script' stdout output: [info] rTorrent not running 2018-06-12 21:04:37,031 DEBG 'rtorrent-script' stdout output: [info] Removing any rTorrent session lock files left over from the previous run... 2018-06-12 21:04:37,030 DEBG 'rtorrent-script' stdout output: [info] rTorrent not running 2018-06-12 21:04:37,031 DEBG 'rtorrent-script' stdout output: [info] Removing any rTorrent session lock files left over from the previous run... 2018-06-12 21:04:37,032 DEBG 'rtorrent-script' stdout output: [info] Attempting to start rTorrent... 2018-06-12 21:04:37,033 DEBG 'rtorrent-script' stdout output: Script started, file is /home/nobody/typescript 2018-06-12 21:04:37,059 DEBG 'rtorrent-script' stdout output: Script done, file is /home/nobody/typescript 2018-06-12 21:04:37,060 DEBG 'rtorrent-script' stdout output: [info] Autodl-irssi not enabled, skipping startup

That's kind of a loaded question, so I'm going to say... it depends. I have Plex Pass and tried to load up my music into Plex and it frustrated me. I have pretty meticulous tagging including embedded artwork and all I really wanted it to do was just use what was already there. It tries to be "helpful" and download all sorts of info for you on the songs and completely overwrites a bunch of the info for you and grabs whatever artwork it decides it should use, etc. That was especially annoying for me as I have a lot of anime music and it replaced my artists, song titles, etc that I had tagged in romanji (basically English letters representing the Japanese words) with actual Japanese text. Needless to say, while I enjoy anime and its music, I can't read a lick of Japanese and it rendered it completely useless to me. There is a way to try to get Plex music to just use the embedded metadata, but even when I turned those settings on, it still seemed to be grabbing the wrong artwork for some things and messing up some titles etc so I'm not sure what it is doing. That led me to subsonic, then to libresonic, and now finally to airsonic (this docker container). I like that it uses my embedded artwork and metadata and so far has not tried to "help" me by grabbing a bunch of extra crap I don't need. I did have to redo my folder structure as it is very stringent/dependent/expected on that being in a specific format, but once I did so it has been working well for me. It is nice now as I don't have to manually copy music to my phone anymore either. I can install DSub on a new device and sync playlists very easily with minimal effort. And the nice thing about DSub is it stores mp3s as mp3s actually on the device (can't say about non-mp3 because that is all I have) so you can see them with other music players as well. The one thing I don't like about airsonic goes back to the folder structure and why I had to redo it. It takes all files in a single folder as an album, so it just grabs the artwork out of the first file as the artwork and applies it to everything in there. So I couldn't have stuff from different albums in the same folder. As I said though after I re-did my folder structure to be more "standard", it works great. So TL;DR would be that if you have spent a lot of time making your metadata and tags perfect and want to use it, then don't use Plex and use something like *sonic (I recommend airsonic, given the issues the others have). On the other hand, if your music is pretty messy and you haven't spend any time organizing or tagging it (and it is in English or a language you understand/can read), then Plex music might be a good way to have it organize it for you.

Did a recent container upgrade also update or upgrade python or maybe something else? I use a Plex agent & scanner plug-in for anime (ASS/HAMA) that is written in python and suddenly it stopped working correctly. I have not changed/updated the plug-in for months, so there shouldn't have been any changes to the plug-in code itself. One thing it does is pull down an xml from github and now that part is throwing an error as of yesterday. Creating: /tmp/anime-list-corrections.xml Error downloading ScudLee's file mod from local/GitHub 'http://rawgit.com/Dingmatt/AMSA/master/Plug-in%20Support/Data/com.plexapp.agents.amsa/DataItems/anime-list-corrections.xml', Exception: '<urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:590)>' Creating: /tmp/ASS-tmp-anime-list-master.xml Error parsing ScudLee's file mod content, Exception: '<urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:590)>' I've dug through the code/py file some and it is using urlopen(URL).read() to try to grab the xml file. The creator isn't sure the cause, so trying to cover all bases to see where it stems from. Plex forums link in case there is any interest.

Yeah I just got Airsonic going really to use as my phone music sync app via DSub, but it is nice to have music playing on my system while I'm working on stuff too occasionally. I did try clearing the cookies for the site on Chrome, but haven't gone nuclear yet on cache and such. I don't think it is a Chrome extension as I haven't changed those and it was just working a couple days ago. Honestly I'm kind of digging having it running on Edge instead as notifications actually work on there so I see a Windows notification pop up when it changes songs and such. Google has seen fit to block Chrome notifications from working on local websites (technically non-trusted sites, but that includes stuff running on my unraid server). If it gets too frustrating for me I can open an issue on the Airsonic github. Thanks!

I've been setting up and playing with my Airsonic container over the past week or two and suddenly I started running into a problem over the past couple days where, when playing back music in Chrome browser, it stops at the end of every song. I have to select or skip to the next song in the queue and then it will play that song, until the end of that one and it stops playing again. Rinse and repeat. It seems like it is similar to what is seen in this Subsonic bug thread, but all my files are just regular mp3s, no FLAC or anything else really exotic or otherwise. But after reading that, I noticed that for almost every song the time in the player would show as 1 second longer than the length listed in the playlist. I tried going in to the settings and under "Players" select the "web" player and unchecked all the "Active Transcoding" boxes to make sure it wasn't a transcoding issue (I assume unchecking those disables transcoding). I don't see anything in the /config/airsonic.log file, just the file playback info messages. No errors or even warnings when this happens. I found out I can just open up Airsonic in Microsoft Edge browser instead and it seems to work fine there, so the problem looks to be specific to Chrome. I've tried restarting Chrome and also restarting the container. Anyone seen this before or any ideas?

Funnily enough, that link recommends using the preclear plugin on unRAID v6 systems...

Thanks for quick fix/revert. Applied latest update and working again.

Just noticed there was an update to this container tonight and so I was going to run it quick before going to bed (famous last words...) and now after applying the update it is not starting correctly. The container runs but nothing comes up. I can connect to the web UI but it says it can't connect to rtorrent itself. Connecting to the container via docker exec -it and switch to nobody user, there is no tmux session running like normal. I don't believe openvpn is connecting either so might be why rtorrent isn't even trying to start yet. root@yggdrasil:/mnt/user/appdata/rtorrentvpn-binhex/rtorrent/config# docker exec -it rtorrentvpn-binhex /bin/bash [root@97ce8ed60181 /]# su nobody [nobody@97ce8ed60181 /]$ tmux ls no server running on /tmp/tmux-99/default [nobody@97ce8ed60181 /]$ Looking at the docker log, this just continually is cycling in there (changed IP obviously): 2017-12-18 23:26:21,475 DEBG 'start-script' stdout output: Mon Dec 18 23:26:21 2017 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts 2017-12-18 23:26:21,476 DEBG 'start-script' stdout output: Mon Dec 18 23:26:21 2017 TCP/UDP: Preserving recently used remote address: [AF_INET]1.2.3.4:443 Mon Dec 18 23:26:21 2017 Socket Buffers: R=[212992->212992] S=[212992->212992] Mon Dec 18 23:26:21 2017 UDP link local: (not bound) Mon Dec 18 23:26:21 2017 UDP link remote: [AF_INET]1.2.3.4:443 2017-12-18 23:27:21,337 DEBG 'start-script' stdout output: Mon Dec 18 23:27:21 2017 [UNDEF] Inactivity timeout (--ping-restart), restarting 2017-12-18 23:27:21,338 DEBG 'start-script' stdout output: Mon Dec 18 23:27:21 2017 SIGHUP[soft,ping-restart] received, process restarting 2017-12-18 23:27:21,339 DEBG 'start-script' stdout output: Mon Dec 18 23:27:21 2017 WARNING: file 'credentials.conf' is group or others accessible Mon Dec 18 23:27:21 2017 OpenVPN 2.4.4 x86_64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Sep 26 2017 Mon Dec 18 23:27:21 2017 library versions: OpenSSL 1.1.0f 25 May 2017, LZO 2.10 2017-12-18 23:27:21,340 DEBG 'start-script' stdout output: Mon Dec 18 23:27:21 2017 Restart pause, 5 second(s) I usually update my containers over the weekend. I know I checked on all of mine and ran the updates. Can't be sure if there was a rtorrentvpn update or not, but I would have at least checked. So that makes me think this update would have came out within the past day or two. Was working fine just minutes before applying the update.

Yeah 192.168.1.X is extremely common as the default on consumer routers and you are going to run into routing problems like that especially when trying to VPN from other locations (where others haven't bothered to change the defaults either). Also, since it is so common, it would probably be the first thing someone would try when trying to hack through a NAT. I always make sure to pick some other random uncommon subnet to use when first setting up my local network, and would recommend doing the same to avoid stuff like this and also to make it ever so slightly harder for someone to get into your network.

@puma1824 Thanks for putting that info/procedure together for me, and so quickly. It worked great! Now able to connect from my phone. I'm at home so can't test from my laptop right now (well easily anyway, would have to start up a tethering session or something), but now that the phone is working I'm pretty confident it will. I'll probably give it a try remotely before taking off this weekend, but puts my mind at ease. Was a bit panic-y. =) Thanks again! edit: Btw, re-noticed the first quote you had there. Is this related to running a cache pool with mirroring? I've had trouble with cache mirroring and trying to run torrent containers, wonder if this is another ding on that setup. Might be getting time to convert back to single drive cache instead.

Not sure what happened, but I can no longer connect to my OpenVPN-AS container setup. I set up the container a couple months ago and have had no issues since, until now. I believe the last time I successfully connected remotely was late last week. If I remember correctly there was an update to the container over the weekend or recently that I applied. No errors showing in the docker/container log, but I can no longer connect using Windows client or from my Android phone, both of which used to work fine as I said. I've made no changes other than updating. I can access the web GUI page remotely (and on my LAN of course, along with the admin page), and it does seem to get the initial handshake, but times out connecting after about 60 seconds or so. Here's what I see in the ovpn log under my appdata directory when a client is trying to connect: 2017-11-01 16:14:10-0500 [-] OVPN 32 OUT: 'Wed Nov 1 16:14:10 2017 <IP>:34291 TLS: Initial packet from [AF_INET]<IP>:34291, sid=<sid>' 2017-11-01 16:14:10-0500 [-] OVPN 32 OUT: 'Wed Nov 1 16:14:10 2017 <IP>:34291 TLS Error: reading acknowledgement record from packet' ... repeat ~50 times 2017-11-01 16:15:09-0500 [-] OVPN 32 OUT: 'Wed Nov 1 16:15:09 2017 <IP>:45709 TLS Error: reading acknowledgement record from packet' 2017-11-01 16:15:10-0500 [-] OVPN 32 OUT: 'Wed Nov 1 16:15:10 2017 <IP>:34291 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)' 2017-11-01 16:15:10-0500 [-] OVPN 32 OUT: 'Wed Nov 1 16:15:10 2017 <IP>:34291 TLS Error: TLS handshake failed' 2017-11-01 16:15:10-0500 [-] OVPN 32 OUT: 'Wed Nov 1 16:15:10 2017 <IP>:34291 SIGUSR1[soft,tls-error] received, client-instance restarting' 2017-11-01 16:15:52-0500 [-] OVPN 32 OUT: 'Wed Nov 1 16:15:52 2017 <IP>:45709 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)' 2017-11-01 16:15:52-0500 [-] OVPN 32 OUT: 'Wed Nov 1 16:15:52 2017 <IP>:45709 TLS Error: TLS handshake failed' 2017-11-01 16:15:52-0500 [-] OVPN 32 OUT: 'Wed Nov 1 16:15:52 2017 <IP>:45709 SIGUSR1[soft,tls-error] received, client-instance restarting' Of course I'm going out of town this weekend and would ideally really want it to be working for that. Any thoughts or ideas on what broke? I've tried restarting the container, but no joy. Also tried reinstalling my Windows client using the msi installer off the web gui after logging in through there, which does at least let me login with my vpn credentials.

From what I've seen on Plex forums, tar'ing is a recommended way to back it up, because the issue you are running into with millions of files. You only end up with a single file to delete/transfer which can greatly improve times. By doing that though you don't have the option of doing incremental syncs, but the trade-off seems like it would probably be worth it rather than hanging your entire NAS! Not sure if it only makes sense to restrict that to Plex though, or make it universal for all the appdata backups (maybe one tar for each folder in there?).

Using rsync is a cool work around. Thanks for the info, will have to give that a try when I get my backups going!

Guessing you got it fixed? Saw a new update available, applied, and now it is working again. Thanks!