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.
Search Criteria
Package Details: sonarr 4.0.4.1491-1
Package Actions
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.28 |
First Submitted: | 2014-11-10 04:45 (UTC) |
Last Updated: | 2024-04-13 18:56 (UTC) |
Dependencies (12)
- sqlite (sqlite-fossilAUR)
- deluge (deluge-gitAUR) (optional) – torrent downloader
- jackettAUR (jackett-monoAUR, jackett-binAUR) (optional) – torrent indexer proxy
- nzbget (nzbget-gitAUR) (optional) – usenet downloader
- nzbhydra2AUR (nzbhydra2-binAUR, nzbhydra2-nojava-binAUR) (optional) – torznab and usenet indexer proxy
- prowlarrAUR (prowlarr-developAUR, prowlarr-nightlyAUR) (optional) – torrent and usenet indexer proxy
- qbittorrent (qbittorrent-dark-gitAUR, qbittorrent-gitAUR, qbittorrent-qt5AUR, qbittorrent-enhanced-gitAUR, qbittorrent-enhanced-uaAUR, qbittorrent-enhancedAUR, qbittorrent-enhanced-qt5AUR, qbittorrent-libtorrent-v1AUR) (optional) – torrent downloader
- rtorrent (rtorrent-colorAUR, rtorrent-pyro-gitAUR, rtorrent-psAUR, rtorrent-ps-chAUR, rtorrent-vi-colorAUR, rtorrent-gitAUR, rtorrent-ipv6AUR) (optional) – torrent downloader
- sabnzbdAUR (sabnzbd-gitAUR) (optional) – usenet downloader
- transmission-cli (transmission-sequential-cliAUR, transmission-noxunlei-cliAUR, transmission-cli-gitAUR, transmission3-cliAUR) (optional) – torrent downloader (CLI and daemon)
- transmission-gtk (transmission-csd-gitAUR, transmission-sequential-gtkAUR, transmission-gtk3AUR, transmission-noxunlei-gtkAUR, transmission-gtk-gitAUR) (optional) – torrent downloader (GTK+)
- transmission-qt (transmission-qt-gitAUR, transmission-sequential-qtAUR, transmission-qt-ssl-gitAUR, transmission-noxunlei-qtAUR) (optional) – torrent downloader (Qt)
Required by (11)
- autobrr (optional)
- nzbget-ppscript-nzbtomedia-git (optional)
- ombi (optional)
- ombi-develop (optional)
- prowlarr (optional)
- prowlarr-develop (optional)
- prowlarr-nightly (optional)
- recyclarr (optional)
- sonarr-runit
- traktarr (optional)
- traktarr-git (optional)
Sources (7)
- http://github.com/Sonarr/Sonarr/releases/download/v4.0.4.1491/Sonarr.main.4.0.4.1491.linux-arm.tar.gz
- http://github.com/Sonarr/Sonarr/releases/download/v4.0.4.1491/Sonarr.main.4.0.4.1491.linux-arm64.tar.gz
- http://github.com/Sonarr/Sonarr/releases/download/v4.0.4.1491/Sonarr.main.4.0.4.1491.linux-x64.tar.gz
- package_info
- sonarr.service
- sonarr.sysusers
- sonarr.tmpfiles
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)
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.
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.