GNOME Bugzilla – Bug 351315
Search begins instantly after typing only 1 letter and is slow
Last modified: 2007-08-18 13:41:52 UTC
Please describe the problem: This is a bit general, but the search function is not very practical when dealing with a large library (9000+ songs in this case). If a user is for example searching for "Beck" the program begins to search as soon as the user has typed B. Since this search will produce a lot of hits there is a delay before "eck" appears in the search box and then an even longer delay before the results are displayed. I don't code so I'm not exactly sure how this is implemented, but I've played around with the interface in order to deduce what is doing on. The way this should probably work is to have the program wait a fraction of a second to see if the user is still typing and only after a short pause in the typing the program should go ahead and search for results. Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information:
This was fixed in CVS on 7/26. Look for it in the next release. *** This bug has been marked as a duplicate of 348274 ***
I'm building from CVS downloading the code with the following command: $ cvs -z3 -d:pserver:anonymous@anoncvs.gnome.org:/cvs/gnome co -P banshee Using that command I compiled banshee on 8/14, after the patch is supposed to have been applied, but I continue to see this bug. I may be doing something stupid.
If you type your search somewhat quickly, it won't start searching right away - it will wait until you pause. If you're not seeing that, make sure you are actually running your CVS version.
I've double checked now and my CVS versión is from August 14th. The only way I was able to get it to start searching on "Beck" is to paste it into the search box. I'm a fairly decent touch typer but I'm been unable to get past "Be" while typing as I normally do. Something like "Miles Davis" would be futile. Maybe the pause time could be increased? BTW I'm sorry for pestering about these issues, it's the first time I've started reporting bugs in a project such as this.
This is a persistent problem for me as of v0.11. Any changes to the search field regularly cause banshee to hang for significant periods of time (usually several minutes). Any song already playing continues until its end but no other track is played until banshee "returns".
I noticed a slowdown when the new click-to-rate code was committed. But I think this will all be solved when the new view/model stuff goes in. Is that right Aaron?
I'm experiencing the hanging that this problem describes. I have 23,000+ songs in Banshee. When I start typing in the search field I can get a few letters typed and then it locks up the search field. The search field should never restrict input. It should allow the user to type after a pause or some amount of letters, let say 3, the event should start a separate thread to filter the view so that the user can continue typing. I'm using the 0.12+ SVN HEAD code.
Created attachment 86406 [details] [review] First attempt. Alpha quality. There are some known issues with this patch. I'm also posting to banshee developer list for feedback. The main issues I see are: - switching active source - cpu utilization; need to kill superseded threads to prevent higher cpu usage - I'm see an occasional gui lockup. I need to figure out what is happening there.
Created attachment 86470 [details] [review] Updated my first attempt. I spoke with Aaron today about this issue. He stated that I should try to do it with only one extra thread, which is what I wanted to do in the first place. He suggested that I use locks/mutex objects to keep the threads in sync. He also suggested that I not build an extra array of tracks in the search thread to save on memory use. I can see his point there, but it's just an array of references so I'm not sure how much difference it would make. I attempted to use delegates tonight to arrange for only one worker thread at a time, but I couldn't get it to work. I was using a Windows C# tutorial that just didn't work under Mono. I'll try again later. For now, I've fixed the issues with changing playlists. This patch works ok for now. It can use a lot of processor and memory, but it works better than what is checked in to HEAD (IMO). I prefer high CPU and memory usage to lockups any day. :-)
This works fine for me in SVN build, checked out yesterday--it waits until I stop typing to start the search.
I think the problem is not with system resources. Searching works good when you type at least 3 chars (12k songs here). Disabling searches of 1 or 2 chars is quite common thing in applications.
No worries everybody, we're going to drop the "3 letter minimum"-restriction and make searching lightning fast when the new list view lands. For those who want to check it out, all the code is in the list-view module in banshee subversion. Oh and it'll use less CPU too. Aaron is a wizard, send him beer.
fixed in the new list-view.