jortan Posted May 8, 2020 Share Posted May 8, 2020 It used to be possible to mount /cardigann in the container and Jackett would load definitions from /cardigann/definitions At some point this has stopped working. From jackett log: Info Loading Cardigann definitions from: /home/nobody/.config/cardigann/definitions/, /etc/xdg/cardigan/definitions/, /usr/lib/jackett/Definitions This can be fixed with a new container path: Container path: /home/nobody/.config/cardigann Host path: /mnt/user/appdata/binhex-jackett/cardigann You want your yaml definitions in this folder: /mnt/user/appdata/binhex-jackett/cardigann/definitions 1 Quote Link to comment
Cobragt88 Posted May 12, 2020 Share Posted May 12, 2020 Hello first great docker app. Got a minor bug that I thought I'd pass on. Anytime I try too add the private torrent tracker Torrentday it gives me an error. "Request to Jackett Server Failed". From the log file : at Jackett.Server.Middleware.CustomExceptionHandler.Invoke(HttpContext httpContext) in /home/vsts/work/1/s/src/Jackett.Server/Middleware/CustomExceptionHandler.cs:line 70 System.Exception: Error parsing JS challenge HTML in red. That seems to be every time I try too add The Tracker Torrentday.com as an Indexer. If required more logs I can. Quote Link to comment
DaveDoesStuff Posted May 13, 2020 Share Posted May 13, 2020 (edited) Started getting parsing errors and torznab feed errors around 3 days ago, right around the time there was an update if I remember correctly. These issues usually coincide with Radarr/Sonarr/Qbittorrentvpn (all binhex) suffering from a major slow down. But possible that's not relevant. Failed to parse magnetlink for movie 'Howl's Moving Castle (2004) [BluRay] [1080p] [YTS] [YIFY]': 'magnet:?xt=urn:btih:7C7A5296A370A5D8067C712DA5146BF5A868E846&dn=Howl's+Moving+Castle+(2004)+[BluRay]+[1080p]+[YTS]+[YIFY]&tr=udp://tracker.coppersurfer.tk:6969/announce&tr=udp://9.rarbg.com:2710/announce&tr=udp://p4p.arenabg.com:1337&tr=udp://tracker.leechers-paradise.org:6969&tr=udp://tracker.internetwarriors.net:1337&tr=udp://tracker.opentrackr.org:1337/announce&tr=udp://tracker.zer0day.to:1337/announce&tr=udp://tracker.leechers-paradise.org:6969/announce&tr=udp://coppersurfer.tk:6969/announce': A field-value pair of the magnet link contain more than one equal'. System.FormatException: A field-value pair of the magnet link contain more than one equal'. at MonoTorrent.MagnetLink.ParseMagnetLink (System.String url) [0x002b0] in C:\projects\radarr-usby1\src\MonoTorrent\MagnetLink.cs:93 at MonoTorrent.MagnetLink..ctor (System.String url) [0x00022] in C:\projects\radarr-usby1\src\MonoTorrent\MagnetLink.cs:32 at NzbDrone.Core.Download.TorrentClientBase`1[TSettings].DownloadFromMagnetUrl (NzbDrone.Core.Parser.Model.RemoteMovie remoteMovie, System.String magnetUrl) [0x00004] in C:\projects\radarr-usby1\src\NzbDrone.Core\Download\TorrentClientBase.cs:203 The above is happening for any attempt to add a movie/release (no matter the tracker) with a ' in the title. Error taken from Radarr. The below is what the sonarr logs look like, pages and pages of this...not sure if its related but all my trackers for Sonarr and Radarr are all done through jackett only. For the record I'm not attempting to track/call for any of the content mentioned in that above list (pioneer one, allah the movie lol). I'm aware this is the jackett thread, but the issues being logged in Radarr and Sonarr to point to jackett and jacketts logs are practically empty so I've attached them in case it's helpful. But to be honest I'm having a hard time telling where these sudden issues lie so sorry if I'm being an ass and looking at the wrong thing. radarr.txt sonarr.txt Edited May 13, 2020 by DaveDoesStuff Spelling Quote Link to comment
tjb_altf4 Posted May 13, 2020 Share Posted May 13, 2020 2 hours ago, DaveDoesStuff said: The above is happening for any attempt to add a movie/release (no matter the tracker) with a ' in the title. Error taken from Radarr. This link covers the issue as being a Radarr/Sonarr one https://github.com/Radarr/Radarr/issues/3256 A quick read suggests it is limited to magnet links, try avoiding in the short term if possible, looks like a fix is in the pipeline. 1 Quote Link to comment
DaveDoesStuff Posted May 13, 2020 Share Posted May 13, 2020 6 hours ago, tjb_altf4 said: This link covers the issue as being a Radarr/Sonarr one https://github.com/Radarr/Radarr/issues/3256 A quick read suggests it is limited to magnet links, try avoiding in the short term if possible, looks like a fix is in the pipeline. Thanks for that, I had seen that post on github but was unclear on whether or not the fix/improvement was already made or not. Quote Link to comment
PeteRock Posted May 21, 2020 Share Posted May 21, 2020 I am running binhex-jackett and using it with binhex-delugevpn, binhex-sonarr and binhex-radarr (thanks binhex!) I am running sonarr, radarr and jackett through the privoxy proxy generated by the delugevpn, and it seems to work fine, except for the demonoid tracker. I add the tracker by logging in and getting the cookie, and it passes testing in jackett, but when I try to add it using torznab and test, I get the msg: "No results were returned from your indexer, please check your settings." ... in both sonarr and radarr. The tracker works fine within jackett, expect for a slightly weird behavior when doing manual search using the demonoid tracker. When I set category to "Any" or "All", lots of stuff shows up including movies and tv shows, but when I try to restrict to a category, say "2000 (Movies)" no results show up. Not sure this is related to my problem with sonarr and radarr, but thought I would mention it. Thanks. Quote Link to comment
binhex Posted May 27, 2020 Author Share Posted May 27, 2020 fyi guys, i have reduced the builds for this image so that it will now produce a new image at a maximum of every 5 days as opposed to every jackett release as it was getting crazy frequent, so dont panic if you dont see a release every other day like before. 2 Quote Link to comment
Silverhand77 Posted June 8, 2020 Share Posted June 8, 2020 Hi All, I am on Unraid 6.8.2 with all dockers updated & am experiencing an issue with Binhex-Jackett as follows: If I enable PIA socks proxy in Binhex-Jackett everything works fine, but after a short period Binhex-Jackett starts maxing out the CPU & Binhex-Sonarr & Binhex-Radarr start to struggle & I get the following error in the docker UI: Indexers unavailable due to failures: The Pirate Bay, Kickass Torrent, ETTV, EZTV, TGx I then have to re-start the docker in order to correct this. If anyone has a fix for this it would be greatly appreciated. I am more than happy to provide additional information if needed. Quote Link to comment
binhex Posted June 9, 2020 Author Share Posted June 9, 2020 On 6/8/2020 at 8:07 AM, Silverhand77 said: but after a short period Binhex-Jackett starts maxing out the CPU & Binhex-Sonarr & Binhex-Radarr start to struggle & I get the following error in the docker UI: this used to be an issue with mono, but i havent seen this particular issue for sometime, im assuming you have the latest jackett image right?. one other thing you can do to mitigate this is to pin cores to the container, this will restrict how much cpu hogging it can do, i know its a workaround and not a fix but it will for the time being at least stop your system from locking up. Quote Link to comment
4554551n Posted June 24, 2020 Share Posted June 24, 2020 (edited) Hi binhex, I've just joined this forum to say I've got the same issues happening as described by Silverhand. I am on 6.8.3, and the latest binhex-jackett docker image, which goes nuts when the pia socks proxy is applied. I have it pinned to a CPU as you suggested to mitigate the damage. Would it be possible to please ask you to have another look at this, as it does seem to be affecting a few people. [edit] Pinning to CPU doesn't mitigate the errors from the other dockers, so it requires a lot of manual oversight and regular restarts just to have sonarr and radarr to work as intended and get regular automated downloads. Edited June 24, 2020 by 4554551n More information Quote Link to comment
Silverhand77 Posted June 25, 2020 Share Posted June 25, 2020 On 6/9/2020 at 5:51 PM, binhex said: this used to be an issue with mono, but i havent seen this particular issue for sometime, im assuming you have the latest jackett image right?. one other thing you can do to mitigate this is to pin cores to the container, this will restrict how much cpu hogging it can do, i know its a workaround and not a fix but it will for the time being at least stop your system from locking up. Hi, Sorry for taking so long to reply. Yes I have the latest Jackett & I have pinned a core to the container like you have advised. The issue that this is causing is that when the CPU maxes out, Sonarr & Radarr become unable to connect to the indexers until I restart Jackett & successfully re-test all the indexers. I am hoping there is a fix some time soon, I am grateful for your time & effort in investigating & resolving this if possible. Quote Link to comment
Nowjon Posted July 15, 2020 Share Posted July 15, 2020 On 6/25/2020 at 2:45 PM, Silverhand77 said: Hi, Sorry for taking so long to reply. Yes I have the latest Jackett & I have pinned a core to the container like you have advised. The issue that this is causing is that when the CPU maxes out, Sonarr & Radarr become unable to connect to the indexers until I restart Jackett & successfully re-test all the indexers. I am hoping there is a fix some time soon, I am grateful for your time & effort in investigating & resolving this if possible. Do you happen to have another VPN container? I have my DelugeVPN container running and I have the Jackett docker use it's network by setting the network type = none and then adding "--net=container:binhex-delugevpn" to the Extra Parameters. I haven't noticed any of the issue you've described, maybe this could be a helpful workaround! Quote Link to comment
4554551n Posted July 26, 2020 Share Posted July 26, 2020 On 7/16/2020 at 8:13 AM, Nowjon said: Do you happen to have another VPN container? I have my DelugeVPN container running and I have the Jackett docker use it's network by setting the network type = none and then adding "--net=container:binhex-delugevpn" to the Extra Parameters. I haven't noticed any of the issue you've described, maybe this could be a helpful workaround! Thank you, that's a little awkward, but otherwise a really good work around. However I notice that doing that removes the webUI option from the jackett docker, and I can't navigate to it via the port anymore. Do you just set the settings you want, then make the above change, and revert the change next time you want to modify jackett again, or is there an easier way? @binhex I was wondering if this is something you'd consider looking at? Not rushing, just curious if waiting is a valid option, or I need to look more into exploring something like the above? Quote Link to comment
Nowjon Posted July 26, 2020 Share Posted July 26, 2020 15 hours ago, 4554551n said: Thank you, that's a little awkward, but otherwise a really good work around. However I notice that doing that removes the webUI option from the jackett docker, and I can't navigate to it via the port anymore. Do you just set the settings you want, then make the above change, and revert the change next time you want to modify jackett again, or is there an easier way? @binhex I was wondering if this is something you'd consider looking at? Not rushing, just curious if waiting is a valid option, or I need to look more into exploring something like the above? Take a look at You could also get the amazing Docker Folder plugin and add a button from the folder to the item Quote Link to comment
4554551n Posted July 30, 2020 Share Posted July 30, 2020 (edited) Ok, that's been super helpful, thank you. I still have the webui problem even though I forward the port 9117 in the delugevpn container (which I didn't do before the video). Everything works, curl ifconfig.io is the same on both containers, and radarr and sonarr test fine with the jackett based indexers(!), but I still can't get at the webui using ip:port. Just says connection timed out. Though it does correctly add "/UI/Dashboard" after ip:port automatically like it would the old way. Any thoughts? Edited July 30, 2020 by 4554551n Quote Link to comment
cybrnook Posted August 19, 2020 Share Posted August 19, 2020 @binhex hope you are well. Still loving a good handful of your dockers 🙂 Just wanted to ask if you still are following the "tags" of Jackett to then push updates? I noticed my Jackett docker hadn't updated in a few days, so I checked their tags and looks like we're on "Jackett Version 0.16.991.0" when Jacket has tags up to 0.16.1017.0, which means we are four releases behind. https://github.com/Jackett/Jackett/tags Just wanted to make sure something in your automation wasn't going awry. Quote Link to comment
tjb_altf4 Posted August 19, 2020 Share Posted August 19, 2020 On 5/27/2020 at 7:42 PM, binhex said: fyi guys, i have reduced the builds for this image so that it will now produce a new image at a maximum of every 5 days as opposed to every jackett release as it was getting crazy frequent, so dont panic if you dont see a release every other day like before. @cybrnook 1 1 Quote Link to comment
cybrnook Posted August 19, 2020 Share Posted August 19, 2020 4 minutes ago, tjb_altf4 said: @cybrnook Thanks 👍 Quote Link to comment
Jorgen Posted August 19, 2020 Share Posted August 19, 2020 Hey, is it possible to add a VPN to Jacket ? I don't use a locally P2P client so I can't use DeluveVPN or something else. Thank you ! Probably the simplest solution is to use binhex privoxy docker to create the VPN tunnel and then configure Jackett to use it as a proxy.Sent from my iPhone using Tapatalk Quote Link to comment
roobix Posted August 23, 2020 Share Posted August 23, 2020 (edited) Does anyone know what causes the docker to display as abandoned in Unraid? I can't remember the exact msg that Unraid displayed, but my Binhex Jacett docker dropped to the bottom of the docker list and i couldn't open it to edit settings. I had to go into CA and reinstall. Edited August 23, 2020 by roobix Quote Link to comment
4554551n Posted August 26, 2020 Share Posted August 26, 2020 On 7/30/2020 at 11:49 PM, 4554551n said: Ok, that's been super helpful, thank you. I still have the webui problem even though I forward the port 9117 in the delugevpn container (which I didn't do before the video). Everything works, curl ifconfig.io is the same on both containers, and radarr and sonarr test fine with the jackett based indexers(!), but I still can't get at the webui using ip:port. Just says connection timed out. Though it does correctly add "/UI/Dashboard" after ip:port automatically like it would the old way. Any thoughts? Can anyone please shed any light on this? It's super confusing why the webgui doesn't work Quote Link to comment
binhex Posted August 26, 2020 Author Share Posted August 26, 2020 1 hour ago, 4554551n said: Can anyone please shed any light on this? It's super confusing why the webgui doesn't work if you are linking containers together (and im assuming thats what you have done) then you will need to use the 'additional_ports' env var to define the web ui port for jackett, you should then be able to connect to the jackett web ui - note the 'web ui' link on the container will obviously not work, as it can only point at one url, usually the hosts app container, i.e. in your case Deluge web ui. Quote Link to comment
4554551n Posted August 26, 2020 Share Posted August 26, 2020 2 hours ago, binhex said: if you are linking containers together (and im assuming thats what you have done) then you will need to use the 'additional_ports' env var to define the web ui port for jackett, you should then be able to connect to the jackett web ui - note the 'web ui' link on the container will obviously not work, as it can only point at one url, usually the hosts app container, i.e. in your case Deluge web ui. "additional_ports"? I watched the video abvoe and followed the instructions there. And I did set up a "port" config type in deluge with Host Port being 9117 (the port used by jackett), but navigating to the URl just gives the default can't be loaded screen. Jackett has no webui option now, and that's fine. I can use bookmarks lol, but putting in the URL:port, having set the extra "port" in deluge still doesn't work, and I followed the instructions in the above video specifically, so I'm really unsure why that's happening Quote Link to comment
binhex Posted August 26, 2020 Author Share Posted August 26, 2020 12 minutes ago, 4554551n said: "additional_ports"? yes 'additional_ports' its required to allow access to specific ports as the strict iptable rules will block by default, you may have an out of date template perhaps that doesnt have this setting, if so please add it as a config type of 'variable' to delugevpn, it should look something like the below:- Quote Link to comment
jebusfreek666 Posted August 29, 2020 Share Posted August 29, 2020 (edited) It appears that some time in the last few days jackett has become unreachable for me for both Sonarr and Radarr. I am not able to complete auto searches or manual searches. Reading the log in Sonarr shows: System.Net.WebException: Error getting response stream (ReadDoneAsync2): ReceiveFailure: 'http://192.168.1.69:9117/api/v2.0/indexers/all/results/torznab/api?t=tvsearch&cat=5030,5040,5070,100003&extended=1&apikey=DELETEDFORPRIVACY&offset=0&limit=1000' ---> System.Net.WebException: Error getting response stream (ReadDoneAsync2): ReceiveFailure at System.Net.WebResponseStream.InitReadAsync (System.Threading.CancellationToken cancellationToken) [0x000e6] in /build/mono/src/mono/mcs/class/System/System.Net/WebResponseStream.cs:458 at System.Net.WebOperation.Run () [0x0018f] in /build/mono/src/mono/mcs/class/System/System.Net/WebOperation.cs:283 at System.Net.WebCompletionSource`1[T].WaitForCompletion () [0x0008e] in /build/mono/src/mono/mcs/class/System/System.Net/WebCompletionSource.cs:111 at System.Net.HttpWebRequest.RunWithTimeoutWorker[T] (System.Threading.Tasks.Task`1[TResult] workerTask, System.Int32 timeout, System.Action abort, System.Func`1[TResult] aborted, System.Threading.CancellationTokenSource cts) [0x000e8] in /build/mono/src/mono/mcs/class/System/System.Net/HttpWebRequest.cs:956 at System.Net.HttpWebRequest.GetResponse () [0x0000f] in /build/mono/src/mono/mcs/class/System/System.Net/HttpWebRequest.cs:1218 at NzbDrone.Common.Http.Dispatchers.ManagedHttpDispatcher.GetResponse (NzbDrone.Common.Http.HttpRequest request, System.Net.CookieContainer cookies) [0x0011b] in C:\BuildAgent\work\5d7581516c0ee5b3\src\NzbDrone.Common\Http\Dispatchers\ManagedHttpDispatcher.cs:82 --- End of inner exception stack trace --- at NzbDrone.Common.Http.Dispatchers.ManagedHttpDispatcher.GetResponse (NzbDrone.Common.Http.HttpRequest request, System.Net.CookieContainer cookies) [0x001ca] in C:\BuildAgent\work\5d7581516c0ee5b3\src\NzbDrone.Common\Http\Dispatchers\ManagedHttpDispatcher.cs:113 at NzbDrone.Common.Http.Dispatchers.FallbackHttpDispatcher.GetResponse (NzbDrone.Common.Http.HttpRequest request, System.Net.CookieContainer cookies) [0x000b5] in C:\BuildAgent\work\5d7581516c0ee5b3\src\NzbDrone.Common\Http\Dispatchers\FallbackHttpDispatcher.cs:53 at NzbDrone.Common.Http.HttpClient.ExecuteRequest (NzbDrone.Common.Http.HttpRequest request, System.Net.CookieContainer cookieContainer) [0x0007e] in C:\BuildAgent\work\5d7581516c0ee5b3\src\NzbDrone.Common\Http\HttpClient.cs:121 at NzbDrone.Common.Http.HttpClient.Execute (NzbDrone.Common.Http.HttpRequest request) [0x00008] in C:\BuildAgent\work\5d7581516c0ee5b3\src\NzbDrone.Common\Http\HttpClient.cs:57 at NzbDrone.Core.Indexers.HttpIndexerBase`1[TSettings].FetchIndexerResponse (NzbDrone.Core.Indexers.IndexerRequest request) [0x0004b] in C:\BuildAgent\work\5d7581516c0ee5b3\src\NzbDrone.Core\Indexers\HttpIndexerBase.cs:321 at NzbDrone.Core.Indexers.HttpIndexerBase`1[TSettings].FetchPage (NzbDrone.Core.Indexers.IndexerRequest request, NzbDrone.Core.Indexers.IParseIndexerResponse parser) [0x00000] in C:\BuildAgent\work\5d7581516c0ee5b3\src\NzbDrone.Core\Indexers\HttpIndexerBase.cs:298 at NzbDrone.Core.Indexers.HttpIndexerBase`1[TSettings].TestConnection () [0x0000e] in C:\BuildAgent\work\5d7581516c0ee5b3\src\NzbDrone.Core\Indexers\HttpIndexerBase.cs:335 Not sure what the issue is. I have touched nothing, and have actually been out of town all week. If I copy and paste "http://192.168.1.69:9117/api/v2.0/indexers/all/results/torznab/api?t=tvsearch&cat=5030,5040,5070,100003&extended=1&apikey=DELETEDFORPRIVACY&offset=0&limit=1000" into a browser on its own i get responses. So I have no idea why Sonarr/Radarr have "ReceiveFailure". Not even sure if the problem is with Radarr, Sonarr, or Jackett.... Edit for more info: Just looked at the settings for deluge in sonarr as well, and attmepted to test and it kicked back a red error on that page after failing stating "Unknown exception: Unable to write data to the transport connection: The socket has been shut down." So it seems something big is going on.... Turning off PIA for deluge seems to fix everything..... however, not a realistic everyday fix. So clearly the issue is with the way VPN is being handled in a recent update? Checked the credentials, and they are fine and my PIA account is up to date. Edit 2: After pulling down the image for deluge with PIA off, and confirming everything worked I then pulled down the image with it turned back on. After retesting the indexer and download client in both Sonarr and Radarr, everything seems to be working correctly again. Not sure how long it will last, or what caused the hiccup in the first place but I will update later if it conks out again. Edit 3: After 2 manual searches, it is back the the same behavior I reported at the beginning of the post. Edited August 29, 2020 by jebusfreek666 Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.