Overseer with lidarr support

[ano0002]

Description

Implemented Lidarr Support into overseerr

• You can find it on Docker Hub here for now: https://hub.docker.com/r/ano002/overseerr-lidarr

Here is a sample docker-compose.yml for it :

version: '3'
services:
  overseerr:
    build:
      context: https://github.com/ano0002/overseerr.git#overseer-with-lidarr-support
      args:
        COMMIT_TAG: c105f10420049d1ade2eb28a6ae8335e96507e74
      dockerfile: Dockerfile.local
    ports:
      - 5055:5055
    volumes:
      - .:/app:rw,cached
      - /app/node_modules
      - /app/.next

[ano0002]

I just rebased all the commits, it's all in your hands now !

[githubaccount3322]

brilliant, hope this gets approved

[ano0002]

I'll repost here what I said on discord:

I temporarly pushed it to docker hub for anyone wanting to try it out but who don't want to build it: https://hub.docker.com/r/ano002/overseerr-lidarr I'll delete it as soon as it gets merged.

And also:

Now that I'm using only the lidarr overseerr I found some bugs:

• the Jobs & Cache page crashes in settings
• even though they are in the backend I forgot to add the possibility change music quotas etc for users in the frontend

If you have found any other issues please report them to me

[ano0002]

the Jobs & Cache page crashes in settings

Just fixed this

[ano0002]

Even though they are in the backend I forgot to add the possibility change music quotas etc for users in the frontend

Fixed this too

[psychowood]

I'll repost here what I said on discord:

I temporarly pushed it to docker hub for anyone wanting to try it out but who don't want to build it: https://hub.docker.com/r/ano002/overseerr-lidarr I'll delete it as soon as it gets merged.

Hi, I'm testing the docker image, it looks like that the external lidarr url is ignored.

In settings I specified an external url:

but in the overseer music page everything defaults to "/images/overseerr_poster_not_found_logo_top.png" image

and in the debug console you can see that it is trying to use the internal url (in https)

The same happens when opening an artist's page

Album view is OK, image is pulled directly from coverartarchive.

[ano0002]

Thanks for reporting this, I will hopefully be able to fix these soon as I'm finally on vacation

[kshannoninnes]

May I suggest changing "Musics" to "Music", given that the plural of Music is the same word? eg. "That's a lot of music", but not "That's a lot of musics". Seems to be in a few places (eg. search bar placeholder, main page header, "Discover More Musics", etc), but not all.

Otherwise, I plan to pull this other image shortly and check it out!

[kshannoninnes]

Thanks for reporting this, I will hopefully be able to fix these soon as I'm finally on vacation

As for this issue, I don't believe the external url is ignored per se, as setting the url to the local address allows cover art to be appropriately retrieved.

[kshannoninnes]

After using it for a bit, I think a better layout for the artist view is to improve the album display so it's not a horizontal scroller. I think a better option would be a list, including a coverart thumbnail, album title, release date, number of tracks, and maybe some other information like studio published under although this is less relevant and could be shown on the album view instead.

I like the way lidarr did it, where you can select metadata types to be displayed (eg. albums, singles, mixtapes, soundtracks, etc), and have each one be a scrollable list with a reasonable height. Maybe even make each release type its own tabbed section within the artist view.

Also, are there any plans to implement the discover feature in the music view?

[psychowood]

Thanks for reporting this, I will hopefully be able to fix these soon as I'm finally on vacation

As for this issue, I don't believe the external url is ignored per se, as setting the url to the local address allows cover art to be appropriately retrieved.

What do you mean? In my case the internal url is http only (while the browser exposes it in https) and is not reachable (it's internal to the docker network of the container). On the other side, I can't use the external url internally because it's behind a reverse proxy (no reachable from the docker network) with authentication.

[kshannoninnes]

Thanks for reporting this, I will hopefully be able to fix these soon as I'm finally on vacation

As for this issue, I don't believe the external url is ignored per se, as setting the url to the local address allows cover art to be appropriately retrieved.

What do you mean? In my case the internal url is http only (while the browser exposes it in https) and is not reachable (it's internal to the docker network of the container). On the other side, I can't use the external url internally because it's behind a reverse proxy (no reachable from the docker network) with authentication.

What I mean is that I had the same issue as you, using the external url meant the cover art wasn't being retrieved properly due to not found errors. When I changed that "external url" parameter to the local ip address, the cover art was appropriately retrieved. So it's not that the external url is ignored, it's just misnamed or misused somehow.

[psychowood]

What I mean is that I had the same issue as you, using the external url meant the cover art wasn't being retrieved properly due to not found errors. When I changed that "external url" parameter to the local ip address, the cover art was appropriately retrieved. So it's not that the external url is ignored, it's just misnamed or misused somehow.

Well that makes sense as a workaround, when possibile. In my case though the local ip of lidarr is not reachable (internal docker network), and lidarr is exposed via a reverse proxy that needs the correct hostname...

[trivarialthea]

Hi, any updates on when this is going to be in the stable release?

[ano0002]

Thanks for reporting this, I will hopefully be able to fix these soon as I'm finally on vacation

As for this issue, I don't believe the external url is ignored per se, as setting the url to the local address allows cover art to be appropriately retrieved.

What do you mean? In my case the internal url is http only (while the browser exposes it in https) and is not reachable (it's internal to the docker network of the container). On the other side, I can't use the external url internally because it's behind a reverse proxy (no reachable from the docker network) with authentication.

What I mean is that I had the same issue as you, using the external url meant the cover art wasn't being retrieved properly due to not found errors. When I changed that "external url" parameter to the local ip address, the cover art was appropriately retrieved. So it's not that the external url is ignored, it's just misnamed or misused somehow.

The external URL was in fact being misused, I didn't catch it at first but it was using /movie/ instead of /album/ and /artist/. The issue is I don't know how to test the fix so it's kinda up to someone else to verify it works. (I did verify the code works but I couldn't really test it outside what I did)

[ano0002]

I built the newest version and pushed it to docker hub! This should fix your issue @psychowood and @kshannoninnes .

[anatosun]

Unsure if it's a bug or a feature.

If a request is made for a release of an unmonitored artist. The release is not monitored and thus not searched, since the artist is not monitored.

The expected behavior would be to monitor the artist and the release, and search for it?

[ano0002]

Unsure if it's a bug or a feature.

If a request is made for a release of an unmonitored artist. The release is not monitored and thus not searched, since the artist is not monitored.

The expected behavior would be to monitor the artist and the release, and search for it?

Thanks for reporting this, I'll try and fix it soon

[ano0002]

Latest version is on docker hub

[DeadDevil6210]

Hi Everyone,

I came across ano0002 his overseer Lidarr docker and installed it (Host OS = Unraid).

It seems to work beter since the last update thnx for your hard work!

I found one thing, My Lidarr scan get interupted with the following message:

2024-08-15T09:44:39.332Z [error][Lidarr Scan]: Scan interrupted{"errorMessage":"[Lidarr] Failed to retrieve albums: Cannot create a string longer than 0x1fffffe8 characters"}

When I check the Lidarr connection on the service tab it's fine and works, I also see that some artiste are being flagged by overseers as available and that's correct. So it works but it seems that the job Lidarr scan has an issue?

If I can help in any meaningful way let me know,

[ano0002]

Unsure if it's a bug or a feature.

If a request is made for a release of an unmonitored artist. The release is not monitored and thus not searched, since the artist is not monitored.

The expected behavior would be to monitor the artist and the release, and search for it?

~~@anatosun I fixed this overlook, now if you add a release, Overseerr will ask Lidarr to monitor the artist and the release, and search for it. However, because of the way Lidarr API is setup, I can't know if Lidarr found a release in the indexers. I'll maybe find a workaround later but for now I have no fix.~~

After talking with the Servarr discord, I need to update my lidarr and it should hopefully allow to do some things.

[huzama]

Thank you, @ano0002, for your hard work. I've found another bug: accessing Overseerr via HTTPS results in the following error:

[blocked] The page at https://overseerr.domain.com/ requested insecure content from http://IP:PORT/MediaCover/396/poster.jpg?lastWrite=ID. This content was blocked and must be served over HTTPS.

However, it works relatively fine when accessed via HTTP. Specifically, the artist posters are displayed correctly using HTTP when an artist page is opened but not on the music page.

[ano0002]

Thank you, @ano0002, for your hard work. I've found another bug: accessing Overseerr via HTTPS results in the following error:

[blocked] The page at https://overseerr.domain.com/ requested insecure content from http://IP:PORT/MediaCover/396/poster.jpg?lastWrite=ID. This content was blocked and must be served over HTTPS.

However, it works relatively fine when accessed via HTTP. Specifically, the artist posters are displayed correctly using HTTP when an artist page is opened but not on the music page.

Thanks for reporting that, I was aware of the issue and didn't have time to fix it yet. Will fix when I have time.

For any issues that arise could you please put them in: https://github.com/ano0002/overseerr/issues as it will make it easier to keep track

[ano0002]

The Lidarr API should now work as expected (at least to add stuff, the scanning part hasn't changed)

[ano0002]

Pushed the latest commit to docker

[ano0002]

!!! If you are using the lidarr fork and have been experiencing issue with the lidarr requests please pull the latest image from docker for both lidarr and overseerr-lidarr. I finally managed to find a fix which is reliable. The scans however might still have issues as I haven't gotten around to it yet.

[kieraneglin]

Tremendous work here! Is there any specific areas of testing that you'd like to give extra attention?

[ano0002]

I haven't fixed the lidarr scan and the UI requesting elements from lidarr directly so not those. But requesting should work for both artists and releases, artist are not always marked as available though. I also don't really know how I should make the search work, rn I'm not satisfied with how it works. I think there isn't anything specifically but if you find new bugs feel free to report them.

[Druidblack]

Good afternoon. I want to see how the integration with ldap works, I'm trying to run docker. It gives an error when starting. What should I do to launch the docker container?

yarn run v1.22.19
error Couldn't find a package.json file in "/app"
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

[ano0002]

Good afternoon. I want to see how the integration with ldap works, I'm trying to run docker. It gives an error when starting. What should I do to launch the docker container?

yarn run v1.22.19
error Couldn't find a package.json file in "/app"
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

What does your docker compose look like ?