Lidarr widget not working

[2ndwonder]

Lidarr widget is not working for me. Am I missing something? I don't see instructions for Lidarr.

    - Lidarr:
        icon: lidarr.png
        href: https://subdomain.domain.nl
        description: Music Managment
        server: docker
        container: lidarr
        widget:
          type: lidarr
          url: https://subdomain.domain.nl
          key: API KEY 

If I uncomment the "key" section, it loads. But with API Error.

with API key included

[JazzFisch]

Is your Lidarr instance, perhaps, on a sub-path such as https://subdomain.domain.nl/lidarr?

[2ndwonder]

No it Is not

[JazzFisch]

Is there anything in the log output from the homepage container?

[benphelps]

The services proxy is reporting that the API key is unauthorized, it forwards the API response 1:1, so that's the actual error returned by the API. I'd check and make sure your key is correct.

[2ndwonder]

I double checked the API. It is correct. I'll try to generate another API key and see if that works

[2ndwonder]

I changed the API and still the same results.

@JazzFisch this is what I'm only getting from the logs from Homepage

[mtompkins]

I can confirm that the Lidarr widget chokes on large libraries. Perhaps this is in play for this issue.

[benphelps]

Ohhh, it very well could be. How large is your library?

This is also a problem with the Radarr and Sonarr integrations.

[bjgeiser]

Mine is failing the same way for Lidarr and Readarr. Seeing this in the container logs.

type=lidarr&group=Media+Management+%28Cont%29&service=Lidarr&endpoint=album exceeds 4MB. API Routes are meant to respond quickly. https://nextjs.org/docs/messages/api-routes-response-size-limit

[neildeadman]

My Lidarr is failling also:

API response for /api/services/proxy?type=lidarr&group=Media+Acquisition&service=Lidarr&endpoint=album exceeds 4MB. API Routes are meant to respond quickly. https://nextjs.org/docs/messages/api-routes-response-size-limit
TypeError: Cannot read properties of null (reading 'map')
    at handler (/app/.next/server/pages/api/bookmarks.js:61:36)
    at async Object.apiResolver (/app/node_modules/.pnpm/next@12.3.0_biqbaboplfbrettd7655fr4n2y/node_modules/next/dist/server/api-utils/node.js:366:9)
    at async NextNodeServer.runApi (/app/node_modules/.pnpm/next@12.3.0_biqbaboplfbrettd7655fr4n2y/node_modules/next/dist/server/next-server.js:469:9)
    at async Object.fn (/app/node_modules/.pnpm/next@12.3.0_biqbaboplfbrettd7655fr4n2y/node_modules/next/dist/server/next-server.js:719:37)
    at async Router.execute (/app/node_modules/.pnpm/next@12.3.0_biqbaboplfbrettd7655fr4n2y/node_modules/next/dist/server/router.js:247:36)
    at async NextNodeServer.run (/app/node_modules/.pnpm/next@12.3.0_biqbaboplfbrettd7655fr4n2y/node_modules/next/dist/server/base-server.js:346:29)
    at async NextNodeServer.handleRequest (/app/node_modules/.pnpm/next@12.3.0_biqbaboplfbrettd7655fr4n2y/node_modules/next/dist/server/base-server.js:284:20)

[JazzFisch]

Interesting. Also, ever so slightly jealous of the size of your libraries. 😁
Let me see if there's a way I can convince the underlying Lidarr API to return summary data.

[2ndwonder]

I have over 1 TB shows on Sonarr and that widget is working without problems. On Lidarr I got like maybe max 5-10 GB music. So something else is going on

[JazzFisch]

I just looked at Lidarr's source code and they don't have a way to get summary data. I have an idea for a workaround that doesn't proxy the entire Lidarr response body to the client that runs in homepage server side.

[bjgeiser]

Could the 4MB limit be removed per this: https://nextjs.org/docs/messages/api-routes-response-size-limit. It's not like the API requests are going across the internet in most cases.

[2ndwonder]

Lidarr still nog working.. all of the other widgets work for me.

[bjgeiser]

Just updated to the new release (0.3.55) and large libraries still aren't working.

From container logs:

TypeError: Cannot read properties of undefined (reading 'percentOfTracks')
    at /app/.next/server/pages/api/services/proxy.js:145:61
    at Array.filter (<anonymous>)
    at /app/.next/server/pages/api/services/proxy.js:116:50
    at jsonArrayTransform (/app/.next/server/pages/api/services/proxy.js:109:12)
    at jsonArrayFilter (/app/.next/server/pages/api/services/proxy.js:116:10)
    at Object.album (/app/.next/server/pages/api/services/proxy.js:145:15)
    at genericProxyHandler (/app/.next/server/pages/api/services/proxy.js:397:36)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async Object.apiResolver (/app/node_modules/.pnpm/next@12.3.0_biqbaboplfbrettd7655fr4n2y/node_modules/next/dist/server/api-utils/node.js:366:9)
    at async NextNodeServer.runApi (/app/node_modules/.pnpm/next@12.3.0_biqbaboplfbrettd7655fr4n2y/node_modules/next/dist/server/next-server.js:469:9)

This is similar to what the browser console was doing before the change, makes me think the json is still being truncated.

[JazzFisch]

I think if this were a data truncation issue, the JSON.parse inside of asJson would have failed. I'll try adding a little more null coalescing logic.

[JazzFisch]

Looks like Ben just submitted the almost exact same fix I was working on. 😁

[bjgeiser]

Lidarr and Readarr are working now with 0.3.57. Nice work.

[2ndwonder]

I can confirm that Lidarr also works on my side. Thanks guy's!

[benphelps]

Thanks all for getting this one ironed out :)

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new discussion for related concerns.