navidrome
navidrome copied to clipboard
Navidrome unresponsive after listing a specific artist
Hi together,
i am using navidrome for e few month now and everything works great. But today i am trying to list a specific Artist and navidrome (webUI) gets unresponsive vor minutes... After ~2min the webui comes back to live. When i try to relist the artist the same happens. Listing other artists is working. Im not sure if die Artistname could be a Problem because its "Die Drei ???" or eventually because there are >200 Albums from it?
Die Gui shows unfinished results when it gets unresponsive:
And te debug-Log only shows a lot of api-requests but without any errormessage...
vel=debug msg="HTTP: GET http://ssh.bit-link.de:4533/rest/getCoverArt?u=Alex&t=[REDACT> vel=debug msg="API: New request /rest/getCoverArt" client=NavidromeUI requestId=Bit-Li> vel=debug msg="HTTP: GET http://ssh.bit-link.de:4533/rest/getCoverArt?u=Alex&t=[REDACT> vel=debug msg="HTTP: GET http://ssh.bit-link.de:4533/rest/getCoverArt?u=Alex&t=[REDACT> vel=debug msg="HTTP: GET http://ssh.bit-link.de:4533/rest/getCoverArt?u=Alex&t=[REDACT> vel=debug msg="HTTP: GET http://ssh.bit-link.de:4533/rest/getCoverArt?u=Alex&t=[REDACT> vel=debug msg="API: New request /rest/getCoverArt" client=NavidromeUI requestId=Bit-Li> vel=debug msg="API: New request /rest/getCoverArt" client=NavidromeUI requestId=Bit-Li> vel=debug msg="API: New request /rest/getCoverArt" client=NavidromeUI requestId=Bit-Li> vel=debug msg="API: New request /rest/getCoverArt" client=NavidromeUI requestId=Bit-Li> vel=debug msg="HTTP: GET http://ssh.bit-link.de:4533/rest/getCoverArt?u=Alex&t=[REDACT> vel=debug msg="HTTP: GET http://ssh.bit-link.de:4533/rest/getCoverArt?u=Alex&t=[REDACT> vel=debug msg="API: New request /rest/getCoverArt" client=NavidromeUI requestId=Bit-Li> vel=debug msg="API: New request /rest/getCoverArt" client=NavidromeUI requestId=Bit-Li> vel=debug msg="HTTP: GET http://ssh.bit-link.de:4533/rest/getCoverArt?u=Alex&t=[REDACT> vel=debug msg="HTTP: GET http://ssh.bit-link.de:4533/rest/getCoverArt?u=Alex&t=[REDACT> vel=debug msg="HTTP: GET http://ssh.bit-link.de:4533/rest/getCoverArt?u=Alex&t=[REDACT> vel=debug msg="HTTP: GET http://ssh.bit-link.de:4533/rest/getCoverArt?u=Alex&t=[REDACT> vel=debug msg="HTTP: GET http://ssh.bit-link.de:4533/rest/getCoverArt?u=Alex&t=[REDACT> vel=debug msg="API: New request /rest/getCoverArt" client=NavidromeUI requestId=Bit-Li> vel=debug msg="API: New request /rest/getCoverArt" client=NavidromeUI requestId=Bit-Li> vel=debug msg="API: New request /rest/getCoverArt" client=NavidromeUI requestId=Bit-Li> vel=debug msg="API: New request /rest/getCoverArt" client=NavidromeUI requestId=Bit-Li
I also have a lot of "???" Albums and see the same slowness.
I do not think its anything todo with the name, rather the shere amount of albums for that artist. The artist page isn't well optimized for hundreds of albums, thus loads very slowly and creates unresponsivness.
If i read on the website of Navidrome:
- Very low resource usage.
- Runs well even on simple Raspberry Pi Zero and old hardware setups
- Handles very large music collections
it would be a some sort of funny if 200 Albums from an artist can kill my Multicore i7 Server...
For me it looks like it runs in some sort of rate-limiting or... anything like that... or a return value is to big and the ui waits for it forever or whatever...
Is this Firefox specific? I've noticed a lot of slowdowns on Firefox, while Safari/Edge/Chrome stay responsive.
This issue has been automatically marked as stale because it has not had recent activity. The resources of the Navidrome team are limited, and so we are asking for your help.
If this is a bug and you can still reproduce this error on the master
branch, please reply with all of the information you have about it in order to keep the issue open.
If this is a feature request, and you feel that it is still relevant and valuable, please tell us why.
This issue will automatically be closed in the near future if no further activity occurs. Thank you for all your contributions.
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.