lazka
commented
7 years ago I often stream music off the (slow) disk on a device in my network, or over internet even, by mounting it as an sshfs. Obviously reading from this file system is slower than reading from a local file system. I get a bandwidth of around 3 MiB/s. That’s not a lot, but for streaming music it is plenty.
Now there are a few issues:
- The application is extremely slow to start up, and during startup no window is painted. The time between starting the application, and the moment the window appears, is ~10 minutes. This is with the “Scan library on start” option disabled in the preferences. My library contains about 10k songs and weighs around 300 GiB. I’d hope that Quod Libet doesn’t need to read much of this data just to get a window on the screen. (I am fine with cover art appearing later on demand, and library updates taking place in the background.) For reference, running
duorfind .in my library (mounted as sshfs) — operations that access the metadata of every file — takes about 20 seconds. Slow, but not the minutes Quod Libet is taking to start. When I look at the process in htop, I see that the application is blocked on disk IO for long streches of time (~a dozen seconds), then runs briefly, and goes back into being blocked on disk IO.
Which browser is active? Does it change when using the simple search browser
- I occasionally experience stutter during playback, or even dozens of seconds of silence. I have already set the buffer duration to the maximum value in the playback preferences, but I am not sure whether that applies to readahead from disk, or buffering decoded output samples.
yeah, buffer duration only applies to http streaming. One thing you can do is write "queue" in the "Output pipeline" entry. That will add some additional buffering.
- Even when loaded, the user interface occasionally locks up completely for a few seconds. Furthermore, scrolling through the album list is not smooth when album art has not been loaded yet.
We do some IO in threads, but not all of it.
The last two points are annoying every now and then, but I think these are an acceptable consequence of using a slow file system. Better performance (especially avoiding stutter in playback) would be nice to have. The first issue is quite annoying however. Once Quot Libet is loaded, it runs quite smoothly apart from the occasional hiccup; playback is starts quickly and browsing the library and searching are all responsive (after I have scrolled through the album list once to load the covers).
I am not familiar with the internals of Quod Libet, but my guess is that the application is doing blocking IO on the thread that is also responsible for UI operations. Ideally all IO would be async, but that would be a large and invasive change to an existing application. And to be fair, even with slow disk IO the application is still “responsive enough” most of the time. However, I hope that startup time can be improved. Is the application perhaps accessing more data than it needs to? Or could some operations be delayed until after the UI has been fully initialized?
Please let me know if there is anything I can do to further diagnose the problem. I would also be happy to try and work on a fix if somebody can point me in the right direction.
Please run the following command python2 -m cProfile -o prof.out $(which quodlibet). Wait until QL settles and quit the program. This should result in a file "prof.out" being generated which you can send me (reiter.christoph@gmail.com)
declension
ruuda
I often stream music off the (slow) disk on a device in my network, or over internet even, by mounting it as an sshfs. Obviously reading from this file system is slower than reading from a local file system. I get a bandwidth of around 3 MiB/s. That’s not a lot, but for streaming music it is plenty.
Now there are a few issues:
duorfind .in my library (mounted as sshfs) — operations that access the metadata of every file — takes about 20 seconds. Slow, but not the minutes Quod Libet is taking to start. When I look at the process in htop, I see that the application is blocked on disk IO for long streches of time (~a dozen seconds), then runs briefly, and goes back into being blocked on disk IO.The last two points are annoying every now and then, but I think these are an acceptable consequence of using a slow file system. Better performance (especially avoiding stutter in playback) would be nice to have. The first issue is quite annoying however. Once Quot Libet is loaded, it runs quite smoothly apart from the occasional hiccup; playback is starts quickly and browsing the library and searching are all responsive (after I have scrolled through the album list once to load the covers).
I am not familiar with the internals of Quod Libet, but my guess is that the application is doing blocking IO on the thread that is also responsible for UI operations. Ideally all IO would be async, but that would be a large and invasive change to an existing application. And to be fair, even with slow disk IO the application is still “responsive enough” most of the time. However, I hope that startup time can be improved. Is the application perhaps accessing more data than it needs to? Or could some operations be delayed until after the UI has been fully initialized?
Please let me know if there is anything I can do to further diagnose the problem. I would also be happy to try and work on a fix if somebody can point me in the right direction.
OS: Arch Linux with Gnome 3.22, kernel 4.7.6. Quod Libet: 3.7.1 installed from the Arch repositories.