You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, when adding a larger number of songs to the DB, the background threads overwhelm the disk IO queue and may even make the entire app unresponsive for a long time (tens of minutes, even). It'd be much better to centralize and serialize all disk IO bound to adding songs (hashing, tag reading, tempo detection) into a single thread that would read the disk data for each song and then send it to processing.
The text was updated successfully, but these errors were encountered:
Slight problem with this: After adding an entire folder, all the song files get read in the memory, but their hash detection is slower than the read rate, thus consuming large amounts of RAM. Would need a dedicated song scan scheduler. However, because there was no noticeable improvement in GUI reactivity, this entire task has been abandoned for now.
Currently, when adding a larger number of songs to the DB, the background threads overwhelm the disk IO queue and may even make the entire app unresponsive for a long time (tens of minutes, even). It'd be much better to centralize and serialize all disk IO bound to adding songs (hashing, tag reading, tempo detection) into a single thread that would read the disk data for each song and then send it to processing.
The text was updated successfully, but these errors were encountered: