Iris is slow on browsing mopidy-dleyna content, cause it to throw some exceptions and wrongly assign current folder name

I’m comparing behaviour of the Iris and musicbox_webclient during browsing mopidy-dleyna library content. I have quite large collection of artists and albums on my NAS that exposes its content trough DLNA. The structure of the library is like this (the folder level is denotet as indentation):

• MUSIC -
  • Albums
    • Some album
      • some tracks
  • all tracks
  • Artists
  • etc. basically some aagregation types
• PHOTOS - this does not matter, i’m not browsing that
• VIDEOs - this does not matter, i’m not browsing that

The result of comparison is that musicbox_webclient is blasing fast and does not make any issues, while Iris is very slow and causes some exceptions rasing in mopiyd-dleyna backend (this is propably issue in mopidy-dleyna itself).

I put some debug logs into mopidy-dleyna to see what kind of LibraryProvider actions are triggered while stepping trough the folders. For example entering the first level of folders (the one with MUSIC, PHOTOS, VIDEOS) I see that Iris is sending theese requests: mopidy.backend.LibraryProvider.lookup mopidy.backend.LibraryProvider.browse mopidy.backend.LibraryProvider.get_images

While musicbox_webclient only: mopidy.backend.LibraryProvider.browse

in the case of Iris, mopidy.backend.LibraryProvider.lookup takes 0.5s which is 20x longer that mopidy.backend.LibraryProvider.browse and it makes mopidy-dleyna to fetch list of metadata of all the music content on the NAS (i think). And the name of the current folder (the name at the bottom) is set to the name of the album of the first item in the fetched list, which is not what the current folder is (Should be the name of the dlna server ?)

mopidy.backend.LibraryProvider.get_images is taking more than 10s but it seems that it is done in the background so it is not the issue. But calling this request at the root of mopidy-dleyna browsing library (where the list of dlna servers should be) causes mopidy-dleyna to raise an exception:

dbus.exceptions.DBusException: com.intel.dleyna.OperationFailed: Unable to parse results of search: Empty 'DIDL-Lite' node in the DIDL-Lite XML:
<DIDL-Lite xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:upnp="urn:schemas-upnp-org:metadata-1-0/upnp/" xmlns:dlna="urn:schemas-dlna-org:metadata-1-0/" xmlns:arib="urn:schemas-arib-or-jp:elements-1-0/" xmlns:dtcp="urn:schemas-dtcp-com:metadata-1-0/" xmlns:pv="http://www.pv.com/pvns/" xmlns="urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/"></DIDL-Lite>

In contrast, musicbox_webclient is calling only browse while entering the folder of folders, and when entering the folder of tracks (album) it calls lookup for all files in the folder (one lookup for single file), and get_images for the album.

It seems like fetching metadata of all the audio tracks for every folder level is not necesary and is causing noticable delay. also calling get_images for resources that are not albums also seems not necesarry. At least for my nas server fetching images is very long > 10s.

The other issue with get_images is that I think that to enter next folder level, Iris is waiting for the current level to finish fetching images. So I cannot step trough folders quickly. For example when I go into the Albums folder where there are all of the albums I have, then fetching all the albums images takes very very long and Iris frontend is rising timeout errors:

app.min.js?v=1605864990:116 Uncaught (in promise) Error: Request timed out
    at app.min.js?v=1605864990:116
    at r (app.min.js?v=1605864990:116)

To Reproduce

• install iris and mopidy-dleyna
• reparse some dlna media server with audio tracks
• click on the Browse -> Digital Media Servers -> your server
• start browsing the folders

Expected behavior stepping trough the mopidy-dleyna library folders being fast and not crashing the browsing feature

Environment details:

• OS: Ubuntu 18.04 for the client, armbian buster for the server
• Browser chrome
• Iris version 3.54.2

[mczerski]

OMG YES !!! 😄

[kingosticks]

s/PlaylistsProvider/LibraryProvider/ ?