i’ve just noticed rarbg is available, but i’m having trouble getting it tested and added - mainly because in the UK, it’s blocked so it needs a proxy.
the log file error is “Unable to connect to indexer: Error: SendFailure (Error writing headers): Error: SendFailure (Error writing headers)”
if anyone has any clues i’d be grateful, thanks
Works for me in the UK, I just left all settings as default.
still doesn’t with me - just tried it again and get “Unable to connect to indexer, check the log for more details” which gives the log error above - i’m on sky broadband if that helps.
Thats an SSL error, make sure libcurl is available on your system so Sonarr can fallback to that.
thanks for the reply. i’ve got a synology nas drive that runs sonarr at the moment, but i wouldn’t have the faintest idea on how to get libcurl installed or working so i’ll see what google has to suggest.
not having a lot of luck figuring out libcurl - if anyone has any clues or tips i’d be very grateful, thanks
Haven’t gotten RarBG to work yet, but here’s a quick how-to on how to install libcurl (and other packages).
Download the appropriate bootstrap file to a folder on your Synology box.
Find a suitable IPKG bootstrap here: http://www.synology-wiki.de/index.php/Welchen_Prozessortyp_besitzt_mein_System%3F
Put the file on your synology in an accessable folder through the web interface (or SSH).
SSH or Telnet into the Synology Box and login as root
Go to the directory containing the bootstrap file, for example “cd /volume1/downloads/”
Install bootstrap file, type “sh syno” and hit “tab” to fill out the rest of the filename.
Change the path settings in “/etc/profile” and “/root/.profile” to include “/opt/bin” and “/opt/sbin”. For example:
“PATH=/opt/bin:/opt/sbin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/syno/sbin:/usr/syno/bin:/usr/local/sbin:/usr/local/bin”
Log out of the SSH session and start a new session.
Give the command “ipkg install libcurl”
This will install libcurl - 7.24.0-1 - Curl is a command line tool for transferring files with URL syntax, supporting FTP, FTPS, HTTP, HTTPS, GOPHER, TELNET, DICT, FI
I still end up with:
15-7-22 12:29:40.6|Trace|HttpClient|Req: [GET] https://torrentapi.org/pubapi_v2.php?get_token=get_token
15-7-22 12:29:40.6|Trace|HttpClient|Curl not available, using default WebClient.
To validate libcurl install:
Synology> curl-config --version
libcurl 7.24.0
Since you are basically doing a “clean” install, you might want to try installing Entware instead of Optware.
Entware contains libcurl 7.40 which is significantly newer then the one Optware has.
http://forum.synology.com/enu/viewtopic.php?f=40&t=95346&hilit=libcurl
I’m going to give that a try later, to see if that helps.
Edit: I end up with the same result:
15-7-22 13:44:29.9|Trace|HttpClient|Req: [GET] https://torrentapi.org/pubapi_v2.php?get_token=get_token
15-7-22 13:44:29.9|Trace|HttpClient|Curl not available, using default WebClient.
Synology> curl --version
curl 7.40.0 (i686-openwrt-linux-gnu) libcurl/7.40.0 OpenSSL/1.0.2a zlib/1.2.8
Protocols: file ftp ftps http https imap imaps pop3 pop3s rtsp smtp smtps tftp
Features: IPv6 Largefile SSL libz
Sometimes the work-around is so simple you don’t even think about it. The API also works on http, so you can just change the url into http://torrentapi.org
you sir are a genius and clearly a great success with the ladies 
works perfectly - tested and saved. thanks!
Same issue here, but I am on QNAP. I have Qnapware (a port of Entware) and installed libcurl. The version I have is 7.40.0-3. Rarbg cannot be added.
That’s because sonarr can’t find the libcurl library.
I think we might have been looking at it wrong. To run Sonarr on Synology and QNAP you resp. need Mono or QMono. What we have done with Optware/Entware is enabling curl / libcurl in the NAS layer, but possibly not in the Mono layer.
So I think the resolution direction would be to try and validate if and which libcurl is part of Mono and QMono.
Edit: On the mono forum they talked about first checking it in the NAS layer. This results in:
curl https://torrentapi.org/
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: http://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a “bundle” of Certificate Authority (CA) public keys (CA certs). If the default bundle file isn’t adequate, you can specify an alternate file using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in the bundle, the certificate verification probably failed due to a problem with the certificate (it might be expired, or the name might not match the domain name in the URL).
If you’d like to turn off curl’s verification of the certificate, use the -k (or --insecure) option.
Mono doesn’t use libcurl, Sonarr does. As I said, sonarr can’t find the libcurl library or fails to initialise it as evident by
15-7-22 13:44:29.9|Trace|HttpClient|Curl not available, using default WebClient.
Sonarr has a dllmap entry for the various platforms, this might not be correct for syno:
See https://github.com/Sonarr/Sonarr/blob/develop/src/NzbDrone.Common/CurlSharp.dll.config for the map.
since syno is linux it will be looking for libcurl.so.3
I tried buzz our synology expert on IRC yesterday, no luck so lets try… @maxrogers this.
Max also made the mono package available on SynoCommunity, so if he can take a look at it, that would be great.
I was looking at this forum thread on the mono boards:
http://mono.1490590.n4.nabble.com/Problem-with-mono-and-HtttpWebRequest-ssl-td4666196.html#a4666211
In the standard /lib I have the following libcurl versions:
libcurl.so
libcurl.so.4
libcurl.so.4.3.0
/var/packages/nzbdrone/target/lib doesn’t contain any libcurl.
I might be poluting the thread, and will delete the useless posts later…
Changing /var/packages/nzbdrone/target/share/NzbDrone/CurlSharp.dll.config
to does not fix the issues.
Same after copying libcurl.so.4 into /var/packages/nzbdrone/target/lib
If I try a different URL like “https://google.com” I will get different errors then when I try “https://torrentapi.org/tetetsts/”.
This might be due to the certificate of torrentapi to be signed with “SHA256withECDSA” which supposedly isn’t supported by mono.
http://mono.1490590.n4.nabble.com/ECDSA-support-td4665908.html
Did you restart sonarr afterwards? If I change that file to <dllmap os="linux" dll="libcurl.dll" target="libcurl.so.4" /> (libcurl.so.4 instead of .so.3) on my ubuntu machine it works.
Why do you think I added libcurl as fallback in the first place? 
I’m having similar RARGB issues on OS X (10.7.5) as it’s using an older version of curl:
$ curl --version
curl 7.21.4 (universal-apple-darwin11.0) libcurl/7.21.4 OpenSSL/0.9.8z zlib/1.2.5
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smtp smtps telnet tftp
Features: AsynchDNS GSS-Negotiate IPv6 Largefile NTLM SSL libz
which fails even just on the command line:
$ curl https://torrentapi.org/pubapi_v2.php?get_token=get_token
curl: (35) error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
Installing the latest via homebrew gives me a working command line version (if I specify that binary), but doesn’t fix the issue, presumably because…
==> Caveats
This formula is keg-only, which means it was not symlinked into /usr/local.
OS X already provides this software and installing another version in
parallel can cause all kinds of trouble.
Generally there are no consequences of this for you. If you build your
own software and it requires this formula, you’ll need to add to your
build variables:
LDFLAGS: -L/usr/local/opt/curl/lib
CPPFLAGS: -I/usr/local/opt/curl/include
So, is there a way to specify /usr/local/opt/curl/lib/libcurl.4.dylib ? For example, changing CurlSharp.dll.config to include <dllmap os=“osx” dll=“libcurl.dll” target="/usr/local/opt/curl/lib/libcurl.4.dylib"/> didn’t solve this for me, even after a sonarr restart.
That would imply me actually understanding this stuff. My knowlegde only comes from google and common sense. Of which the common sense is debatable 
I did reboot sonarr after the change, I even rebooted the entire NAS just to be sure.
I noticed 4.0 is a symlink to 4.3.0, so retried it (entire NAS reboot) with 4.3.0 in all to options. Same result.
Tracelog:
http://pastebin.com/3SH7BKVT