Package Details: lidarr 0.8.1.2135-2

Git Clone URL: https://aur.archlinux.org/lidarr.git (read-only, click to copy)
Package Base: lidarr
Description: Music download automation for usenet and torrents.
Upstream URL: https://github.com/lidarr/Lidarr
Licenses: GPL3
Submitter: orkeren
Maintainer: fryfrog
Last Packager: fryfrog
Votes: 10
Popularity: 0.000010
First Submitted: 2017-10-06 08:46 (UTC)
Last Updated: 2021-10-19 15:38 (UTC)

Required by (4)

Sources (7)

Pinned Comments

fryfrog commented on 2021-02-12 07:01 (UTC)

You may also be interested in lidarr-develop or lidarr-nightly.

Latest Comments

resol341 commented on 2022-04-20 03:24 (UTC)

Thank you!

eta-carinae commented on 2022-04-19 22:22 (UTC)

resol341,

You can work around this issue for now by setting the environment variable DOTNET_SYSTEM_GLOBALIZATION_INVARIANT to 1 when you run lidarr.

resol341 commented on 2022-04-17 15:57 (UTC)

Getting "Process terminated. Couldn't find a valid ICU package installed on the system." after icu update.

fryfrog commented on 2021-02-12 07:01 (UTC)

You may also be interested in lidarr-develop or lidarr-nightly.

fryfrog commented on 2019-04-13 14:31 (UTC) (edited on 2019-04-13 14:31 (UTC) by fryfrog)

@xombiemp: I've added it as an optdepend for now, thanks for letting me know.

xombiemp commented on 2019-04-13 13:54 (UTC)

After the latest update I'm seeing this message in the Health check page: fpcalc could not be found. Audio fingerprinting disabled.

Looks like we can solve the issue by making chromaprint a dependency. https://github.com/Lidarr/Lidarr/wiki/Health-checks#fpcalc-missing

storrgie commented on 2018-05-30 17:10 (UTC)

Alright, thanks! I didn't want to harass via a flag if you had something else in mind. Thanks for the quick update.

fryfrog commented on 2018-05-30 15:06 (UTC)

It started by tracking development, since that was all they had. Now it tracks their pre-releases, though I was expecting them to be a little more frequent. When they have a release version, I'll have it track that.

You can totally flag out of date for pre-releases. :)

storrgie commented on 2018-05-30 14:52 (UTC)

Would this package consider moving to their most recent "prerelease" or should that be done in a lidarr-git package?

https://github.com/lidarr/Lidarr/releases/tag/v0.3.0.430

fryfrog commented on 2018-04-26 23:10 (UTC)

@binhex, now that they've had a "release" ... what do you think we should track here? :/

fryfrog commented on 2018-03-21 14:46 (UTC)

@binhex, the lidarr.tmpfiles creates and maintains ownership of /var/lib/lidarr and /usr/lib/lidarr. The way of the future! :)

binhex commented on 2018-03-21 12:26 (UTC)

thanks @fryfrog

btw i think you may want to take a look at the lidarr.service file, it still has references to /var/lib/lidarr, which by the look of the PKGBUILD is no longer created.....unless the very action of running the service creates this folder?, i dunno but i thought its worth mentioning.

fryfrog commented on 2018-03-17 19:55 (UTC)

Ah, this is from using the trixie url thing. :/

binhex commented on 2018-03-17 16:39 (UTC)

I'm getting validation failure:-

Validating source files with sha512sums... Lidarr.develop.0.2.0.305.linux.tar.gz ... ?[0m ?[91mFAILED

binhex commented on 2018-03-09 09:31 (UTC)

@fryfrog looks good to me mate, my automated scripts picked up your change and built a new docker image with no issues, so its all good for me.

fryfrog commented on 2018-03-08 17:39 (UTC)

@binhex and @orkeren, check out what I just pushed and see what you think. When Lidarr has regular (pre)releases, we can do away w/ the silliness. We'll still need to manually edit the pkgver, so don't forget to do that! :)

binhex commented on 2018-03-08 10:46 (UTC)

ok how about a bit of regex then so we don't rely on jq:-

lidarr_url=$(curl -s "https://services.lidarr.audio/v1/update/nightly/changes?os=linux" | grep -P -o -m 1 '(?<=url":")[^"]+' | head -1)

orkeren commented on 2018-03-08 10:04 (UTC)

@binhex - that snippet though requires jq which we would have to add as dependency.

orkeren commented on 2018-03-08 10:03 (UTC)

@fryfrog I'll add you. @binhex thanks for that snippet!

binhex commented on 2018-03-06 16:01 (UTC)

This might be of interest @fryfrog @orkeren, json output from appveyor, so you could curl this and then jq to get first entry, that way you can then just re-run without having to alter the url in the PKGBUILD:-

lidarr_url=$(curl "https://services.lidarr.audio/v1/update/nightly/changes?os=linux" | jq -r '.[0].url')

fryfrog commented on 2018-03-05 20:42 (UTC)

https://ci.appveyor.com/api/buildjobs/w3mqu9a4gtrdgv38/artifacts/Lidarr.develop.0.2.0.289.linux.tar.gz <- this one fixes mono 5.10.

I'd be happy to be a co-maintainer to help keep it more up to date.

orkeren commented on 2018-02-19 10:20 (UTC)

@binhex there sadly is no way of targeting latest on appveyor. I am looking into creating an automated way though. Until then I will try to remember updating weekly.

binhex commented on 2018-02-08 09:47 (UTC)

@orkeren hey no probs, no apology required. How about a weekly build of this until things stabilise a bit, as those dev builds are obviously continuous, would that be a possibility? Not sure if there is a way of targeting 'latest' on appveyor to prevent the need to change the package?

orkeren commented on 2018-02-08 00:19 (UTC)

@binhex - I have updated the package to the current build. I apologize for the delay in updating packages. In the future just flag it as out of date, as I get a priority alert for that.

binhex commented on 2018-02-07 10:07 (UTC) (edited on 2018-02-07 10:26 (UTC) by binhex)

i appreciate this is pre-alpha and thus difficult at this time, but is there a later developer build we can move to?, this hasn't changed in a while, if not could this package target github master branch instead?

edit - i cannot use the built in app updater as im running this in a docker container.

edit2 - bit of googling revelaed a link to appveyor with their latest dev build (0.2.0.267) :- https://ci.appveyor.com/project/lidarr/lidarr/build/artifacts

fryfrog commented on 2017-12-25 04:04 (UTC) (edited on 2017-12-25 04:06 (UTC) by fryfrog)

To make the built in updater work, you probably just need to update some permissions in the package. While it isn't Arch to use the built in updater... you don't need to block it. :)

Edit: Which it looks like you might already be doing!

orkeren commented on 2017-12-14 13:10 (UTC)

@mhicklen I have now updated this package to the latest version of lidarr. Regarding the built-in updates page - you have to remember that this is still pre-alpha software, and as such features like that are not exptected to work. Furthermore it would be against the spirit of using a package manager like pacman to use such a build-in update feature.

hicklemon commented on 2017-12-13 21:46 (UTC)

Looks like the database schema is not being properly read in this release. The author has advised an update; however, the artifact being downloaded here is too old. Additionally, the updates page in the software's UI fails to function.

orkeren commented on 2017-10-24 11:25 (UTC)

@Ryan-Bell you are obviously right. I have fixed this witth the 0.2.0.103 update.

Ryan-Bell commented on 2017-10-22 23:50 (UTC)

I think the version in the .SRCINFO was not updated in the last commit (to 0.2.0.78). The package fails to install.