Package Details: sonarr 4.0.15.2941-1

Git Clone URL: https://aur.archlinux.org/sonarr.git (read-only, click to copy)
Package Base: sonarr
Description: Smart PVR for newsgroup and torrent users
Upstream URL: https://sonarr.tv
Licenses: GPL-3.0-or-later
Groups: servarr
Submitter: txtsd
Maintainer: txtsd (fryfrog)
Last Packager: txtsd
Votes: 5
Popularity: 0.114991
First Submitted: 2024-10-15 07:11 (UTC)
Last Updated: 2025-06-20 17:55 (UTC)

Dependencies (22)

Required by (17)

Sources (5)

Pinned Comments

mkomko commented on 2024-11-15 06:59 (UTC)

PSA: If you receive exceptions like "System.IO.IOException: Read-only file system" when Sonarr is importing files after updating to 4.0.10.2544, and you use your home directory for downloaded files (which is advised against), you can either move file management out of your home directory or do something like the following:

$ sudo systemctl edit sonarr

[Service]
# Allow home directory path to be writable again
ReadWritePaths=/home/user/media

txtsd commented on 2024-10-21 03:54 (UTC) (edited on 2024-10-30 12:50 (UTC) by txtsd)

Alternate versions

sonarr-bin (binary version of this package)
sonarr-develop (develop branch)
sonarr-develop-bin (binary version of the develop branch)

Latest Comments

1 2 3 Next › Last »

fryfrog commented on 2025-07-20 03:24 (UTC)

@Bosnia, ever since the move to building I've had to do most of them in a chroot via extra-x86_64-build, maybe that'll get you sorted? I just built it that way and it was fine.

You could also switch to the sonarr-bin package.

Bosnia commented on 2025-07-20 02:57 (UTC)

I'm running into a dotnet-sdk issue when installing the latest version.

requested SDK version: 6.0.113
global.json file: /home/guitar/.cache/yay/sonarr/src/Sonarr-4.0.15.2941/global.json

Installed SDKs:
6.0.428 [/usr/share/dotnet/sdk]

Install the [6.0.113] .NET SDK or update [/home/guitar/.cache/yay/sonarr/src/Sonarr-4.0.15.2941/global.json] to match an installed SDK.

Learn about SDK resolution:
https://aka.ms/dotnet/sdk-not-found
==> ERROR: A failure occurred in prepare().
    Aborting...
-> error making: sonarr-exit status 4
-> Failed to install the following packages. Manual intervention is required:
sonarr - exit status 4

When I edited the global.json file to point to the SDK version that does get installed, I end up running into a yarn issue... not sure if it's related to dotnet.

error rimraf@6.0.1: The engine "node" is incompatible with this module. Expected version "20 || >=22". Got "21.6.2"
error Found incompatible module.

alan.mckinnon commented on 2025-01-08 13:08 (UTC)

@fryfrog sure thing, soon as I figure discord out. 20+ years in this game and never used Discord :-D

fryfrog commented on 2025-01-07 16:18 (UTC)

@alan.mckinnon, hop on Discord and we'll figure out whats wrong and get it sorted.

alan.mckinnon commented on 2025-01-07 15:27 (UTC)

Hi,

Any breaking changes since Dec 22? I notice this issue on most of the *arrs now. I was away from Dec 22 till Jan 5, and stuff worked fine before I left.

After pacman -Syu and updating all arrs, now they won't manually import. Importing one file does move the file, then writes an .nfo file and then the task never completes. It shows up in System -> Tasks and just stays there. Importing more than one file does move the first, then same as above.

Nothing sensible shows up in the trace logs or systemd journal. incomplete, downloaded files and destination are all on NFS on FreeNAS, this setup has worked for years.

Any ideas? System is fully updated Sonarr is latest here: pkgver=4.0.12.2823 pkgrel=1

Can provide all logs and info if needed, didn't post them yet to avoid clutter

fryfrog commented on 2025-01-01 17:24 (UTC)

@einappo, you could override -data w/ the path to your actual appdata location instead of using a symlink. I don't think it would fix the issue you're reporting, but it would remove a layer of indirection.

elnappo commented on 2025-01-01 15:26 (UTC) (edited on 2025-01-01 15:38 (UTC) by elnappo)

Setting StateDirectory=sonarr breaks Sonarr and all other *arr's for me because /var/lib/sonarr is a symlink pointing to another disk. Overriding the unit with StateDirectory= fixes it. There is already a systemd issue https://github.com/systemd/systemd/issues/25097

Furthermore the LogsDirectory= issue has to be fixed in all *arr packages including -bin

zayatura commented on 2024-12-24 17:29 (UTC) (edited on 2024-12-24 17:32 (UTC) by zayatura)

Does it work if you use an override to set it to nothing?

Yes, it works. That's what I also did to get rid of the warning. I guess we don't need systemd managing the log files.

Thanks for maintaining this package!

Note that you seem to have forgotten to update the pkgrel value of this package after updating the service files, so my AUR helper won't see the package as updated.

zayatura commented on 2024-12-24 17:27 (UTC)

Thanks for the report. Does it work if you use an override to set it to nothing?

Np. Yes, that's what I also did to get rid of the warning.

Thanks for maintaining this package!

fryfrog commented on 2024-12-23 19:29 (UTC)

Hey @zayatura, the LogsDirectory= was set to sonarr previously and a systemd update caused the too many levels of symbolic links issue. I "fixed" them all by setting it to /var/lib/sonarr/logs which only actually fixed it because it was invalid. I guess we need to go back and remove the line entirely!

Thanks for the report. Does it work if you use an override to set it to nothing?

1 2 3 Next › Last »