Jump to content

music: sort albums by date added: album cover will showup with delay


plessers@gmail.com
Go to solution Solved by quickmic,

Recommended Posts

plessers@gmail.com

Hi,

Running LibreElec 10.0.3 on Raspberry 4 with Kodi and addon  "Kodi Emby for Kodi Next Gen" 7.13.1

My music library contains +/- 2600 albums (+/- 40.000 songs)

For me: the most interesting view is "albums-sorted-by-date-added".


This works fine, BUT I noticed that the album cover art is displayd with some delay....


Taking a closer look at the process, it seems that the cover art is displayed alphabetically, meaning that an the cover art of album with name "zzzz" is showed much later that album with name "aaa".
This is not noticeable in a "normal" view, because the default sortorder is alphabetically.
However, If you sort the albums by "date added", it looks like the cover art is displayed randomly and it takes a while (if you have a large library) to show all covers.

To speed up things I already tried to enable local cache. ANd my LibreElec is  running on a fast SSD on the USB3 port  (+/-200Mb/s).
On the emby webinterface, I can not see this behavior: cover art of albums sorted on "date added" shows up immediately.

So I'm afraid that this is a KODI issue, but maybe somebody has some workaround for this......

 

 

Any help is appreciated!

 

kind regards,

Bart

 

 

 

 

Link to comment
Share on other sites

quickmic
16 hours ago, plessers@gmail.com said:

ANd my LibreElec is  running on a fast SSD on the USB3 port  (+/-200Mb/s).

 

That's a wise decision. I hope you have installed complete Kodi on the SSD and not just outsourced thumbnails etc. Most performance boost can be expected when Kodi's databases are located on a fast device. Also the thumbnails can benefit but mostly the databases.

Ultimate would be databases on a ramdrive, but this is tricky and not very reliable (powercuts).

 

Quote

To speed up things I already tried to enable local cache.

You mean you cached all artwork via plugin menu? That's so good choice, if not, try it.

Quote

Taking a closer look at the process, it seems that the cover art is displayed alphabetically, meaning that an the cover art of album with name "zzzz" is showed much later that album with name "aaa".
This is not noticeable in a "normal" view, because the default sortorder is alphabetically.
However, If you sort the albums by "date added", it looks like the cover art is displayed randomly and it takes a while (if you have a large library) to show all covers.

I'll have a look into that, but usually these are Kodi's internal functionalities.

 

Last but not least, Kodi skin can have a big impact on performance. Especially if you use other nodes than next-gen custom ones (those are optimized for performance).

Custom skin nodes maybe good, maybe bad. It depends. Kodi't stock nodes are usually fast, but doesn't take care about multi-libraries. -> read FAQ here.

Also some skins loading xsp playlists in the background. Big performance issue, I always "disable" them in my skins.

Edited by quickmic
Link to comment
Share on other sites

plessers@gmail.com

Hi @quickmic, thanx for taking the time for this. Much appreciated

 

Quote

 I hope you have installed complete Kodi on the SSD and not just outsourced thumbnails etc.

Indeed, RPI4+bootable SSD

Quote

You mean you cached all artwork via plugin menu? That's so good choice, if not, try it.

correct, that's the setting I used:

image.thumb.png.5aa90a32ef1d3a33bdd86ed2f26c834d.png

 

Quote

Especially if you use other nodes than next-gen custom ones

Problem is that net next-gen does not offer "show all albums, sorted by date added". There is a node "recently added albums", but this view is limited to 25 albums.

 

 

Quote

Kodi't stock nodes are usually fast, but doesn't take care about multi-libraries. -> read FAQ here

For testing now, I used the out-of-the-box "Estuary" skin. I will experiment with some others, but don't expect much improvement from there

 

Quote

I'll have a look into that, but usually these are Kodi's internal functionalities.

Much appreciated!

 

Meanwhile, I will do a test with the library stored local on the SSD and let KODI index and display this. See If the issue remains there and I will post something on the KODI forum than.

 

kind regards,

Bart

 

 

Link to comment
Share on other sites

quickmic
1 hour ago, plessers@gmail.com said:

Problem is that net next-gen does not offer "show all albums, sorted by date added". There is a node "recently added albums", but this view is limited to 25 albums.

You can remove the limit in the xml file. -> somewhere in ./userdata/library/music/emby_music_Music/recentlyaddedalbums.xml

Link to comment
Share on other sites

plessers@gmail.com

ok, thanx for that info, I will take a look into that. But expect that the same rendering latency will occur.

Meanwhile, I tested following

  • removed emby-next-gen addon
  • copied my music files to the local SSD of LibreElec
  • added the  local music files to music library
  • indexed the music library in KODI
  • select view "albums", sorted by "dated added" (descending)

No problems with this setup: all albums covers are displayed immediately without delay!
(I must say that I couldn't copy all of my music files due to limitations of the SSD, but still there are +/- 1.000 albums with +/- 14.000 songs)

 

So for now it seems that the rendering order

  • is alphabetically when using emby-next-gen, meaning that the first album showed (=most recently added album) is not necessarily rendered first (rendering runs alphabetically)
  • is by first-displayed when using native KODI library, meaning that the first album showed (=most recently added album) is rendered first, thus no latency in cover art

 

So to me it seems an issue of the combination of addon with kodi...

 

kind regards,

Bart

 

 

  • Like 1
Link to comment
Share on other sites

plessers@gmail.com

I'm afraid I do not understand your question fully....
But

  • latest test: no addon at all, Just KODI with local library
  • first test: addon, with emby-next-gen addon, with following options when started:

image.thumb.png.954850cc7cfb2acd60e620c5ef578ece.png

 

image.thumb.png.e46bac088be033e47ceb4e07843714ef.png

Link to comment
Share on other sites

quickmic
10 minutes ago, plessers@gmail.com said:

I'm afraid I do not understand your question fully....
But

  • latest test: no addon at all, Just KODI with local library
  • first test: addon, with emby-next-gen addon, with following options when started:

image.thumb.png.954850cc7cfb2acd60e620c5ef578ece.png

 

image.thumb.png.e46bac088be033e47ceb4e07843714ef.png

First screenshot tells me, you are using 6.X. Why?

2nd screenshot, yes that's what I was asking for.

Edited by quickmic
Link to comment
Share on other sites

plessers@gmail.com

my fault. On my production environment (Raspberry) I'm running the correct version, this was indeed an old version on my dev environment on a windows box for making the screenshots.

So I started all over again:

  • removed kodi config "C:\Users\xxxxxx\AppData\Roaming\Kodi"
  • started kodi
  • added repository "plugin.video.emby-next-gen-7.13.5.zip"

image.png.85849940ac998ada8efc6bab21a941f1.png

 

image.png.5eb0c0f25ca8a1302c6fde66c94cb575.png

 

  • I selected the music library to sync
  • reconfigured the addon:

image.png.bd5b5e694d50cee8e605a40364ae53e2.png

  • after caching, problem still exists.

 

grtz

B

 

 

 

 

Link to comment
Share on other sites

quickmic

I performed several tests. Yes I can confirm, the Album artwork seems to be loaded alphabetically (or other order), but there is no difference with stock Kodi on my tests so far.

Have you tested with the SAME number of albums. Cause Kodi has performance issues on large lists (which usually appears on music content).

Means a proper comparison is only valid with the same number of albums.

 

Edited by quickmic
Link to comment
Share on other sites

quickmic

Another question, What's the usual size of you album covers? I could imagine, Kodi uses images with lower resolution and therefore has much lower loading time (but the same loading order). Probably it uses the so called "preview" images. Such artwork type is not available yet when artwork comes from Emby.

Edited by quickmic
Link to comment
Share on other sites

quickmic

I performed several tests. Smaller images, disable some options via advancedsettings.xml, disabled music scrapers, disabled autoplay next songs. Still nothing.

I think this is, as mentioned, an issue due to large lists and I would be very surprised if stock Kodi is faster under same conditions/metadata.

Unfortunately this is a design flaw of Kodi, I reported that years ago but probably never been fixed.

That's why I limit large list in the custom nodes wherever it makes sense. e.g. Browsing artist ist also quite slow, that's why the A-Z artists node is recommended to use.

I also wrote a workaround for songs by genre. The stock Kodi (genre) node is also very slow here.

Let me know, if you figure something out, find any pattern.

 

You could try to modify the music (custom) nodes (xml files) -> adding the sort order directly there. This loads the list following the xml order, ergo -> the artwork loading should also follow those parameters. BUT it will not boost the loading time in general, just how it's loaded.

Edited by quickmic
Link to comment
Share on other sites

plessers@gmail.com

Hi @quickmic,

Thanx for all your effort!

 

Quote

the Album artwork seems to be loaded alphabetically (or other order),

Good news that we can reproduce this.

 

Quote

but there is no difference with stock Kodi on my tests so far.

I did a new test, now running on my window box.
Setup

  • Windows 10 ("mediaserver"), serving a share "\\mediaserver\MEDIA" and some subfolders containing music: "\MUZIEK\collectie"
  • emby server running on "mediaserver". Music library pointed to share  "\\mediaserver\MEDIA\MUZIEK\collectie"
  • KODI running on "mediaserver"

 

Test 1

  • kodi, music library pointed to "\\mediaserver\MEDIA\MUZIEK\collectie"
  • view: musicalbums, sorted by date added
  • result:

 

Test 2

  • kodi, with emby-next-gen 
  • view: musicalbums, sorted by date added
  • result:

 

So noticeable difference between OOB and ADDON (with same library, network, kodi, etc...). Out-Of-the-Box version is much faster with same amount of songs/albums

 

 

 

Quote

 What's the usual size of you album covers?

Max 600x600 pxl. Every song contains the cover of the album.
 

 

Quote

I think this is, as mentioned, an issue due to large lists and I would be very surprised if stock Kodi is faster under same conditions/metadata.

See above: same list, same environment, same metadata, but noticeable difference...

 

 

Quote

You could try to modify the music (custom) nodes (xml files) -> adding the sort order directly there. This loads the list following the xml order, ergo -> the artwork loading should also follow those parameters. BUT it will not boost the loading time in general, just how it's loaded.

I'll give this a try in the weekend. Can you point me to the location of the XML?

 

 

What also surprises me:

image.png.d2cd87d3f45b19644fbde1a554b5d2a3.png

If I use the cached setup, I have almost 4GB on local storage, but no improvement on dispay. The oob version "Kodi.19.5.music.network" (network because it's configured to get the files from a network drive and not from the local disc) is the fastest even without caching....

 

Edited by plessers@gmail.com
Link to comment
Share on other sites

quickmic

Thanks for the test, I'll review them carefully.

One more thing you probably not aware of. There is no toggle cached or no cached artwork.

Selecting artwork cache in the plugin menu starts a download process in the background. While it's running, the option is grayed out and there should be a progress bar visible.

This can take quite long depending on the number of artworks. If you interrupt this process (e.g. shutdown Kodi), you have to re-trigger this option. Already downloaded artwork will be skipped by default (unless you select remove existing artwork).

So you need to wait till everything is downloaded, probably just select the album covers. Would be faster than loading everything.

 

btw.

If the cache process is running, it's quite natural that the artwork is slow! The download process can consume the complete network bandwidth.

Edited by quickmic
Link to comment
Share on other sites

quickmic

Additional info about caching.

Stock Kodi (and the plugin as well) uses Kodi's internal caching mechanisms. Let me elaborate.

Kodi always caches artwork (on demand) means, if an artwork was shown once it's cached. The only difference using the cache option in the plugin is pre-caching (not on demand). It caches/downloads everything even so far not used by Kodi.

 

Link to comment
Share on other sites

quickmic
2 hours ago, plessers@gmail.com said:

I'll give this a try in the weekend. Can you point me to the location of the XML?

 

 

23 hours ago, quickmic said:

You can remove the limit in the xml file. -> somewhere in ./userdata/library/music/emby_music_Music/recentlyaddedalbums.xml

All nodes are located here. For all albums -> albums.xml

Just modify it

default:

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<node order="7" type="filter">
    <label>Albums</label>
    <match>all</match>
    <icon>DefaultMusicAlbums.png</icon>
    <content>albums</content>
    <rule field="type" operator="is">719641-Music</rule>
    <order direction="descending">albums</order>
    <group>albums</group>
</node>

try:

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<node order="7" type="filter">
    <label>Albums</label>
    <match>all</match>
    <icon>DefaultMusicAlbums.png</icon>
    <content>albums</content>
    <rule field="type" operator="is">719641-Music</rule>
    <order direction="descending">dateadded</order>
    <group>albums</group>
</node>

the order parameter.

However, I think you need to dig into that matter (those are Kodi standard node functionalities, nothing plugin specific). The plugin just pre-configures some nodes.

https://kodi.wiki/view/Video_nodes

The stock audio nodes from Kodi uses a different approach (database parameters), but if you use the same one you lose multi (audio) library support (which is not supported by Kodi).

 

Edited by quickmic
Link to comment
Share on other sites

plessers@gmail.com

Hi 

 

Quote

If the cache process is running, it's quite natural that the artwork is slow!

This was not the case. I waited till everything was settled.

 

 

Quote

You can remove the limit in the xml file. -> somewhere in ./userdata/library/music/emby_music_Music/recentlyaddedalbums.xml

OK, I modified this, but it does not have any effect

image.png.5b0a58a7fa943e934438011fd99279af.png

 

 

Quote

All nodes are located here. For all albums -> albums.xml

My config is now

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<node order="7" type="filter">
    <label>Albums</label>
    <match>all</match>
    <icon>DefaultMusicAlbums.png</icon>
    <content>albums</content>
    <rule field="type" operator="is">301221-MUZIEK</rule>
    <order direction="descending">dateadded</order>
    <group>albums</group>
</node>

but this doesn't make any difference

 

Quote

Do you use Kodi 20?

Nope, KODI 19.5.0 (2022-12-24)

image.png.515a5dbc1524f052bc0f9bcd850e8b65.png

 


 

Link to comment
Share on other sites

quickmic

Ok, I'm still optimizing artwork code. Reason I asked for Kodi 20, My current dev version runs only under Kodi 20 (plugin version 8.X)

Backports to Kodi 19 (7.X) will take quite a while...

  • Like 1
Link to comment
Share on other sites

plessers@gmail.com

I can test with Kodi 20 if you want.

However, my production environment will be OpenElec. As long as they will stick on 19.4, I'm stuck...

Link to comment
Share on other sites

quickmic
7 hours ago, plessers@gmail.com said:

I can test with Kodi 20 if you want.

However, my production environment will be OpenElec. As long as they will stick on 19.4, I'm stuck...

I'll backport at least the artwork changes. I'll send you a test version via PM as soon as finished.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...