Arch Linux User Repository

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

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.

@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? :(

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

@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.

Can you put this in the service file:

[Service]
SyslogIdentifier=sonarr

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

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

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?

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 10.0.0.2685" 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 6.12.0.147, so probably >=6.12.0.147 then.

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. :)

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

@fryfrog We are currently blocked by FS#71007, which prevents sonarr from successfully building with msbuild. I have tested this patch with mono 6.12.0.147, 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
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -3,20 +3,18 @@
 # Contributor: Justin Dray <justin@dray.be>
 # Helpful URL: http://services.sonarr.tv/v1/releases

-pkgname='sonarr'
-pkgver=3.0.6.1265
+pkgname=sonarr
+pkgver=3.0.6.1266
 pkgrel=1
 pkgdesc='TV download automation for usenet and torrents.'
-arch=(any)
+arch=(x86_64)
 url='https://sonarr.tv/'
 license=('GPL3')
-
 depends=(
   'mono'
   'libmediainfo'
   'sqlite'
 )
-
 optdepends=(
   'sabnzbd: usenet downloader'
   'nzbget: usenet downloader'
@@ -27,26 +25,44 @@ optdepends=(
   'rtorrent: torrent downloader'
   'jackett: torrent indexer proxy'
 )
+makedeps=(
+  'nuget'
+  'mono-msbuild'
+)

 source=(
-  "https://download.sonarr.tv/v3/main/${pkgver}/Sonarr.main.${pkgver}.linux.tar.gz"
+  "https://github.com/Sonarr/Sonarr/archive/refs/tags/v$pkgver.tar.gz"
   'sonarr.service'
   'sonarr.sysusers'
   'sonarr.tmpfiles'
   'package_info'
 )

-noextract=()
-sha256sums=('87098971b27d383b4502f9350dbc919d94f3486b93514b98ba7fde67dc83018b'
+sha256sums=('3973cf80928062b4fd068a45a417a4fb4f26ee6dd740ad92f6198070d54fd652'
             'cafc9dfea7d6f941d7c481d35d83e3228ac35f51ad78a220e2eb1e1bd3652d62'
             'cc3c69f719fa64335f4c5b41b2588f1ec56865fb2202f5919d3668b50b8f398e'
             '7bf87304383b7d58ecab59b3686d00a8f1b6fbe4af3a86da35a887e4cebee411'
             '19112dc0051224b4de66f28077c93b6ee06e163b5194e6aecf62dedf66ff45a9')

+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"

@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!

Just as a notice, this package is more like sonarr-bin rather then sonarr, since its only delivering prebuild binarys. See https://wiki.archlinux.org/title/AUR_submission_guidelines#Rules_of_submission for more.

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.

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.

@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.

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: 'services.sonarr.tv'
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:

Wants=network-online.target
After=network-online.target

Sure. I've removed the nzbdrone stuff now.

@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?

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

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 www.nzbfinder.ws 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 4.3.3.0546

https://www.dropbox.com/s/xiwzpfgj87mbibx/sonarr.debug.txt?dl=0

https://www.dropbox.com/s/y09dkbz5yq2nw02/sonarr.trace.txt?dl=0

Please can someone assist.

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

@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.

https://github.com/Sonarr/Sonarr/releases

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

https://bugs.archlinux.org/task/57718

I downgraded ncurses to the last 6.0

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

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 

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

Thanks!

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

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.