Open rphair opened 9 years ago
lazka
commented
9 years ago Thanks for the detailed bug report. I can't exactly reproduce the problem, but I see that restoring the selection with both parent and child doesn't work right, so maybe that is caused by the same problem.
rphair
commented
9 years ago you're welcome; it would be a really boring video to send a screencast of the 2 minute wait to start the window.
lazka
commented
9 years ago Multiple options:
rphair
commented
9 years ago Found what was triggering the bug! Just ran my backup for the evening & found it was backing up a never seen before, huge directory... everything "cleaned" by the broken version of bleachbit I ran had been put in a single subdirectory of my home directory.
So the "Filesystem view" of quodlibet was being forced to read this enormously sized directory, but only under the conditions that I observed. I guess a non-hierarchical selection doesn't force quodlibet to scan everything before opening up the window.
Thanks a lot for the debugging tips since they will surely come in handy, if not for this then for other Python applications. As far as I am concerned you are welcome to close this issue, since a 500-megabyte flat directory in the home dir is not likely to occur very often in nature.
lazka
commented
9 years ago I see, thanks for the update. Ideally QL shouldn't read the directory in this case so I will keep this open.
I don't know what to make of this problem; I've used quodlibet for 3-4 years on Fedora & Ubuntu & never seen this happen before. I hope I'm posting this in the right place: I don't have any experience with the source but I'm standing by to gather debugging info.
Current system: Ubuntu 14.04 & both Quodlibet versions 3.0.2 (Ubuntu package) and 3.4.1 (PPA).
I ran bleachbit for the first time which deleted loads of temporary files including image thumbnails all through the filesystem & my home directory. I didn't see anything else unusual, but the next time I ran quodlibet (Ubuntu stock version 3.0.2), which would have inherited a big hierarchical song selection from the previous run, it took 3-4 minutes to start.
I have a 7000 song database (~/Music) which I normally leave in "Filesystem View" and it always starts in a second or so, plus a small amount of time proportional only to the number of songs that may have moved or changed. What I see now: when I run quodlibet it takes about 2 minutes or so for the window itself to start. (I'm not talking about the familiar "Scanning Library" delay... this is an unusually long delay before the window even comes up.)
I've tested exiting quodlibet with different selections in "Filesystem View" & starting it again: the delay happens every time the saved selection includes both a folder and its parent. This can be only a single album and a folder that contains it, for instance. When only single folders are selected, or nothing, I don't see the delay at all (i.e., the window comes up immediately).
I have tried both reinstalling & upgrading to version 3.4.1 via the Ubuntu ppa:lazka/ppa repository, moving ~/.quodlibet so it started with a fresh configuration each time I installed it. The GNOME launcher is not starting the program with any unusual options and "quodlibet" isn't aliased to anything nor does anything non-standard precede it in the PATH. The problem occurs whether or not the option "Refresh library on start" is checked.
This is a well-conditioned desktop with a fast processor, lots of RAM and the music library on an SSD drive, in case anyone thinks it is performance related... in fact I can reproduce the problem by selecting a music folder and its child folder with 4 songs in it and I still see about a 2-minute delay before the window opens.
If I could, I would start by trying to find out what it's hanging on before the window starts, if someone could please tell me how to get some kind of debugging information. I have loved this program almost above all others so please let me know how I can investigate, or if this even sounds familiar to anyone.