Emby has become sluggish with music since a few months

[ryancey 55]

And it doesn't seem to improve. Has the team abandonned the music side of Emby?

Shuffling an album on the whole lib hangs forever. Remote control is flaky as hell, I stopped using it because I cannot trust it anymore. It seems like ReplayGain will never be implemented. Loading new music takes a solid 10mn before Emby aknowledge it, wrap it into an album and puts a cover. The Android app reload every now and then when it's not in focus, lose the transport when the bluetooth goes off, etc. There's a global feeling of sluggishness and regression that wasn't always here. I'm slowly loosing faith in Emby day after day for managing my music and as a media center.

These are not edge cases and it makes me wonder if the software is thoroughly tested before release? Do you think there's room for improvement here?

Can you communicate a bit more on what's planned, what are your struggles as a team, what should we expect or not, and so on? As an example you should check HomeAssistant, they're brillant on this subject.

[Luke 42079]

Hi there, we are constantly working on improving music support. Can we please look at a specific example of your issue?

How to Report a Problem

Thanks !

[Carlo 4561]

Luke, a more technical explanation for the issue is the number of rows being added to the same table used for nearly everything.  The number of rows added for a typical music CD is much greater than a movie or TV Episode. 10K movies vs 10K of music CDs makes quite a difference in rows added to the same table.

Without a normalized set of tables and indexes used for each media type, we instead have one table holding everything. The indexes are non-optimized and SQL queries require numerous self-joins that aren't able to be optimized since the query engine has to parse and create temporary tables as it runs for each part of the self-join.  Doing a query for example to find only movies still requires looking at data that encapsulates all types of data vs just movie related data that could otherwise return quickly via optimized indexing.

The affect is that a server could have a 1 or 2 second response time searching only movies but once you've added thousands of music CDs the time a movie search takes can climb to 6 or 7 seconds due to all the other data now present that the query engine needs to parse into temp tables as it runs vs having direct access to indexed tables for quick access.

So, installing any quantity of a specific media type not only affects the result times for that type but for nearly every query the system has to do making the system slower and slower as new media and its metadata is added. It's proportionally longer when self-joins are used as that creates numerous additional steps for the query engine.

[pwhodges 2012]

This suggests that a lot of music also makes the database disproportionately bigger.  This in turn suggests that optimising the database cache size is particularly important in this situation.

Paul

[tmurphy2792 27]

17 hours ago, Carlo said:

Luke, a more technical explanation for the issue is the number of rows being added to the same table used for nearly everything.  The number of rows added for a typical music CD is much greater than a movie or TV Episode. 10K movies vs 10K of music CDs makes quite a difference in rows added to the same table.

Without a normalized set of tables and indexes used for each media type, we instead have one table holding everything. The indexes are non-optimized and SQL queries require numerous self-joins that aren't able to be optimized since the query engine has to parse and create temporary tables as it runs for each part of the self-join.  Doing a query for example to find only movies still requires looking at data that encapsulates all types of data vs just movie related data that could otherwise return quickly via optimized indexing.

The affect is that a server could have a 1 or 2 second response time searching only movies but once you've added thousands of music CDs the time a movie search takes can climb to 6 or 7 seconds due to all the other data now present that the query engine needs to parse into temp tables as it runs vs having direct access to indexed tables for quick access.

So, installing any quantity of a specific media type not only affects the result times for that type but for nearly every query the system has to do making the system slower and slower as new media and its metadata is added. It's proportionally longer when self-joins are used as that creates numerous additional steps for the query engine.

So then reading this, it sounds like it's really important to have Emby installed on a fast SSD to help minimize these query/read times?
I know that one is common sense, but are there other best practices documented somewhere? I tried checking the documentation and didn't see anything.

[Carlo 4561]

DATABASE:
On the database menu set "Database cache size (MB)" to 4096 if you can spare 4GB of memory for the database to load into memory. This doesn't mean it will use that but you're allowing it to use up to that much.  As it reads things from the database it will keep a copy in memory.  This isn't saved on shutdown so it's always starting fresh on Emby Loading.

Enable "Attempt to optimize the database on server shutdowns"
Set "Analysis row limit" to 1000
If you add a bunch of media or delete media you can do a vacuum (optimize) on the database by enabling "Vacuum the database on the next Emby Server startup" and then restarting the server. On startup it will optimize the database before normal loading of the server. If it takes a while do not be concerned or try and stop the server since the dashboard doesn't load or you get a browser error. Just be patient and wait for it to finish and then load normally.  That's just a heads up, but it normally is done in just a couple minutes if that.

MAKE USE of SSD/NVMe DRIVES
If you have an SSD or NVMe drive it's best to install Emby Server on this so everything including the database and logs are here. If you can't reinstall Emby Server on a SSD/NVMe drive or if you have 2 SSD/NVMe drives you can change the location of certain paths.

Setting menu: Cache path
Transcoding Menu: Transcoding temporary path
Conversion Menu: Settings Tab: Temporary file path

Library menu: Advanced Tab: Metadata path (make a copy of this location) After you change this to a new location, copy the contents from the old location to the new location. Compare the locations carefully to see if Emby Server created a folder called "metadata" .  Give it a name without "metadata" so you don't get a metadata\metadata folder.

Live TV Menu: Advanced Tab: "Movie recording folder" 
Live TV Menu: Advanced Tab: "Series recording folder"
For both of these on the latest versions of Emby Server you will first create a location on disk for DVR Movies and another location for DVR Series. Create these areas on your SSD/NVMe drives. Next you create 2 new libraries, one for DVR Movies (type set to Movies) and one for DVR Series (type set to TV Shows). Once the libraries have been created you can select these new libraries for the Live TV recorder folder entries above.  There is another option on that path "Default recording folder" which you will leave blank.

NOTE: you will need to set proper permissions on any folders created for these locations so Emby.

Those are the main things you can do to improve performance.