renocz Posted December 17, 2020 Share Posted December 17, 2020 Hi, i posted a solution for that on the linuxserver.io - Jackett thread I think it should solve your issue Quote Link to comment
thymon Posted December 17, 2020 Share Posted December 17, 2020 (edited) 1 hour ago, renocz said: Hi, i posted a solution for that on the linuxserver.io - Jackett thread I think it should solve your issue I kown but I don’t see any of these settings in Jackett configuration. So I’ll wait the next docker update Edited December 17, 2020 by thymon Quote Link to comment
PeterB Posted January 25, 2021 Share Posted January 25, 2021 I have posted some of this info in a reply in the delugevpn thread, but I think it really belongs here. I find that the Jacket rarbg fetcher sometimes fetches a 1.3kB file containing html which says something about enabling cookies, instead of the legitimate torrent file of around 80kB. I'm still struggling with this. Resetting the configuration of the rarbg fetcher in Jacket seems to make it work once, then the next time it fails again. In case it makes a difference, I'm using Jacket with CouchPotato. Has anyone else encountered this or, better, found a solution. I've never had any success with the 1337 or isohunt fetchers. Quote Link to comment
tjb_altf4 Posted January 25, 2021 Share Posted January 25, 2021 4 minutes ago, PeterB said: I have posted some of this info in a reply in the delugevpn thread, but I think it really belongs here. I find that the Jacket rarbg fetcher sometimes fetches a 1.3kB file containing html which says something about enabling cookies, instead of the legitimate torrent file of around 80kB. I'm still struggling with this. Resetting the configuration of the rarbg fetcher in Jacket seems to make it work once, then the next time it fails again. In case it makes a difference, I'm using Jacket with CouchPotato. Has anyone else encountered this or, better, found a solution. I've never had any success with the 1337 or isohunt fetchers. Look a few posts up RE: Flaresolver Quote Link to comment
xxDeadbolt Posted January 28, 2021 Share Posted January 28, 2021 On 12/10/2020 at 8:36 AM, xxDeadbolt said: Has the magdl.com indexer disappeared for anyone else? Had this set up but seems to have gone after a recent update, I think. Trying to track back to find out exactly when but no joy so far Had forgotten about this for a while, but it seems the site maintainer requested the removal, in case anyone was wondering or had the same issue. Quote Link to comment
xxDeadbolt Posted February 25, 2021 Share Posted February 25, 2021 Anyone having issues accessing the gui? Seems to have just been today for me. Logs look fine, just can't access gui & Radarr/Sonarr both say indexers down. This is Jackett log: 2021-02-25 12:24:57,088 DEBG 'jackett' stdout output: 02-25 12:24:57 Info Jackett startup finished in 2.346 s 2021-02-25 12:24:57,088 DEBG 'jackett' stdout output: Hosting environment: Production Content root path: /usr/lib/jackett/Content Now listening on: http://[::]:9117 Application started. Press Ctrl+C to shut down. Radarr/Sonarr just show a 503:ServiceUnavailable message. Quote Link to comment
binhex Posted February 25, 2021 Author Share Posted February 25, 2021 41 minutes ago, xxDeadbolt said: Anyone having issues accessing the gui? Seems to have just been today for me. Logs look fine, just can't access gui & Radarr/Sonarr both say indexers down. This is Jackett log: 2021-02-25 12:24:57,088 DEBG 'jackett' stdout output: 02-25 12:24:57 Info Jackett startup finished in 2.346 s 2021-02-25 12:24:57,088 DEBG 'jackett' stdout output: Hosting environment: Production Content root path: /usr/lib/jackett/Content Now listening on: http://[::]:9117 Application started. Press Ctrl+C to shut down. Radarr/Sonarr just show a 503:ServiceUnavailable message. are you by any chance routing jackett through another container? Quote Link to comment
xxDeadbolt Posted February 25, 2021 Share Posted February 25, 2021 (edited) 1 hour ago, binhex said: are you by any chance routing jackett through another container? Yup, routing it through your rTorrentvpn container. Edited February 25, 2021 by xxDeadbolt Quote Link to comment
binhex Posted February 25, 2021 Author Share Posted February 25, 2021 21 minutes ago, xxDeadbolt said: Yup, routing it through your rTorrentvpn container. ok, due to tightening of iptable rules you will need to add the web ui port for jackett to the ADDITIONAL_PORTS env var defined for rtorrentvpn. Quote Link to comment
xxDeadbolt Posted February 25, 2021 Share Posted February 25, 2021 (edited) Awesome, sorted! I assume this is the case, but just to double check: am I ok to delete the manual key I created for jackett to run through it, now that it's in the additional_ports? Edit: Oops, tried it and it broke again. Sorted once I added it back 🤣 Cheers binhex! Edited February 25, 2021 by xxDeadbolt 1 Quote Link to comment
xxDeadbolt Posted February 25, 2021 Share Posted February 25, 2021 Strange, all my indexers are failing now 😕 Quote Link to comment
binhex Posted February 25, 2021 Author Share Posted February 25, 2021 2 minutes ago, xxDeadbolt said: Strange, all my indexers are failing now 😕 after adding in the ports this will cause the vpn container to restart, and because the networks are links you will now also need to restart any other containers routed through the vpn container, which in your case is jackett. Quote Link to comment
xxDeadbolt Posted February 25, 2021 Share Posted February 25, 2021 Yeah I've restarted jackett a couple of times, but still failing. Quote Link to comment
xxDeadbolt Posted February 25, 2021 Share Posted February 25, 2021 Think it's fixed now - for some reason, I had the proxy settings set to use the rTorrent/privoxy port 8118 in my jackett settings. I removed that, since it's routing through the container anyway and it's fine now. Cheers again! Quote Link to comment
binhex Posted February 25, 2021 Author Share Posted February 25, 2021 Just now, xxDeadbolt said: Think it's fixed now - for some reason, I had the proxy settings set to use the rTorrent/privoxy port 8118 in my jackett settings. I removed that, since it's routing through the container anyway and it's fine now. Cheers again! ahh yes that would do it :-), thanks for letting me know i was half way through trying to replicate the issue 🙂 1 Quote Link to comment
xxDeadbolt Posted February 25, 2021 Share Posted February 25, 2021 18 minutes ago, binhex said: ahh yes that would do it :-), thanks for letting me know i was half way through trying to replicate the issue 🙂 Can I check - is the privoxy/port 8118 not able to be used with the iptable tightening now? I used the same proxy settings on radarr/sonarr and the indexers were failing in them until I removed it. I'm not entirely sure I need the proxy on them, tbh, when the indexer traffic is being routed through the vpn on rTorrent, but just wondering if this is what's affecting it. Quote Link to comment
binhex Posted February 25, 2021 Author Share Posted February 25, 2021 9 minutes ago, xxDeadbolt said: Can I check - is the privoxy/port 8118 not able to be used with the iptable tightening now? I used the same proxy settings on radarr/sonarr and the indexers were failing in them until I removed it. I'm not entirely sure I need the proxy on them, tbh, when the indexer traffic is being routed through the vpn on rTorrent, but just wondering if this is what's affecting it. lol this is blowing my mind a little, so you have radarr and sonarr both set to point at privoxyvpn, and then the index site is pointing at jackett which is routed through rtorrentvpn, right?. i would need a strong drink to work all that out and the routing implications, but for now i would say just drop the proxy, its not required at all, as jackett is safely doing the biz for you via routing through the vpn tunnel, no need to make things overly complex eh. 1 Quote Link to comment
xxDeadbolt Posted February 25, 2021 Share Posted February 25, 2021 3 minutes ago, binhex said: lol this is blowing my mind a little, so you have radarr and sonarr both set to point at privoxyvpn, and then the index site is pointing at jackett which is routed through rtorrentvpn, right?. i would need a strong drink to work all that out and the routing implications, but for now i would say just drop the proxy, its not required at all, as jackett is safely doing the biz for you via routing through the vpn tunnel, no need to make things overly complex eh. haha yeah that's it. I can't remember setting the proxy manually in radarr/sonarr tbh, so I must've done it a long time ago & never had a reason to change it before now. All working fine now though 🙂 Quote Link to comment
JimmyGerms Posted February 26, 2021 Share Posted February 26, 2021 Second attempt at clarifying what I'm after haha. So, with the changes to the binhex VPN dockers I wanted to verify if I was utilizing Jackett properly. Sonarr and Radarr are currently configured to tunnel through the VPN and have been updated with the proper host setting: 'localhost'. Now, within Jackett these buttons are still using 192.168.1.x causing Sonarr and Radarr to error while grabbing indexers. To fix this, within Sonarr/Radarr I edited what the "Copy Torznab Feed" gives me and replaced 192.168.1.x with 'localhost'. With this, both dockers pass while checking the indexers! Is this the correct way to update these settings? Can I set something up within Jackett so I do not have to manually change the ip address when adding a new indexer? Thanks again for your help and time. I'm learning quite a bit! Quote Link to comment
Jorgen Posted February 26, 2021 Share Posted February 26, 2021 15 hours ago, JimmyGerms said: Second attempt at clarifying what I'm after haha. So, with the changes to the binhex VPN dockers I wanted to verify if I was utilizing Jackett properly. Sonarr and Radarr are currently configured to tunnel through the VPN and have been updated with the proper host setting: 'localhost'. Now, within Jackett these buttons are still using 192.168.1.x causing Sonarr and Radarr to error while grabbing indexers. To fix this, within Sonarr/Radarr I edited what the "Copy Torznab Feed" gives me and replaced 192.168.1.x with 'localhost'. With this, both dockers pass while checking the indexers! Is this the correct way to update these settings? Can I set something up within Jackett so I do not have to manually change the ip address when adding a new indexer? Thanks again for your help and time. I'm learning quite a bit! This doesn't answer your question directly, but in Sonarr/Radarr you can also set them up to use all your configured indexers in jacket, see example from Radarr below. That way you only have to set up one indexer, once, in sonarr/radarr. If you add new indexers to jackett, they will be automatically included by the other apps. Doesn't work if you need different indexers for the different apps though... Quote Link to comment
DrBazUK Posted March 1, 2021 Share Posted March 1, 2021 I seem to be having similar issues to @xxDeadbolt in that I can access Jackett using the GUI on port 9117 and testing the 5 indexers I have in Jackett all work as expected, each reporting a result with a green tick mark. In the Jackett GUI I have configured the proxy to point at the binhex-rTorrentVPN endpoint on port 8118 which I know is working as I can connect through that proxy with my desktop machine and it gives a different IP address than my home IP address. The issue I have is that I can't get Radarr or Sonarr to connect to Jackett (all @binhex repos). I get errors like this from Sonarr: NzbDroneErrorPipeline Invalid request Validation failed: -- Unable to connect to indexer, check the log for more details TorznabUnable to connect to indexer: HTTP request failed: [503:ServiceUnavailable] [GET] at [http://192.168.0.50:9117/api/v2.0/indexers/all/results/torznab/api?t=caps&apikey=(removed) HttpClientHTTP Error - Res: [GET] http://192.168.0.50:9117/api/v2.0/indexers/all/results/torznab/api?t=caps&apikey=(removed) 503.ServiceUnavailable and this from Radarr: 2021-3-1 17:02:48.0|Warn|HttpClient|HTTP Error - Res: [GET] http://192.168.0.50:9117/api/v2.0/indexers/all/results/torznab?t=caps&apikey=(removed) 503.ServiceUnavailable 2021-3-1 17:02:50.1|Warn|HttpClient|HTTP Error - Res: [GET] http://192.168.0.50:9117/api/v2.0/indexers/all/results/torznab?t=caps&apikey=(removed) 503.ServiceUnavailable 2021-3-1 17:02:50.1|Warn|Torznab|Unable to connect to indexer From checking the logs, the errors first started 26 Feb so I don't know if there was a change to one or more of the containers that might have caused an issue as the 4 containers seemed to have been working reasonably well until then. Reinstalling Jackett after nuking the install made no difference. I've tried to add the 9117 port to rTorrent in both the Container Variable: ADDITIONAL_PORTS section and as a separate Container Port as @xxDeadbolt did without any noticeable effect. I may be getting my wires crossed though... I'm out of ideas on what else to try. Any help very gratefully received. Quote Link to comment
binhex Posted March 1, 2021 Author Share Posted March 1, 2021 2 minutes ago, DrBazUK said: I seem to be having similar issues to @xxDeadbolt in that I can access Jackett using the GUI on port 9117 and testing the 5 indexers I have in Jackett all work as expected, each reporting a result with a green tick mark. In the Jackett GUI I have configured the proxy to point at the binhex-rTorrentVPN endpoint on port 8118 which I know is working as I can connect through that proxy with my desktop machine and it gives a different IP address than my home IP address. The issue I have is that I can't get Radarr or Sonarr to connect to Jackett (all @binhex repos). I get errors like this from Sonarr: NzbDroneErrorPipeline Invalid request Validation failed: -- Unable to connect to indexer, check the log for more details TorznabUnable to connect to indexer: HTTP request failed: [503:ServiceUnavailable] [GET] at [http://192.168.0.50:9117/api/v2.0/indexers/all/results/torznab/api?t=caps&apikey=(removed) HttpClientHTTP Error - Res: [GET] http://192.168.0.50:9117/api/v2.0/indexers/all/results/torznab/api?t=caps&apikey=(removed) 503.ServiceUnavailable and this from Radarr: 2021-3-1 17:02:48.0|Warn|HttpClient|HTTP Error - Res: [GET] http://192.168.0.50:9117/api/v2.0/indexers/all/results/torznab?t=caps&apikey=(removed) 503.ServiceUnavailable 2021-3-1 17:02:50.1|Warn|HttpClient|HTTP Error - Res: [GET] http://192.168.0.50:9117/api/v2.0/indexers/all/results/torznab?t=caps&apikey=(removed) 503.ServiceUnavailable 2021-3-1 17:02:50.1|Warn|Torznab|Unable to connect to indexer From checking the logs, the errors first started 26 Feb so I don't know if there was a change to one or more of the containers that might have caused an issue as the 4 containers seemed to have been working reasonably well until then. Reinstalling Jackett after nuking the install made no difference. I've tried to add the 9117 port to rTorrent in both the Container Variable: ADDITIONAL_PORTS section and as a separate Container Port as @xxDeadbolt did without any noticeable effect. I may be getting my wires crossed though... I'm out of ideas on what else to try. Any help very gratefully received. see the support thread for rTorrentVPN and click on the 'recommended post'. Quote Link to comment
DrBazUK Posted March 1, 2021 Share Posted March 1, 2021 17 minutes ago, binhex said: see the support thread for rTorrentVPN and click on the 'recommended post'. Thank you! Q26 solved the issue. For anyone else facing the same issue - this is what solved it: inside both Radarr and Sonarr in the General tab > Proxy settings and "Ignored Addresses" and adding the IP address of my UNRAID server to the Ignored Addresses field. Thanks Binhex, stellar support as always. 1 1 Quote Link to comment
betaman Posted March 1, 2021 Share Posted March 1, 2021 (edited) New to Jackett due to the tightening of iptables issue. Am I correct in assuming that if my indexer isn’t listed then this docker is of no use or could I still use it to route download clients thru? Using nzbplanet for nzb’s and rarbg for torrents. On a side note, I was using Privoxy to route Sonarr, Radarr and Lidarr thru DelugeVPN. Adding the “Additional_Ports” variable for these dockers to DelugeVPN and ignoring my server’s IP address has restored the download client connection to DelugeVPN but not NZBgetVPN. Assuming I can’t make the same changes to NZBgetVPN because a docker update would be required to recognize the Additional Ports variable? Is there a fix to get NZBgetVPN working similar to DelugeVPN or should I bite the bullet and bind these containers to DelugeVPN? Edited March 1, 2021 by betaman Quote Link to comment
Jorgen Posted March 2, 2021 Share Posted March 2, 2021 New to Jackett due to the tightening of iptables issue. Am I correct in assuming that if my indexer isn’t listed then this docker is of no use or could I still use it to route download clients thru? Using nzbplanet for nzb’s and rarbg for torrents. On a side note, I was using Privoxy to route Sonarr, Radarr and Lidarr thru DelugeVPN. Adding the “Additional_Ports” variable for these dockers to DelugeVPN and ignoring my server’s IP address has restored the download client connection to DelugeVPN but not NZBgetVPN. Assuming I can’t make the same changes to NZBgetVPN because a docker update would be required to recognize the Additional Ports variable? Is there a fix to get NZBgetVPN working similar to DelugeVPN or should I bite the bullet and bind these containers to DelugeVPN?I ended up adding all of the download apps in the delugeVPN network, including NzbGet (the non-VPN version from binhex). I am seeing slower download speeds for nzbget this way, but at least it’s working and all apps can talk to each other again.Binhex is working on a secure solution to allow apps inside the VPN network to talk to apps outside it, so it might be possible to run NzbGet on the outside again in the future.Your only other option is to configure sonarr/radarr to talk to NzbGet on the internal docker ip, e.g. 172.x.x.x, but beware that the actual up is dynamic for each container and may change on restarts.Edit: yeah jackett is of no use for NZB’s, you need to set them up as separate indexers in radarr/sonarr. Which shouldn’t be a problem, both apps should talk to the internet freely over the VPN tunnelEdit2: sorry ignore the first bit of my reply, you’re using privoxy, not network binding. Sorry for the confusion. 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.