Artists are not shown if `get_art` for an artist returns HTTP 404

[paulijar]

If the Nextcloud Music backend has no art available for the target artist of action=get_art, it returns the HTTP error 404. When this happens, the Kodi Ampache plugin 2.0.1 fails to show any artists.

Now, returning HTTP 404 is the correct behavior in this case according to the Ampache API 5 documentation. On the other hand, the API 4 specification does not specify what should happen in this case. But testing with the real Ampache server, it seems to return an empty text file in this case (!).

Do you think that the Nextcloud Music server should be modified to act like the Ampache server, or could the Kodi plugin perhaps support also the API 5 behavior?

[lusum]

I have seen, i will check for a fix in the next days, maybe it is necessary only a sanity check without changing anithing.

[lusum]

I should be fixed, i needed to check for connection errors, btw, i have added some check to speed up the art management with old ampache api versions.

Edit: i will wait some days before send a new version on kodi repository, i will wait some tests.

[paulijar]

Thanks, works now fine with the master version. Your response time was again exceptional!

One thing, which might still require some improvement, is the performance when some of the artists have no art set. When an artist has art, you cache it on the first load and it does not require reloading the next time the user opens the artists view. But for those artists with no art set, you request the art again each time when the artist view opens. This may slow down the view opening a lot. For example, my library contain about 160 artists and maybe half of them have image art. Opening the artist view now always takes around 1 minute.

If you would cache also the information "no art", then you would still need to solve the case where the artist first has no art, but then it is added later to the library. At some point, this should be detected and the actual art fetched and cached. Maybe you could recheck the artist art from the server, when an individual artist is opened for viewing? Time to check one art is almost negligible while fetching art for many entries at once piles up quickly.

With Nextcloud Music, you could also detect the availability of the artist art from the <art> element withing the <artist> element: This element is empty if the artist has no image art. Unfortunately, this is not an universal solution since the real Ampache server gives an <art> element pointing to the default image in that case.

[lusum]

Yes, i think i will skip art retrival when element is empty, for artists and for albums. I think i will expand the possibility to disable art in settings, now possible only for big lists.

[lusum]

I have made some changes to allow faster loading of lists ( no connection if no art is present ) and fixed a bug in long artist list without images. Now the slowest part is on ampache server side ( at least for the official server ).

EDIT: i'm not so fast, the idea of make list loading faster was already in my mind yesterday, working of your bug, and today i have only implemented the code. I think that is better to program before in the mind and implement the code after.

[paulijar]

Thanks, works much better now.

However, there is still one oddity slowing down the opening of the artists view: Whenever the view is opened (and all the available artist images are already cached), the Kodi plugin still requests get_art for each artist ID having an image art set. But what's odd, these requests are made with argument type=album. The server of course does not find albums having IDs matching the artists, and all of these requests are responded with 404. The view still opens without any problems and shows all those artist images it should.

[lusum]

Whenever the view is opened (and all the available artist images are already cached), the Kodi plugin still requests get_art for each artist ID having an image art set. But what's odd, these requests are made with argument type=album

Fixed, i have also done some optimisations to avoid calling useless threads/connections, the art management should be slight faster now

[paulijar]

Nice, works great now!