Hello,
I am currently having an issue using the blackhole directory with RARBG torrents. When I select a torrent to send to the blackhole folder, qbittorrent rejects the file. When I add torrents from other trackers, it works perfectly fine. When I try to open a .torrent file manually that Jackett placed in the Blackhole folder, I get a bencoding error. Downloading torrent files directly from RARBG are working perfectly fine for me though. I have no other issues with Jackett and magnet links work well.
Jackett v 0.10.692.0
Windows Server 2016
Caddy Webserver (but issue happens on 127.0.0.1 also)
Have the same issue with Sonarr. Grabbing via Sonarr gives an error, doing it manually within Jackett is fine.
The only logs I have are 2 errors:
Error downloading rarbg https://torrentapi.org/redirect_to_info.php?token=c7gek5xunj&p=1_7_5_5_1_3_1__693d977b3a
and
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <meta name="theme-color" content="#3860BB" /> </head> <body> <script type="text/javascript" src="https://dyncdn.me/static/20/js/jquery-1.11.3.min.js"></script><style type="text/css">a,abbr,acronym,address,applet,article,aside,audio,b,big,blockquote,body,canvas,caption,center,cite,code,dd,del,details,dfn,div,dl,dt,em,fieldset,figcaption,figure,footer,form,h1,h2,h3,h4,h5,h6,header,hgroup,html,i,iframe,img,ins,kbd,label,legend,li,mark,menu,nav,object,ol,p,pre,q,s,samp,section,small,span,strike,strong,sub,summary,sup,table,tbody,td,tfoot,th,thead,time,tr,tt,u,ul,var,video{margin:0;padding:0;border:0;outline:0;font:inherit;vertical-align:baseline}article,aside,details,figcaption,figure,footer,header,hgroup,menu,nav,section{display:block}body{line-height:1}ol,ul{list-style:none}blockquote,q{quotes:none}blockquote:after,blockquote:before,q:after,q:before{content:'';content:none}ins{text-decoration:none}del{text-decoration:line-through}table{border-collapse:collapse;border-spacing:0} body { background: #000 url("https://dyncdn.me/static/20/img/bknd_body.jpg") repeat-x scroll 0 0 !important; font: 400 8pt normal Tahoma,Verdana,Arial,Arial !important; } .button { background-color: #3860bb; border: none; color: white; padding: 15px 32px; text-align: center; text-decoration: none; display: inline-block; font-size: 16px; cursor: pointer; text-transform: none; overflow: visible; } .content-rounded { background: #fff none repeat scroll 0 0 !important; border-radius: 3px; color: #000 !important; padding: 20px; width:961px; } </style><div align="center" style="margin-top:20px;padding-top:20px;color: #000 !important;"> <div class="content-rounded" style="color: #000 !important;"> <img src="https://dyncdn.me/static/20/img/logo_dark_nodomain2_optimized.png"><br/> Please wait while we try to verify your browser...<br/> <div style="font-weight: bold"><b>Please don't change tabs / minimize your browser or the process will fail</b></div><br/> If you are stuck on this page disable your browser addons<br/><img src="https://dyncdn.me/static/20/img/loading_flat.gif"> </div> </div> <script> var w = window.innerWidth \|\| document.documentElement.clientWidth \|\| document.body.clientWidth; var h = window.innerHeight \|\| document.documentElement.clientHeight \|\| document.body.clientHeight; var days = 7; var date = new Date(); var name = 'sk'; var value_sk = 'uint2rqofx'; var value_c = '15161993'; var value_i = '1025898922'; date.setTime(date.getTime()+(days*24*60*60*1000)); var expires = ";expires="+date.toGMTString(); document.cookie = name+"="+value_sk+expires+"; path=/"; if(w < 100 \|\| h < 100) { window.location.href = "/threat_defence.php?defence=nojc&r=15586568"; } else { if(!document.domain) { var ref_cookie = ''; } else { var ref_cookie = document.domain; } $.ajax({type: 'GET',url: '/threat_defence_ajax.php?sk='+value_sk+'&cid='+value_c+'&i='+value_i+'&r=65151416',contentType: 'text/plain', async: true, timeout: 3000, cache: false }); setTimeout(function(){ window.location.href = "/threat_defence.php?defence=2&sk="+value_sk+"&cid="+value_c+"&i="+value_i+"&ref_cookie="+ref_cookie+"&r=53133944"; }, 5500); }
</script>
(Seems to be a parse error ?, but manually it's working..)
I have always the same 2 errors when trying to grab a torrent from Sonarr.
Here are also the DEBUG infos just after the errors.
Feb 02, 2019 12:30:24 PM | Info | Request finished in 4490.5743ms 404
Feb 02, 2019 12:30:24 PM | Info | Executed action Jackett.Server.Controllers.DownloadController.Download (JackettConsole) in 4486.2949ms
Feb 02, 2019 12:30:24 PM | Info | Executing HttpStatusCodeResult, setting HTTP status code 404
Feb 02, 2019 12:30:24 PM | Info | Executed action method Jackett.Server.Controllers.DownloadController.Download (JackettConsole), returned result Microsoft.AspNetCore.Mvc.NotFoundResult in 4479.0286ms.
I also can't get recent stuff from RARBG. My error is torrent file is empty. I had a similar issue a few months back, due to Jackett not scraping RARBG but instead using https://torrentapi.org/. Seems it's doing so again.
I see RARBG has sorted this in a closed issue.
As you may know, Jackett's RarBG indexer uses the RarBG API to fetch results, since it's prohibited from using the RarBG WEB site via web page scraping methods.
When the RarBG API returns results for a torrent search, it provides a direct download link from the WEB RarBG site for each torrent found.
So when you use a download link you in effect attempt to access the RarBG WEB site at this point.
However, for your IP block in your region, RarBG WEB is invoking cloudflare DDOS protection checking.
The cloudflare DDOS page is interfering with your blackhole directory dump, and the other users Sonarr grab.
Instead of getting a .torrent data file, you are getting the cloundflare DDOS HTML page, and hence the bencoding error.
Don't know if there is anything we can do about this from the Jackett side of the process,
@kaso17 any ideas?
Is the DDos protection from RarBG a new feature ? It worked like a charm for the last few months..
generally sites only invoke cloudflare DDOS protection after their site have come under some form of DDOS attack.
And world wide, indiscriminate DDOS attacks are increasingly more common, so more and more sites are opting to seek relief by using cloudflare services.
The cloudflare DDOS protection usually applies to IP blocks that cloudflare determine are the source of the attacks.
So if you are unlucky enough to have an IP address that falls within the black listed IP range, then you get the cloudflare challenge.
Some time after the attacks stop, cloudflare drop the black list and access is allows without challenge again.
The same error that @minitoine described is happening to me on qbittorrent.
Qbittorrent can get the RSS feeds just fine from Jackett, but when downloading the torrents (as @garfield69 said) qbittorrent has to access RARBG鈥檚 WEB and that's when I get the error.
When I first noticed this behavior I searched for the torrents directly in Jackett's WEBUI, and one thing that I noticed is that when trying to download the torrent file it's indeed is not possible (since it is accessing RARBG's WEB), but on the other hand the magnet link works just fine (if I copy it into qbittorrent the download starts right away).
With that being said, it seems to me that a solution to this problem would be to configure Jackett to return magnet links for the RARBG RSS feed, instead of links to RARBG's WEB .torrent file. Is that currently possible?
yes its possible. we could add to the rarbg indexer config an option to make the magnet the default download-link instead of the .torrent.
but we will have to wait for @kaso17 or another c# coder to implement, as its beyond my limited c# skills.
yes its possible. we could add to the rarbg indexer config an option to make the magnet the default download-link instead of the .torrent.
but we will have to wait for @kaso17 or another c# coder to implement, as its beyond my limited c# skills.
That would be awesome.
Notice us @kaso17 :)
Here are logs from the click on blackhole download to the succesful download of the torrent file. But the .torrent file is considered as invalid.
Feb 15, 2019 03:58:28 PM | Debug |
WebClient(HttpWebClient): Returning OK => 3311 bytes
Feb 15, 2019 03:58:26 PM | Debug |
WebClient(HttpWebClient): delaying request for https://rarbg.to/threat_defence.php?defence=1&r=40540307 by 2.099086 seconds
Feb 15, 2019 03:58:26 PM | Debug |
WebClient(HttpWebClient).GetBytes(Url:https://rarbg.to/threat_defence.php?defence=1&r=40540307)
Feb 15, 2019 03:58:26 PM | Debug |
WebClient(HttpWebClient): Returning Redirect => https://rarbg.to/threat_defence.php?defence=1&r=40540307 0 bytes
Feb 15, 2019 03:58:26 PM | Debug |
[MONO relative redirect bug] Rewriting relative redirect URL from file:///threat_defence.php%3Fdefence=1&r=40540307 to https://rarbg.to/threat_defence.php?defence=1&r=40540307
Feb 15, 2019 03:58:23 PM | Debug |
WebClient(HttpWebClient): delaying request for https://rarbg.to/download.php?id=5gs7zj9&f=jackett.torrent by 2.094316 seconds
Feb 15, 2019 03:58:23 PM | Debug |
WebClient(HttpWebClient).GetBytes(Url:https://rarbg.to/download.php?id=5gs7zj9&f=jackett.torrent)
Feb 15, 2019 03:58:23 PM | Debug |
WebClient(HttpWebClient): Returning Redirect => https://rarbg.to/torrent/5gs7zj9
Feb 15, 2019 03:58:23 PM | Debug |
WebClient(HttpWebClient).GetString(Url:https://torrentapi.org/redirect_to_info.php?token=z0y8jkxuhe&p=1_7_6_3_4_9_3__e786b989bf)
Feb 15, 2019 03:58:23 PM | Info |
Executing action method Jackett.Server.Controllers.BlackholeController.Blackhole (JackettConsole) with arguments (rarbg, Q2ZESjhCUkRxVlV5V1FOQXVkQ1ZTUkJqejRZdk5talZEeWNxMUVQam9mdUpFT2RSQkx5SFRYOTVtTTl5M0h4UXhPa0FpU2RNNlBCeXJBc01TQ294ekFORUY4ZVB3VkZnUUFCRllzQTZ3cGkzUUZWb3Y4MWthd3pSMUZGd0g1S2xvNmhicTgxeWxhaHBIZWxWSXNQWXM5NWd1ZjNUMUl0U2hyeFB0bmVxcDAtZUxVOHIzTncwTHREZmJuZm4zZVRpNWtGOHdIZmQxLVh5WF9rOGpkRTRIYThIVU9RSXk0Y1d3Wkl6WUJDTHg3WGhlbmth, dr1aeadqq7zvkz44kxpx8jzrd963e4zd, American.Dad.S14E14.1080p.WEBRip.x264-TBS[rartv]) - Validation state: Valid
Jackett is definitely getting bytes from the protection webpage.
Shouldn't it be possible to wait for the protection to finish to get the actual real torrent content wanted ?
From what I understand, it is not that simple, because you download the torrent bytes directly from the website, and the protection is about doing a CAPTCHA.. right ?
fixed via ad77068a7b5ece2291c125fb7ed756757618878d (default to magnet now)
Most helpful comment
fixed via ad77068a7b5ece2291c125fb7ed756757618878d (default to magnet now)