Package Details: sonarr

Git Clone URL: (read-only, click to copy)
Package Base: sonarr
Description: TV download automation for usenet and torrents.
Upstream URL:
Licenses: GPL3
Submitter: justin8
Maintainer: degeberg (fryfrog)
Last Packager: fryfrog
Votes: 90
Popularity: 0.78
First Submitted: 2014-11-10 04:45 (UTC)
Last Updated: 2022-04-25 01:18 (UTC)

Pinned Comments

fryfrog commented on 2021-06-27 16:05 (UTC)

Sonarr support: Discord, /r/sonarr, forums or irc.

Latest Comments

ringo commented on 2022-04-24 10:08 (UTC) (edited on 2022-04-24 10:09 (UTC) by ringo)

Since it mistakenly go flagged Out-of-Date weeks ago, I'd just like to point out here that version 3.0.8 is out now.

fryfrog commented on 2022-04-06 20:17 (UTC)

@ringo: Someone mistakenly flagged it out of date, but no matter how many times I click "Unflag package", it does not unflag. Maybe only @vilerage can do that? :(

ringo commented on 2022-04-06 13:29 (UTC)

Why is this flagged out of date? It is up-to-date.

fryfrog commented on 2021-10-15 16:59 (UTC) (edited on 2021-10-15 17:08 (UTC) by fryfrog)

@eNV25: That doesn't sound crazy, is there any benefit besides tagging in syslog w/ "sonarr"? If I do this for sonarr, I'd probably do it for all the packages I manage... but I've never really run into a need for this, so I'm curious.

You can also always use an override.

Edit: Ah, I think I get it. Since this service runs mono, I bet in syslog it is showing up as mono instead of sonarr.

eNV25 commented on 2021-10-15 14:18 (UTC)

Can you put this in the service file:


fryfrog commented on 2021-06-27 16:05 (UTC)

Sonarr support: Discord, /r/sonarr, forums or irc.

fryfrog commented on 2021-06-27 16:02 (UTC)

@nixit: For sonarr support, check out their Discord, sub-reddit and/or forums.

nixit commented on 2021-06-27 03:07 (UTC)

updated sonarr today, and now when I go to localhost:8989, nothing displays. I stop and started sonarr.service, made sure it's running, yet I can't get the interface to load.

anyone else seeing this?

anonfunc commented on 2021-06-26 23:30 (UTC) (edited on 2021-06-26 23:32 (UTC) by anonfunc)

Assuming nuget and mono-msbuild packages exist, we can probably do 'x86_64' 'aarch64' 'armv7h' for arch right?

I would assume so.

Also, what does your version end up as? I believe their build system spits out 10.x versions for self compiled, unless you do something like what the jacket package does.

It does list "Version" in System -> Status. So I still need to fix that.

And to be clear, I should not switch to this until a newer version of mono comes along? I'm not groking what you mean there. :)

Yes, I tested with mono, so probably >= then.

fryfrog commented on 2021-06-26 23:18 (UTC)

Also, what does your version end up as? I believe their build system spits out 10.x versions for self compiled, unless you do something like what the jacket package does. And to be clear, I should not switch to this until a newer version of mono comes along? I'm not groking what you mean there. :)

fryfrog commented on 2021-06-26 23:15 (UTC)

Assuming nuget and mono-msbuild packages exist, we can probably do 'x86_64' 'aarch64' 'armv7h' for arch right?

anonfunc commented on 2021-06-26 22:35 (UTC) (edited on 2021-06-27 09:13 (UTC) by anonfunc)

@fryfrog We are currently blocked by FS#71007, which prevents sonarr from successfully building with msbuild. I have tested this patch with mono, which works flawlessly.

I want to test a clean chroot again (for possibly missing deps) once mono got a new release out, otherwise this patch works, I tested sonarr in action on my machine and had no problems so far.

diff --git a/PKGBUILD b/PKGBUILD
index 2812b4f..9d3af69 100644
@@ -3,20 +3,18 @@
 # Contributor: Justin Dray <>
 # Helpful URL:

 pkgdesc='TV download automation for usenet and torrents.'
   'sabnzbd: usenet downloader'
   'nzbget: usenet downloader'
@@ -27,26 +25,44 @@ optdepends=(
   'rtorrent: torrent downloader'
   'jackett: torrent indexer proxy'
+  'nuget'
+  'mono-msbuild'

-  "${pkgver}/Sonarr.main.${pkgver}.linux.tar.gz"
+  "$pkgver.tar.gz"


+build() {
+  cd "$srcdir/Sonarr-$pkgver"
+  nuget restore src/Sonarr.sln
+  msbuild src/Sonarr.sln -p:Configuration=Release -p:Platform=x86 -t:Build -m
+  yarn install
+  yarn run build --env production
 package() {
-  rm -rf "${srcdir}/Sonarr/Sonarr.Update"
+  cd "$srcdir/Sonarr-$pkgver"
+  rm -rf _output/{Sonarr.Update,System.IO.Compression,System.Runtime.InteropServices.RuntimeInformation,System.Net.Http,System.Globalization.Extensions,System.Text.Encoding.CodePages,System.Threading.Overlapped,ServiceInstall.*,ServiceUninstall.*,sqlite3.*,MediaInfo.*,Sonarr.exe*,Sonarr.Windows.*,*.pdb}
+  cp src/NzbDrone.Core/Sonarr.Core.dll.config _output
+  for file in _output/Sonarr.Console.exe*; do
+    mv "$file" "${file//.Console/}"
+  done
   install -d -m 755 "${pkgdir}/usr/lib/sonarr/bin"
-  cp -dpr --no-preserve=ownership "${srcdir}/Sonarr/"* "${pkgdir}/usr/lib/sonarr/bin"
+  cp -dpr --no-preserve=ownership _output/* "${pkgdir}/usr/lib/sonarr/bin"

   # Disable built in updater.
   install -D -m 644 "${srcdir}/package_info" "${pkgdir}/usr/lib/sonarr"

fryfrog commented on 2021-06-23 14:46 (UTC)

@anonfunc: You're totally right, do you understand dotnetcore/mono/.NET build well enough to turn this into a build from source package? The jackett package was the same way, but flipee recently did the hard work of getting it to build from source and so we switched it up to be correct. I don't think it is worth the churn of a package re-name until I can get it to build. I own a number of other packages like this, so if you have that talent we could knock them all out together!

anonfunc commented on 2021-06-23 11:59 (UTC)

Just as a notice, this package is more like sonarr-bin rather then sonarr, since its only delivering prebuild binarys. See for more.

fryfrog commented on 2021-03-08 22:48 (UTC) (edited on 2021-03-08 23:31 (UTC) by fryfrog)

Sonarr has finally released v3. If you need sonarr related help, their discord or /r/sonarr sub-reddit are your best bets. The unstable nightly version is sonarr-develop, but you'll be expected to be technically inclined and help investigate issues you uncover.

fryfrog commented on 2019-08-24 17:44 (UTC)

Is there anyone who uses this package that feels strongly about using it instead of sonarr or sonarr-develop? I've adopted it, but will probably request that it be merged w/ sonarr-develop unless someone very strongly likes it.

fryfrog commented on 2019-04-15 18:34 (UTC)

@degeberg: You can remove systemd-sysusers sonarr.conf from your install file, the pacman hooks take care of it.

You could also do the ownership w/ systemd's tmpfiles instead.

nicoulaj commented on 2018-09-09 16:10 (UTC)

I think the service starts too early at boot, I can see this stack trace:

Sep 09 17:53:29 storm sonarr[852]: [Error] TaskExtensions: Task Error
Sep 09 17:53:29 storm sonarr[852]: [v2.0.0.5228] System.Net.WebException: DNS Name Resolution Failure: ''
Sep 09 17:53:29 storm sonarr[852]:   at NzbDrone.Common.Http.Dispatchers.ManagedHttpDispatcher.GetResponse (NzbDrone.Common.Http.HttpRequest request, System.Net.CookieContainer cookies) [0x0015e] in <8faeb593f49341d6a7a6d2c3c281887c>:0
Sep 09 17:53:29 storm sonarr[852]:   at NzbDrone.Common.Http.Dispatchers.FallbackHttpDispatcher.GetResponse (NzbDrone.Common.Http.HttpRequest request, System.Net.CookieContainer cookies) [0x000b5] in <8faeb593f49341d6a7a6d2c3c281887c>:0
Sep 09 17:53:29 storm sonarr[852]:   at NzbDrone.Common.Http.HttpClient.ExecuteRequest (NzbDrone.Common.Http.HttpRequest request, System.Net.CookieContainer cookieContainer) [0x0007e] in <8faeb593f49341d6a7a6d2c3c281887c>:0
Sep 09 17:53:29 storm sonarr[852]:   at NzbDrone.Common.Http.HttpClient.Execute (NzbDrone.Common.Http.HttpRequest request) [0x00008] in <8faeb593f49341d6a7a6d2c3c281887c>:0
Sep 09 17:53:29 storm sonarr[852]:   at NzbDrone.Common.Http.HttpClient.Get (NzbDrone.Common.Http.HttpRequest request) [0x00007] in <8faeb593f49341d6a7a6d2c3c281887c>:0
Sep 09 17:53:29 storm sonarr[852]:   at NzbDrone.Common.Http.HttpClient.Get[T] (NzbDrone.Common.Http.HttpRequest request) [0x00000] in <8faeb593f49341d6a7a6d2c3c281887c>:0
Sep 09 17:53:29 storm sonarr[852]:   at NzbDrone.Core.Update.UpdatePackageProvider.GetLatestUpdate (System.String branch, System.Version currentVersion) [0x0006c] in <f8c4a2c9e6194b509efc6018724d76df>:0
Sep 09 17:53:29 storm sonarr[852]:   at NzbDrone.Core.Update.CheckUpdateService.AvailableUpdate () [0x00016] in <f8c4a2c9e6194b509efc6018724d76df>:0
Sep 09 17:53:29 storm sonarr[852]:   at NzbDrone.Core.HealthCheck.Checks.UpdateCheck.Check () [0x000f7] in <f8c4a2c9e6194b509efc6018724d76df>:0
Sep 09 17:53:29 storm sonarr[852]:   at NzbDrone.Core.HealthCheck.HealthCheckService+<>c.<PerformHealthCheck>b__11_0 (NzbDrone.Core.HealthCheck.IProvideHealthCheck c) [0x00000] in <f8c4a2c9e6194b509efc6018724d76df>:0
Sep 09 17:53:29 storm sonarr[852]:   at System.Linq.Enumerable+SelectArrayIterator`2[TSource,TResult].ToList () [0x00014] in <55cb1ea97846413983036e5d2581cc09>:0
Sep 09 17:53:29 storm sonarr[852]:   at System.Linq.Enumerable.ToList[TSource] (System.Collections.Generic.IEnumerable`1[T] source) [0x0001f] in <55cb1ea97846413983036e5d2581cc09>:0
Sep 09 17:53:29 storm sonarr[852]:   at NzbDrone.Core.HealthCheck.HealthCheckService.PerformHealthCheck (NzbDrone.Core.HealthCheck.IProvideHealthCheck[] healthChecks) [0x00025] in <f8c4a2c9e6194b509efc6018724d76df>:0
Sep 09 17:53:29 storm sonarr[852]:   at NzbDrone.Core.HealthCheck.HealthCheckService.HandleAsync (NzbDrone.Core.Lifecycle.ApplicationStartedEvent message) [0x00000] in <f8c4a2c9e6194b509efc6018724d76df>:0
Sep 09 17:53:29 storm sonarr[852]:   at NzbDrone.Core.Messaging.Events.EventAggregator+<>c__DisplayClass6_2`1[TEvent].<PublishEvent>b__1 () [0x00035] in <f8c4a2c9e6194b509efc6018724d76df>:0
Sep 09 17:53:29 storm sonarr[852]:   at System.Threading.Tasks.Task.InnerInvoke () [0x0000f] in <815942dd495d4ccc954b977c1d4bee11>:0
Sep 09 17:53:29 storm sonarr[852]:   at System.Threading.Tasks.Task.Execute () [0x00000] in <815942dd495d4ccc954b977c1d4bee11>:0

It is followed by NetworkManager startup traces. I think the correct way is:

degeberg commented on 2018-07-13 04:48 (UTC)

Sure. I've removed the nzbdrone stuff now.

fryfrog commented on 2018-07-12 20:12 (UTC)

@degeberg, the nzbdrone -> sonarr switch was many, many years ago. Have you considered removing that legacy from the package? Punt the upgrade path from the install file, nuke it from provides, conflicts and replaces?

fryfrog commented on 2018-07-12 20:11 (UTC)

@Renvilo, as a QNAP user, why are you asking for help on the Arch Linux AUR?

RenVilo commented on 2018-05-28 21:26 (UTC) (edited on 2018-05-28 21:40 (UTC) by RenVilo)

I'm running a QNAP NAS with QMono, SABNZBD, Sonarr and Radarr. Everything boots up and is fine except that in Sonarr and Radarr I can't add an Indexer to or any other provider. I've tested this from my PC's version and it works fine. I've read that you have to add "Environment=MONO_TLS_PROVIDER=legacy" but I have no idea how to do this and seems Mono vs QMono might have a different file structure. I can't find "sonarr.service" or the path "usr/lib/systemd/system"

Info on my versions:

Sonarr: V2.0.0.5163 QMono: V5.12.0.266 (of TS-X19 but have tried other previous releases of V5. No V4 available) OS: QNAP Version

Please can someone assist.

danch commented on 2018-04-27 17:14 (UTC)

@fryfrog You are right, my bad. For some reason I am on the develop branch.

fryfrog commented on 2018-04-19 02:23 (UTC)

@danch, you must be following the nightly channel or something. This is currently at the latest release on github and my personal instance that is following their stable releases doesn't say there is an update. Should be unflagged.

shining235 commented on 2018-03-20 17:02 (UTC)

@Ronin7z do you start sonarr from a gnome-terminal?

I downgraded ncurses to the last 6.0

drrlvn commented on 2018-03-19 09:10 (UTC)

@strangebrew you shouldn't upgrade through the GUI, wait for the package to be updated (it already is, BTW).

Ronin7z commented on 2018-03-19 05:41 (UTC)

Tried installing through AUR today, got this error when trying to run it

[ronin@Ronin ~]$ sonarr
exception inside UnhandledException handler: The type initializer for 'System.Console' threw an exception.

[ERROR] FATAL UNHANDLED EXCEPTION: System.TypeInitializationException: The type initializer for 'System.Console' threw an exception. ---> System.TypeInitializationException: The type initializer for 'System.ConsoleDriver' threw an exception. ---> System.Exception: Magic number is wrong: 542
  at System.TermInfoReader.ReadHeader (System.Byte[] buffer, System.Int32& position) [0x00028] in <a84b655e5e6a49ee96b338ec792f5580>:0 
  at System.TermInfoReader..ctor (System.String term, System.String filename) [0x0005f] in <a84b655e5e6a49ee96b338ec792f5580>:0 
  at System.TermInfoDriver..ctor (System.String term) [0x00055] in <a84b655e5e6a49ee96b338ec792f5580>:0 
  at System.ConsoleDriver.CreateTermInfoDriver (System.String term) [0x00000] in <a84b655e5e6a49ee96b338ec792f5580>:0 
  at System.ConsoleDriver..cctor () [0x0004d] in <a84b655e5e6a49ee96b338ec792f5580>:0 
   --- End of inner exception stack trace ---
  at System.Console.SetupStreams (System.Text.Encoding inputEncoding, System.Text.Encoding outputEncoding) [0x00007] in <a84b655e5e6a49ee96b338ec792f5580>:0 
  at System.Console..cctor () [0x0008e] in <a84b655e5e6a49ee96b338ec792f5580>:0 
   --- End of inner exception stack trace ---
  at NzbDrone.Common.Instrumentation.GlobalExceptionHandlers.HandleAppDomainException (System.Object sender, System.UnhandledExceptionEventArgs e) [0x0007a] in <6d548036160a49ed8e2657c617163f50>:0 

strangebrew commented on 2018-03-18 15:28 (UTC) (edited on 2018-03-18 15:29 (UTC) by strangebrew)

I had an issue this morning doing an upgrade through the Sonarr GUI. The ownership of the binary directory should be the sonarr user. Here's a quick patch:

sed -i '/chown/ a \        chown -R sonarr: /usr/lib/sonarr' sonarr.install


shining235 commented on 2018-03-03 16:27 (UTC)

I had mono crashes without legacy setting when updating tv shows. That does not happen any more.... and I don't start sonarr over systemd

fryfrog commented on 2018-02-28 07:09 (UTC)

Anyone know if Environment=MONO_TLS_PROVIDER=legacy can be removed from sonarr.service file yet? I've removed it from mine just now and am keeping an eye on it.

fryfrog commented on 2017-11-06 03:44 (UTC) is up in the client, but not on github yet. Maybe they forgot? :)

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

That is a known bug ( 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?

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 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 since this seems to be a bug in mono.

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 file? So adding this to sonarr.service (under the [Service] tag): "Environment=MONO_TLS_PROVIDER=legacy" Just commented out the option in 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 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 ( 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.

fryfrog commented on 2017-05-15 06:00 (UTC)

Maybe someday, get rid of the bash script entirely? It isn't needed. And let systemd manage the user? Patches for it are below. ;)

degeberg commented on 2017-05-15 04:12 (UTC)

I've added MONO_TLS_PROVIDER=legacy as referenced on the issue tracker and on reddit to make it work with mono 5. I'll remove it again when it's no longer needed.

fryfrog commented on 2017-05-15 03:21 (UTC)

Watch out for mono 5.0, it causes problems w/ sonarr and radarr so far. :/

fryfrog commented on 2017-03-08 07:00 (UTC)

And another that switches to systemd's sysusers

fryfrog commented on 2017-03-08 06:51 (UTC)

I'd like to submit for your consideration a git patch to remove the script and just run mono directly from the systemd unit file.

ejstacey commented on 2017-01-30 00:50 (UTC)

@shkercuh: Thanks! I can confirm it builds successfully now w/o the patch.

shkercuh commented on 2017-01-30 00:25 (UTC)

Thanks, @ejstacey. I've fixed the package now.

ejstacey commented on 2017-01-30 00:08 (UTC)

This fails to build with the current sonarr git: -> Patching Mono-Set-process-name error: src/NzbDrone.Mono/EnvironmentInfo/MonoRuntimeProvider.cs: No such file or directory ==> ERROR: A failure occurred in prepare(). Aborting... The build failed. I think the file got changed (renamed?) to MonoPlatformInfo.cs (in that same directory). I am not confident enough around c# to try and adapt the patch.

jack.mitchell commented on 2016-10-30 13:47 (UTC)

Anyone having issues with Sonarr segfaulting/crashing on RSS index with the lastest Mono. I had to role mine back. I do have a custom mono build, but all it does is remove the libgdi dependancy which has never been an issue in the past.

degeberg commented on 2016-10-27 05:06 (UTC)

@Rusk: It doesn't run as debug on my machine. Do you use the mono package from the official repos, or have you compiled your own version?

Rusk commented on 2016-10-26 23:20 (UTC)

Question: How to run sonarr without "--debug" option of mono? $ ps aux | grep mono sonarr 3719 2.0 2.1 1541812 178892 ? Ssl 00:58 0:07 mono --debug /usr/lib/sonarr/NzbDrone.exe -nobrowser -data=/var/lib/sonarr I checked the sonarr.service file: $ cat /usr/lib/systemd/system/sonarr.service [Unit] Description=Sonarr Service [Service] User=sonarr Group=sonarr ExecStart=/usr/bin/sonarr -nobrowser -data=/var/lib/sonarr Type=simple TimeoutStopSec=20 [Install] It is not eluding to any option with which mono is being run. I also wrote a "Hello, World"-Example and let it run in a loop like this: $ watch -n1 hello_world.exe Every 1.0s: ./hello_world.exe current_user: Thu Oct 27 01:13:36 2016 $ ps aux | grep hello_world.exe current_user 4074 0.2 0.0 9120 2900 pts/6 S+ 01:13 0:00 watch -n1 /home/current_user/hello_world.exe As you can see mono is not even being mentioned. Any directions would be greatly appreciated. Also in case this is the wrong place for this question please point me towards another support site.

SRChiP commented on 2016-09-13 10:08 (UTC)

@moonman I think it would be easier to just create a systemd unit override. :) $ sudo systemctl edit sonarr Enter the text [Service] Restart=on-failure RestartSec=17

moonman commented on 2016-07-30 07:41 (UTC)

@degeberg could you add Restart=on-failure to the systemd service please. It seems sonarr crashes once in a while on armv7 and needs to be restarted manually. This helps

degeberg commented on 2016-04-03 19:06 (UTC)

@fuzzy2: Good point. I've updated the PKGBUILD accordingly.

fuzzy2 commented on 2016-04-03 16:36 (UTC)

I suggest removing the .install file from source/checksums altogether. It's considered bad practice: yaourt prompts you to edit the .install file, but that won't work with this package unless removing it from the source array first.

degeberg commented on 2016-03-14 15:32 (UTC)

Sorry about that. It should work now.

binhex commented on 2016-03-14 14:58 (UTC)

getting a validity test failure on ==> Validating source files with sha512sums...  NzbDrone.master. ... Passed ... Passed  sonarr.service ... Passed  sonarr.install ... FAILED ==> ERROR: One or more files did not pass the validity check! The build failed.

degeberg commented on 2016-03-14 11:18 (UTC)

@disastro: I can't remember if there was any particular reason, so I've removed the "lesser" ones from the PKGBUILD.

disastro commented on 2016-03-13 14:30 (UTC)

Is there a reason you have every possible pkgsum type in there? Since it checks them all and you could just include one...

degeberg commented on 2015-10-04 19:16 (UTC)

Hmm... I wonder if they split the packages. Anyway, it's been updated to include transmission-{cli,gtk,qt} as optdepends instead.

xaisho commented on 2015-10-04 19:06 (UTC)

On install: Optional dependencies for sonarr: sabnzbd: an NZB downloader; nzbget: an NZB downloader; transmission: a torrent downloader; deluge: a torrent downloader. However, transmission is not a package. Possible alternatives are: transmission-cli - daemon, with CLI, and web client (http://localhost:9091) interfaces; transmission-remote-cli - Curses interface for the daemon; transmission-gtk - GTK3 package; transmission-qt - Qt5 package. Could the "optional" dependencies be updated?

jebarb commented on 2015-09-03 00:26 (UTC)

nuget-cert no longer exists on AUR, presumably caused by the switch to AUR4. Package is now broken.

darkfire commented on 2015-07-20 23:06 (UTC)

Upstream got updated to

SAKUJ0 commented on 2015-06-06 14:03 (UTC)

Hey, no rush. I am really impressed that you updated this just very few minutes after I have sent you an email. I hope we weren't annoying you with notifications. For posterity, here is my edited but untested sonarr.service

degeberg commented on 2015-06-06 13:57 (UTC)

I'm sorry I've been away for the last couple of weeks and left the package outdated in the mean time. Hopefully people that needed an update will have figured out editing the version number in the PKGBUILD file. The package should now be up to date with the latest upstream version. I'll see about incorporating SAKUJ0's suggested change during this weekend.

johannvonperfect commented on 2015-06-05 13:58 (UTC)

Upstream has been updated again to

justin8 commented on 2015-04-13 22:35 (UTC)

No problem. Thanks for querying these things. Sometimes packagers overlook simple solutions to things and its helpful. Glad you got a chance to learn something as well.

SAKUJ0 commented on 2015-04-13 11:58 (UTC)

@justin8 I just wanted to add how right you were about /usr (maybe even more right than you would expect). This does not belong into /opt and I would say write permissions inside /usr are not an option. Props to you and degeberg. Thanks to you guys I have learned something.

SAKUJ0 commented on 2015-04-13 10:37 (UTC)

@justin8 I made a post in the Sonarr forums, mainly about the -data 'concerns': I don't argue with anything the two of you have said. Hope I managed to deliver the information appropriately that I mainly wanted to ask for the current reasons to do things the way they are instead of supplying patches or coming up with 'better' or 'right' ways to do things. Let's see if they go as far as to officially deprecate the -data option. I'll keep you posted, in other words consider all my questions answered and I would update you if we hear anything relevant. Thanks for the quick responses!

justin8 commented on 2015-04-13 09:59 (UTC)

@SAKUJ0 There is no link there. Not sure if you didn't post it or if the AUR removes external links in comments these days. The /usr / /var seperation is more of a security thing. Application binaries can't be updated outside of root running your package manager (in a perfect world) Meaning that combined the package signing system you (should) always have trustworthy and immutable programs. It's one of the many ways that Linux is more secure than Windows/OS X by default. If possible I would like to keep the sonarr-develop (and preferably all of the sonarr* packages) not having to use opt since there is an alternative that is more secure.

degeberg commented on 2015-04-13 09:52 (UTC)

I'll have to agree with justin8 on the auto-update thing. It's the package manager's job to keep track of updates and such. In fact, the mono problem you mentioned is a compelling reason to not have applications auto-update themselves. Using the package manager, one can simply opt to either not upgrade sonarr or mono until they're compatible. That being said, I have not personally experienced any problems using the latest repo version of mono along with the latest upstream version of sonarr. As for the --data option, unless its being officially deprecated for future removal, I don't see any reason not to use it. It actually works great for this purpose, which was the reason why I originally made it this way. Separating application binaries from application data is a much more standard Linux/Arch way of doing things. I even believe that's the case on Windows nowadays as well. If they remove --data without providing an alternative, I'll be forced to move it to /opt of course, but I definitely think it'll be a step in the wrong direction.

SAKUJ0 commented on 2015-04-13 08:48 (UTC)

@justin8 I am searching the forums right now here is the thing I am referring to, by the way <@Taloth> yes, but the --data option shouldn't be used in production environments either. you might wanna check our forum, might have a discussion on it.

SAKUJ0 commented on 2015-04-13 08:45 (UTC)

@justin8 I will approach the developers patiently (I don't see any rush with this, arch would be my recommended way to use Sonarr right now *because* of the package you maintained, so thank you again). The Sonarr devs are a bit more Windows centric (they use Linux too of course). From what I gathered and interpreted they would mostly prefer an /opt approach. I believe Arch hates an approach like that but if it is ever warranted, it would probably be here (after all all Sonarr files are in one directory to my knowledge and it would probably solve the -data thing, too - let's not change anything without making sure to do things right, I will talk to the devs and find a forum post). My apologies for the /usr/lib thing. Of course we cannot give write access there, I was mixing things up when compiling things and for that moment I was thinking we were talking about /var/lib so best just ignore that suggestion. Let me come back at you later. I thought I'd let you know you are of course right directly.

justin8 commented on 2015-04-13 00:40 (UTC)

@shkercuh Your one builds in to /opt so it isn't really an issue. /opt is really the catch-all for things that don't comply with the usual standards. check man file-hierachy for more details. It does state that /usr is not required to be read-only. But working in a corporate Linux environment I would have some words with anyone who tried to make an app write to /usr. (FYI, I'm the maintainer for the sonarr-develop package on the AUR) @SAKUJ0 the -data/-datadir thing is needed to write the files to the correct place of /var unless we ran the whole application out of /opt. Since it does appear to support working in this manner, are you able to link to those forum posts you said about the developers recommending against using it?

shkercuh commented on 2015-04-13 00:31 (UTC)

@justin8 @SAKUJ0 Is the approach I have taken in correct?

justin8 commented on 2015-04-13 00:29 (UTC)

I feel I should point out that regardless of the developers wishes, no programs at all should be able to write to /usr. It is static data that should be maintained in your package manager and not transient data. That belongs in /var. Having an auto update system within the app instead of using the OS package manager is a windows/OSX thing that is somewhat against the Linux way of managing things. The correct way to update an app is to update it via the package manager. If auto updating is something they want, it should be living in /opt where other non-conformant apps live.

SAKUJ0 commented on 2015-04-12 17:24 (UTC)

Hey, thanks for maintaining the package. A few obvious and not so obvious points the developers of Sonarr pointed out to me when I mentioned the AUR package: 1) It would be really great if /usr/lib/sonarr had write access to the sonarr user. That is a requirement for the desired update functionality to work within Sonarr and update procedures seem to be fine with the way the installation is set up. 2) Currently using -data / -datadir (I don't recall exactly) is not recommended by the Sonarr devs in production environments. The devs pointed me towards the forums as ongoing discussions appear to be there for best ways how to avoid using the launch option. 3) The distro repo for mono can cause SIGSEGV issues. Currently it is recommended to use mono 3.10.0 instead of 3.12.1 or at least the current git version of 3.12.1. That being said, I myself am using the distro version (3.12.1) of mono just fine so I prefer the currently used mono version myself. I just thought I would mention this. Of course I can supply you with patches but in the spirit of the AUR, which emphasizes collaboration and the learning curve, I thought it would be best to approach you for the reasons of doing things the way they are. Maybe we can handle things more the way the devs of Sonarr would recommend, without going against Arch and AUR conventions. At least making sure the update functionality works (the devs are very conservative with patches) would certainly be a desirable goal.

shkercuh commented on 2015-04-10 10:24 (UTC)

Package has been updated to have Mono's debug mode enabled by default.

johannvonperfect commented on 2015-03-17 15:21 (UTC)

Upstream updated to

shkercuh commented on 2015-03-04 17:13 (UTC)

@johannvonperfect sonarr-develop is the official build; this one you'd compile yourself.

johannvonperfect commented on 2015-03-04 15:45 (UTC)

Is there a difference between this package and sonarr-develop?

johannvonperfect commented on 2015-02-12 15:42 (UTC)

Upstream has gone through a couple of updates and is currently at

ayounggun commented on 2015-02-11 18:37 (UTC)

Hi degeberg Thanks for putting together this package. I'm using it on a raspberry pi 2 currently, and it works really well. In case you're not aware, I thought I should say that a few users (1) have been having problems with sonarr's auto-update feature. They believe it is due to the archlinux/systemd, as similar problems are not seen with debian. Also in the logs I see sonarr complaining about not having the correct write permissions. I'm just looking into these two possibly related things at the moment and wondered whether you had seen this or not. Cheers (1)

degeberg commented on 2015-01-19 11:12 (UTC)

The new version should work with mono 3.12.

pezz commented on 2015-01-18 15:59 (UTC)

This doesn't work with mono-3.12.0-1 that is now in the normal repos, downgrading to mono-3.10.0-1 and all is well again.

degeberg commented on 2015-01-02 12:49 (UTC)

Not yet. You would have to use the develop branch of sonarr.

normanu commented on 2015-01-02 10:29 (UTC)

Has the torrent branch already been included in this?

wilberfan commented on 2014-12-31 19:30 (UTC)

Thanks for the peppy update!

randomstring commented on 2014-12-31 01:00 (UTC)

Upstream updated to

johannvonperfect commented on 2014-12-23 15:05 (UTC)

Upstream updated to (only minor changes though)

justin8 commented on 2014-12-11 00:24 (UTC)

I just looked in to it more; it appears that the torrent branch isn't actually merged in to master yet. So i'll make a sonarr-develop package to replace this for now.

justin8 commented on 2014-12-11 00:20 (UTC)

You are correct, it looks like the sonarr branch has been merged to master and the upstream github project migrated to the new name. I'll make this conflict/provide with nzbdrone and nzbdrone-torrents now and send an email to the maintainer of nzbdrone to see what we want to do.

justin8 commented on 2014-12-11 00:19 (UTC)

Thanks. I'll get this merged in to sonarr. I hadn't realized they had moved it since the old site was still running. And no problem for maintaining them ;) I use them all too.

johannvonperfect commented on 2014-12-10 17:39 (UTC)

You are correct that the sonarr folder has not been updated beyond 2175 (for some reason) but the master folder has been updated up to 2341. This has been updated in the nzbdrone package maintained by degeberg. The two of you may wish to figure out who is maintaining the package as it I think you are duplicating your efforts with the master branch, though degeberg has not changed the name to Sonarr. In addition, as I noted on the torrents package, the files from the domain are now duplicated at if you want to change that over. Again, thanks for your contributions to the community.

johannvonperfect commented on 2014-12-10 17:37 (UTC)

It is my understanding that the torrents branch was deleted and its contents merged into the develop branch, which is up to version 2427: I'm not sure if it is preferable to do a new package, revise this package, etc. Also, the files from the domain are now duplicated at if you want to change that over to the new name. Thanks for your hard work in maintaining a number of packages that I use on my media server.

justin8 commented on 2014-12-06 12:05 (UTC)

v2175 is still the latest one available upstream.

sl33kr commented on 2014-12-02 22:06 (UTC)

Version is available

Tuut commented on 2014-11-01 18:15 (UTC)

New Version is available

Tuut commented on 2014-09-28 11:53 (UTC)

Version is available

justin8 commented on 2014-09-23 14:50 (UTC)

I've made a package for the torrent branch until it gets merged in to master if anyone is interested:\

justin8 commented on 2014-09-21 07:09 (UTC)

That was super fast. Thanks. I also just noticed the install script changes the description of the nzbdrone user if it already exists, I'm not sure if that is on purpose or what.

degeberg commented on 2014-09-21 07:06 (UTC)

Good idea. I've updated the package to do that :)

justin8 commented on 2014-09-21 06:43 (UTC)

Maybe you could try targetting Since it keeps the old versions after new ones exist, and it would stop breaking. It would also not require unpacking a deb to create the package.

Enverex commented on 2014-08-26 11:27 (UTC) is now available. I assume something was wrong with 1855 as it's immediately been replaced with 1861 so this package has broken again already.

Enverex commented on 2014-08-25 15:22 (UTC) is now available.

Enverex commented on 2014-08-24 13:05 (UTC) is now out.

skynet77 commented on 2014-07-03 20:19 (UTC)

new version is 1635 updated PKGBUILD here:

bladesuk1 commented on 2014-06-16 18:43 (UTC)

new version is 1594 new md5sum value is 64e0f6ed7df08bf63c583f39476641b6

bladesuk1 commented on 2014-06-13 11:37 (UTC)

new version is 1586 change the first md5sum to this: f9bda8f89dbb5ef3c8f27dbb2c90ef8e that should sort out the packagebuild

bladesuk1 commented on 2014-06-13 11:29 (UTC)

there's a tar file available here: that might be a better way to pull it down, rather than unpacking the .deb file? should hopefully fix the issues with the missing deb file as well (which i'm also having, btw).

daveerickson commented on 2014-05-10 02:44 (UTC)

It doesn't appear that the 1350 deb is still available. I get a 404 error when I try to install.

degeberg commented on 2014-04-28 07:11 (UTC)

I believe it works now. I guess it was a problem with the server on their end.

Korni22 commented on 2014-04-27 16:53 (UTC)

Download is broken, because the verification of the .deb fails. The verification fails, because the .deb returns just the homepage of the project.

pho commented on 2014-01-25 12:54 (UTC)

Ok good point. I always saw sabnzbd, sickbeard and couchpotato as their own and found it easier to manage that all the packages are in /opt/{pkg}. But I see your point now.

degeberg commented on 2014-01-24 04:53 (UTC)

I mean to refer to the sickbeard package, by the way.

degeberg commented on 2014-01-23 20:36 (UTC)

As I previously said, I think that categorically stating "[in] /opt as it should be" is highly debatable. The Arch Packaging Standard says that "/opt/{pkg}" is for self-contained packages, and "/usr/lib/{pkg}" is for libraries. I think what I've placed under /usr/lib counts as libraries used for the mono program (run via the /usr/bin/nzbdrone executable script). Multiple other packages do something similar. I mentioned chromium earlier, but to mention a few more: r, virtualbox, erlang, ghc. I'm sure I could find more if I bothered. These are packaged by Arch Linux TUs/devs, so I think they can reasonably be regarded as an authoritative interpretation of the packaging standards. Even the mono package, which nzbdrone uses, stores its *.exe files under /usr/lib/mono and has tiny shell scripts in /usr/bin looking like "exec /usr/bin/mono /usr/lib/mono/whatever" like I do. If you want an example from AUR, I can point to the sabnzbd package (which as a "competitor" program must be a reasonably close example for comparison purposes) that is packaged in exactly the same way as this package. If you feel this should be changed, please do provide a compelling counterargument, and I'll of course consider it. So far I've heard nothing but "I think otherwise".

pho commented on 2014-01-23 12:15 (UTC)

deb is no longer available I've changed my package to /opt as it should be

justin8 commented on 2013-11-29 12:37 (UTC)

This should be x86_64/i686. Any packages are for things that can be compiled anywhere and run on any architecture. exe's with mono don't fit in to that category. And as said before, it probably belongs in /opt, but that's your choice.

Bombardment commented on 2013-11-26 20:55 (UTC)

Flagged out-of-date. deb is no longer available

12eason commented on 2013-11-03 19:40 (UTC)

Check out the way sabnzbd, sickbeard and couchpotato do it. Even the executable belongs there, in a folder that only it has access to. /opt/ was meant for packages like this. Chromium is different, it's not a web server for a start.

degeberg commented on 2013-11-03 11:12 (UTC)

I think that's debatable. I regarded it as libraries required to execute the /usr/bin/nzbdrone executable. The chromium package works the same way. I agree that it can belong in /opt as well though.

12eason commented on 2013-11-03 10:42 (UTC)

Thanks for this, but it belongs in /opt/.