Package Details: sonarr 4.0.4.1491-1

Git Clone URL: https://aur.archlinux.org/sonarr.git (read-only, click to copy)
Package Base: sonarr
Description: TV download automation for usenet and torrents.
Upstream URL: https://sonarr.tv/
Licenses: GPL3
Submitter: justin8
Maintainer: degeberg (fryfrog)
Last Packager: fryfrog
Votes: 99
Popularity: 0.44
First Submitted: 2014-11-10 04:45 (UTC)
Last Updated: 2024-04-13 18:56 (UTC)

Dependencies (12)

Required by (11)

Sources (7)

Pinned Comments

fryfrog commented on 2021-06-27 16:05 (UTC) (edited on 2023-12-29 23:28 (UTC) by fryfrog)

If you're interested in the develop branch, see sonarr-develop.

Support: Discord, /r/sonarr, forums or irc.

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 9 10 .. 15 Next › Last »

degeberg commented on 2017-08-21 08:41 (UTC)

That is a known bug (https://github.com/Sonarr/Sonarr/issues/1928). I think it depends on the particular SSL/TLS parameters used to establish connections. At least that would explain why some people experience it and others don't.

Denzo commented on 2017-08-21 08:13 (UTC) (edited on 2017-08-21 08:14 (UTC) by Denzo)

With the Environment=MONO_TLS_PROVIDER=legacy line removed, Sonarr crashes whenever it sends a torrent to Transmission. Now that I've re-added the line, it no longer crashes. Anyone else experiencing this?

<deleted-account> commented on 2017-07-28 20:31 (UTC)

@springer Same here, I removed this line and no problems meanwhile.

springer commented on 2017-07-19 11:06 (UTC)

Were there any recent changes that fixed the mono TLS related problem? I just removed the MONO_TLS_PROVIDER line from the startup script and Sonarr seems to be up and running. Can someone else test it as well? This is from my Sonarr > System page """ Health No issues with your configuration About Version 2.0.0.4855 Mono Version 5.0.0 AppData directory /var/lib/sonarr Startup directory /usr/lib/sonarr """

smmalis37 commented on 2017-07-07 18:17 (UTC)

The devs and I have been debugging this issue. For now, legacy is still needed despite the health check (we thought it was fixed but it wasn't). I have filed https://bugs.archlinux.org/task/54738 since this seems to be a bug in mono.

<deleted-account> commented on 2017-07-07 10:57 (UTC)

Hi @degeberg. Is it possible to include the "MONO_TLS_PROVIDER=legacy" as on option in the systemd service file (where it can be easily overriden) instead of in the sonarr.sh file? So adding this to sonarr.service (under the [Service] tag): "Environment=MONO_TLS_PROVIDER=legacy" Just commented out the option in sonarr.sh and it doesn't seem to affect sonarr at all in my install.

degeberg commented on 2017-07-05 04:56 (UTC)

I've switched it back to legacy.

degeberg commented on 2017-07-05 04:30 (UTC) (edited on 2017-07-05 04:30 (UTC) by degeberg)

Hmm... the commit in https://github.com/Sonarr/Sonarr/commit/11926d8b2dfa30d2ed0f1a1579e6fa110a02462a adds a health check saying that it will work with mono >= 5.0.0 using btls.

drrlvn commented on 2017-07-04 21:42 (UTC)

Latest version (2.0.0.4855-1) crashes with a stacktrace involving boringtls. Maybe legacy TLS provider is still needed?

degeberg commented on 2017-05-15 06:27 (UTC)

The /usr/bin/sonarr is a matter of preference although it strictly is not necessary. I just prefer having an executable in /usr/bin for non-library packages. Seeing as it execs, it shouldn't make a difference to what actually ends up running. People can use a systemd override if they don't want to use it. I actually forgot about your previous comment about sysusers. I'll have a look at it after work later today.

« First ‹ Previous 1 2 3 4 5 6 7 8 9 10 .. 15 Next › Last »