Setting up rarbg as an indexer?

Help & Support
#21

Synology devices don’t have libcurl.so.3 available in /lib. (libcurl.so.4.3.0 is the main file, libcurl.so.4, libcurl.so are the available symlinks)

Creating a symlink (from /lib/libcurl.so.4.3.0 > lib/libcurl.so.3) works, but that’s not feasible for us (system libs, not retained after DSM updates). If we package curl along with Sonarr, the file and symlinks have the same name as above.

So, would it be possible to add a fallback to libcurl.so in there? The only other alternative I can see is that we package curl, create our own symlink for .3 within the Sonarr package, and see if we can tell Sonarr to look there.
/edit: Might be just as easy to patch Sonarr during packaging to change the target, so that’s another way to fix it.

#22

But then the edit of dllmap os=“linux” dll=“libcurl.dll” target=“libcurl.so.4.3.0” should work, and I’m still not getting it up and running.
I did notice libcurl.dll is nowhere to be found on my synology.

Is there anything I can “ldd” against to see if all the required packages are available?

#23

That’s because that’s the windows dll name that the dllmap is supposed to translate to libcurl.so.x :wink:

Remove the os="linux" part, try <dllmap dll="libcurl.dll" target="libcurl.so.4" />.

#24

Same result. The linux qualifier already seemed to be valid, because alterations were shown in the exception.

15-7-23 20:33:01.1|Trace|CurlHttpClient|Initializing curl failed

System.DllNotFoundException: libcurl.so.4.3.0
at (wrapper managed-to-native) CurlSharp.NativeMethods:curl_global_init (int)
at CurlSharp.Curl.GlobalInit (CurlInitFlag flags) [0x00000] in m:\BuildAgent\work\6c3239faf2b92630\src\ExternalModules\CurlSharp\CurlSharp\Curl.cs:75
at NzbDrone.Common.Http.CurlGlobalHandle.Initialize () [0x00028] in m:\BuildAgent\work\6c3239faf2b92630\src\NzbDrone.Common\Http\CurlHttpClient.cs:224
at NzbDrone.Common.Http.CurlHttpClient.CheckAvailability () [0x00000] in m:\BuildAgent\work\6c3239faf2b92630\src\NzbDrone.Common\Http\CurlHttpClient.cs:32

and

15-7-23 20:37:25.5|Debug|HttpClient|https request failed in tls error for torrentapi.org, trying curl fallback.
15-7-23 20:37:25.6|Trace|CurlHttpClient|Initializing curl failed
System.DllNotFoundException: libcurl.so.4
at (wrapper managed-to-native) CurlSharp.NativeMethods:curl_global_init (int)
at CurlSharp.Curl.GlobalInit (CurlInitFlag flags) [0x00000] in m:\BuildAgent\work\6c3239faf2b92630\src\ExternalModules\CurlSharp\CurlSharp\Curl.cs:75
at NzbDrone.Common.Http.CurlGlobalHandle.Initialize () [0x00028] in m:\BuildAgent\work\6c3239faf2b92630\src\NzbDrone.Common\Http\CurlHttpClient.cs:224
at NzbDrone.Common.Http.CurlHttpClient.CheckAvailability () [0x00000] in m:\BuildAgent\work\6c3239faf2b92630\src\NzbDrone.Common\Http\CurlHttpClient.cs:32

#25

@Mirx_NL I can’t reproduce that. You sure it’s not caused by the optware changes you made earlier, that maybe Sonarr can’t find the correct libs anymore?

@Taloth, let me know if we need to do anything with the package (or, if maxrogers resurfaces, he can handle it ;))

#26

@Dr_Bean So just to be clear, it is working for you on your synology?
What did you do? Did you add a libcurl.so.3 symlink in /lib to rederict to libcurl.so.4.3.0 and leave the CurlSharp.dll.config as is?

#27

Adding the symlink was my first attempt. After I considered that changing CurlShapr.dll.config file was probably easier than adding a dependency to the package, I tried that too. Either way works, as it’s essentially the same thing.

And just to be sure it’s not a fluke on the device I’m testing on, I’m going to test it on a second device too :wink:

#28

@Dr_Bean No tnx, I’ll probably just change the reference to .so.4 since they’re largely compatible.

Just waiting for @Mirx_NL to figure out why it’s not working on his end.

And probably gotta get the osx dylib and include it like we do with libmediainfo.

#29

@Mirx_NL, what model Synology are you working with? Did a quick test on an x64-based model, and it seems I can reproduce your issue.
The one I was testing with previously was ARM-based, and that one does work. I don’t know exactly which paths Sonarr would search for the file, but there may be a relationship there.

#30

I tried the symlink with original CurlSharp.dll.config.
Still not working. Gonna try and deinstall the optware / entware package and reboot the NAS.

#31

@Dr_Bean I’m on a DS-412+ which has an Intel Atom x86-64

#32

After deinstalling Curl and libcurl from Entware (can’t remove it from Optware as git requires it) it still the same.
And as a simpleton, I also tried adding a symlink in lib64, but that also didn’t help.

#33

Run sonarr with MONO_LOG_LEVEL=debug MONO_LOG_MASK=dll,cfg mono --debug /../../NzbDrone.exe in the console, preferably in something with a reasonably large buffer so you can scroll back, or log to file.

#34

Here you go:

Also, I cross-compiled curl into the package. The error changes to Curl Error SslCaCert for Url. That’s probably because we (currently) don’t specify a CA bundle with OpenSSL. That’s something I’ve been considering for other reasons, but hadn’t done yet.
I’ll look into that in a bit more detail, maybe next week.

#35

@Dr_Bean Glad you understood what Taloth meant, I was just getting fatal erros on my screen :blush:

#36

I actually expected it to try a couple of different paths.

#37

Well, to be clear, the package uses this to start Sonarr: https://github.com/SynoCommunity/spksrc/blob/master/spk/sonarr/src/dsm-control.sh#L17

So I ended up with this: env PATH=/usr/local/mono/bin:$PATH LD_LIBRARY_PATH=/usr/local/nzbdrone/lib MONO_LOG_LEVEL=debug MONO_LOG_MASK=dll,cfg /usr/local/mono/bin/mono --debug /usr/local/nzbdrone/share/NzbD rone/NzbDrone.exe

After cross-compiling libcurl into the package, it ends up in /usr/local/nzbdrone/lib, and that’s searched too…it doesn’t show up here though (removed it to test properly)

#38

I tried making a symlink in /volume1/@appstore/nzbdrone/share/NzbDrone/ to /lib.
That didn’t seem to help.

#39

Ok, this is what I was looking for. I created a symlink to /lib/libcurl.so.4.3.0, and ran the command again, with the following result:

Mono: DllImport error loading library '/volume1/@appstore/nzbdrone/share/NzbDrone/libcurl.so.4': '/volume1/@appstore/nzbdrone/share/NzbDrone/libcurl.so.4: wrong ELF class: ELFCLASS32'.

Fyi, Synology uses a lot of 32b libs on the 64b-based models, and not a lot of 64b libs are available.
Usually, not a problem. However, we do compile Sonarr with a 64b toolchain…

With the 64b libcurl added in, the ELF class error disappears, and the CA-cert error comes back. So that will probably be the direction to go.

[Jackett] Additional torrent trackers for Sonarr
#40

that’s actually interesting coz normally we run sonarr 32bit. Edit: … on windows.

Anyway, if you or maximus can fix the x64 package I’ll change the dllmap to libcurl.so.4 and get that to our develop branch.