Random on a genre or playlist takes few minutes to start !

[vincen 71]

On 11/1/2024 at 8:20 PM, Lessaj said:

When this task runs all it does is enable "Vacuum the database on the next Emby Server startup" option under the database tab. A restart is required to actually run the vacuum, which will reset this back to disabled.

Thanks @Lessajfor clarification. So I have activated it as automated task now and restarted emby. It created a library.db.old that is only 300M and main library.db has just shrunk from 1.44G to 1.4G

[Lessaj 467]

Sounds like your database is very very large, mine is closer to 350 MB, so the vacuum really just reorganizes some of the data blocks to be more contiguous (similar to defragmenting) but it sounds like the query being used is taking a long time to run. I only have about 5600 songs so if you have many thousands of items, that's a large query to process. My understanding is music entries add a lot more to the database than shows/movies do but I've never really tried to dig into it.

[Neminem 1518]

@LessajThen I guess i'm Luckey

But then again, my db is only about 500mb

 

[vincen 71]

48 minutes ago, Lessaj said:

Sounds like your database is very very large, mine is closer to 350 MB, so the vacuum really just reorganizes some of the data blocks to be more contiguous (similar to defragmenting) but it sounds like the query being used is taking a long time to run. I only have about 5600 songs so if you have many thousands of items, that's a large query to process. My understanding is music entries add a lot more to the database than shows/movies do but I've never really tried to dig into it.

well considering time it took to restart and do the vacuum compared at a regular restart, I'm thinking that I might need perhaps to do few restarts so the process can run through the whole db no ? (I have seen the limit of rows it can run through for optimisation in the Database tab).

[Lessaj 467]

I don't think it really works that way, but at the same time it doesn't hurt to try.

[vincen 71]

12 hours ago, Lessaj said:

I don't think it really works that way, but at the same time it doesn't hurt to try.

Did it few times but no real changes on size of library.db file Tempted to do the export/re-import as indicated in documentation when you get db corrupted !

[visproduction 315]

modules/common/playback/playbackmanager.js

 function updateResultSetStartingPoint

1. I noticed that Items.length value is used for shuffle code.  It looks like Items.length is just the number of items in a Playlist or other group.  The 'for' function increments i++ and goes again.  That looks reasonable.  Did anyone QA this with playlists items from different libraries in different server directories?  Could finding the next item from a different library break this?
2. Does isQueueing work for all cases?  

===

... playqueuemanager.js

{var randomIndex=Math.floor(Math.random()*currentIndex),_ref=(currentIndex--,[array[randomIndex],array[currentIndex]]);array[currentIndex]=_ref[0],array[randomIndex]=_ref[1]

var randomIndex=Math.floor(Math.random()*currentIndex)

Since The Math.random() method returns a random floating point number between 0 and 1, does that always make randomindex < currentindex?  Wouldn't that always choose the next random id to be less than the previous id.  So on a playlist of 100 items, if the 1st one is #45, than all other playback items using shuffle would pick number less than 45 and items 46 through 100 would never get played?  I think you might want to take the total number in the playlist and use that in finding randomIndex variable.
see: https://www.w3schools.com/jsref/jsref_random.asp
 

Pulling the total of items in a playlist as itemTotal, then something like this would help make sure randomIndex works for all playlist items.

var randomIndex = Math.floor( Math.random() * itemTotal)+1) 

Maybe I missed something and perhaps I am not seeing the code correctly.  It's just a quick view and some questions.  A lot of this can easily be missed in QA, if you don't really test it.  Since people have noticed issues for quite and while and it is something difficult to recreate, that, to me, sounds like a code design issue.

Hope this helps.

 

[vincen 71]

Any chance of a solution or get problem fixed ? or it just goes in the pile of all the other issues with Emby

[Luke 42077]

On 11/18/2024 at 1:32 AM, vincen said:

Any chance of a solution or get problem fixed ? or it just goes in the pile of all the other issues with Emby

Hi, we are working on it. Thanks.

[vincen 71]

On 11/28/2024 at 12:13 AM, Luke said:

Hi, we are working on it. Thanks.

Hi @Luke

3 months later and still nothing back from Emby team, either something to try or a solution to test ?? I guess it's time to find an other solution than Emby for Music

Vincèn

[Luke 42077]

Hi, I think the performance of this should be better on the 4.9 beta channel.

[vincen 71]

On 1/10/2025 at 7:35 PM, Luke said:

4.9 beta channel.

You just sell some dream as I see nothing in Changelog of the beta that indicates it could fix the problem I'll wait for it to be released but I have no hope at all !

Side problem I discovered is that if I try to restart the Emby server while someone has launched a random play on the genre, the server hangs on shutdown the status of process indicates that:

Feb 07 15:36:36 myserver emby-server[2915855]: Info LibraryMonitor: Stopping directory watching for path /medias/aaaaa
Feb 07 15:36:36 myserver emby-server[2915855]: Info LibraryMonitor: Stopping directory watching for path /medias/bbbbbb
Feb 07 15:36:36 myserver emby-server[2915855]: Info LibraryMonitor: Stopping directory watching for path /medias/ccccccc
Feb 07 15:36:36 myserver emby-server[2915855]: Info App: Disposing AuthenticationRepository
Feb 07 15:36:36 myserver emby-server[2915855]: Info AuthenticationRepository: DisposeConnection
Feb 07 15:36:36 myserver emby-server[2915855]: Info AuthenticationRepository: Closing sqlite connection
Feb 07 15:36:36 myserver emby-server[2915855]: Info App: Disposing SqliteUserDataRepository
Feb 07 15:36:36 myserver emby-server[2915855]: Info SqliteUserDataRepository: DisposeConnection
Feb 07 15:36:36 myserver emby-server[2915855]: Info App: Disposing SqliteItemRepository
Feb 07 15:36:36 myserver emby-server[2915855]: Info SqliteItemRepository: DisposeConnection

What does it mean these disposing ? Can I kill the server process safely or I'm going to destroy the db ? as it's already 20 minutes since that and nothing else happens

 

[Luke 42077]

On 2/7/2025 at 9:49 AM, vincen said:

You just sell some dream as I see nothing in Changelog of the beta that indicates it could fix the problem I'll wait for it to be released but I have no hope at all !

Side problem I discovered is that if I try to restart the Emby server while someone has launched a random play on the genre, the server hangs on shutdown the status of process indicates that:

Feb 07 15:36:36 myserver emby-server[2915855]: Info LibraryMonitor: Stopping directory watching for path /medias/aaaaa
Feb 07 15:36:36 myserver emby-server[2915855]: Info LibraryMonitor: Stopping directory watching for path /medias/bbbbbb
Feb 07 15:36:36 myserver emby-server[2915855]: Info LibraryMonitor: Stopping directory watching for path /medias/ccccccc
Feb 07 15:36:36 myserver emby-server[2915855]: Info App: Disposing AuthenticationRepository
Feb 07 15:36:36 myserver emby-server[2915855]: Info AuthenticationRepository: DisposeConnection
Feb 07 15:36:36 myserver emby-server[2915855]: Info AuthenticationRepository: Closing sqlite connection
Feb 07 15:36:36 myserver emby-server[2915855]: Info App: Disposing SqliteUserDataRepository
Feb 07 15:36:36 myserver emby-server[2915855]: Info SqliteUserDataRepository: DisposeConnection
Feb 07 15:36:36 myserver emby-server[2915855]: Info App: Disposing SqliteItemRepository
Feb 07 15:36:36 myserver emby-server[2915855]: Info SqliteItemRepository: DisposeConnection

What does it mean these disposing ? Can I kill the server process safely or I'm going to destroy the db ? as it's already 20 minutes since that and nothing else happens

 

When you shutdown, the database waits for all open operations to complete, so that is why that's happening.

[vincen 71]

Some new updates on that problem that won't be fixed by Emby.

I have recreated from scratch a music library in Emby and added in it 275 albums (5 500 tracks) and again unable to do a random in a genre -> server becomes unavaible through user interface, only admin interface is still usable, everything else is hung  and it lasts at least 15/30 minutes (usually I end up restarting emby server to get access at it back working properly.

[smrippUS 0]

As a troll comment, I just started experiencing this same behavior upgrading from version 4.8.10.? to 4.8.11.0 on a multi-cpu machine (16 core E5530 Xeon - similar to OP), running a 5.x Linux kernel.  I did notice that if I turn off Hardware Acceleration on the server, then -BAM!  I'm back to speedy performance.  One might note that at least this gen of Xeon processors is devoid of hardware acceleration, but I always imagine a day when I will install a cheap Intel Arc GPU, so I leave Hardware Acceleration on as it hasn't seemed to be a problem.  I don't know if that will help anyone else, but for me at this point, I'm setting acceleration off. (After playing with different combos of settings, a reboot seemed to clean things up nicely).

[vincen 71]

18 minutes ago, smrippUS said:

As a troll comment, I just started experiencing this same behavior upgrading from version 4.8.10.? to 4.8.11.0 on a multi-cpu machine (16 core E5530 Xeon - similar to OP), running a 5.x Linux kernel.  I did notice that if I turn off Hardware Acceleration on the server, then -BAM!  I'm back to speedy performance.  One might note that at least this gen of Xeon processors is devoid of hardware acceleration, but I always imagine a day when I will install a cheap Intel Arc GPU, so I leave Hardware Acceleration on as it hasn't seemed to be a problem.  I don't know if that will help anyone else, but for me at this point, I'm setting acceleration off. (After playing with different combos of settings, a reboot seemed to clean things up nicely).

It's probably a coincidence as Hardware acceleration is only used for video as far as I know

[smrippUS 0]

Maybe a coincidence... but I noticed in my log that Emby was attempting transcoding with the audio, and that's why I went there.  

[smrippUS 0]

Just now, smrippUS said:

Maybe a coincidence... but I noticed in my log that Emby was attempting transcoding with the audio, and that's why I went there.  

FWIW, I fumbled around with the config quite a bit and may have inadvertently introduced another issue when coming up with this solution. So, I'm willing to accept this might be a one-off that may not apply to others, though I can reproduce the issue on my server.