Home → Problems →

Search can be really slow

• Edit

Richard

23 Jan, 2023 05:29 PM

Hello Hendrik:

I've written about this before but I'm back again. Sometimes Search can be REALLY slow, and the problem is, there's no way to get out if it, which means beaTunes is effectively "locked up" for the duration.

This morning, I tried to search for a song, but I mistyped the first couple of letters, so I backed up and retyped. (I wanted to type the word "almost", but typed "alkmost", so I backed up, erasing the "tsomk" and typed what I wanted following the remaining "al" to become "almost cut my hair" (the David Crosby song). In fact, I might have erased all the way to the leading "a". I don't know for sure.

That caused beaTunes to search for about 30 minutes, and to my knowledge, there was no way to make it stop short of going into Task Manager and killing the task. And I hate to do that because I don't know how that affects the beaTunes database. I know it's working. (Image attached.)

I wish beaTunes would stop searching for what it WAS searching for when the user types something else in the Search box, and start searching for the newly input text. Otherwise, is there another way to get out of this situation? Thanks.

Specs:
Windows 8.1 (yes, I know that OS went off MS support 2 weeks ago)
beaTunes 5.2.30
folder-based library, 500,000-plus tracks... which I'm sure is the reason this search took so long, given the input
database stored on the SSD C: drive
32GB RAM, 12G allocated to BEATUNES_MEMORY

1. 1 Posted by Richard on 23 Jan, 2023 05:48 PM

   

   Update:
   The Search returned 228260 items (out of 506222), so I'm guessing those are the number of items that have an "a" or an "al" in the title? (I'm searching on Title.)

   While I was typing this update, the 228260 items went away and is now displaying the 2 tracks I was looking for. So that was another 10 minutes for all that to happen. I do realize it takes time to dump that many items from the db result table.

   It looks like it took all that time finding the "a" items even though I had tried to search for something else by that time, displayed them, then saw the new input ("almost cut my hair"), went about the process of clearing out the "a" result table (10 minutes or so), searched for the new text (which took milliseconds), and displayed that result.

   Further Update:
   Now I've been working awhile, pulling up various songs very quickly. But the most-recent one is back to churning, using a lot of CPU and taking a long time, 5 minutes and counting. This time I did not make a typo, i just typed in the title I'm looking for "psychodrama" with no errors and no back spaces, so maybe that's not a factor. I will send my log files once it returns results. (It should find just one song.)

   • Edit

2. Support Staff 2 Posted by hendrik on 26 Jan, 2023 10:54 AM

   

   Hey Richard,

   thanks for the report.

   According to the logs, what's slow is searches for single characters in title etc. (but not all). This has a technical reason.

   2023-01-23 01:41:59,220 [50309094]  FullTextSearch: Searching for for "brandy fine girl" took 7ms
   2023-01-23 01:41:59,221 [50309095]  FullTextSearch: Searching for column song.name for "brandy fine girl" took 8ms
   2023-01-23 10:06:09,714 [107637]  FullTextSearch: Searching for for "brandy fine girl" took 44ms
   2023-01-23 10:06:09,720 [107643]  FullTextSearch: Searching for column song.name for "brandy fine girl" took 49ms
   2023-01-23 10:13:21,113 [539036]  FullTextSearch: Searching for for "brandy fine girl" took 9ms
   2023-01-23 10:13:21,113 [539036]  FullTextSearch: Searching for column song.name for "brandy fine girl" took 9ms
   2023-01-23 10:40:39,848 [2177771]  FullTextSearch: Searching for for "akl" took 2ms
   2023-01-23 10:40:51,610 [2189533]  FullTextSearch: Searching for for "a" took 9459ms
   2023-01-23 11:20:23,614 [4561537]  FullTextSearch: Searching for column song.name for "a" took 2381463ms
   2023-01-23 11:38:55,898 [5673821]  FullTextSearch: Searching for for "almost cut my he" took 178ms
   2023-01-23 11:38:55,999 [5673922]  FullTextSearch: Searching for for "almost cut my hair" took 15ms
   2023-01-23 11:38:56,000 [5673923]  FullTextSearch: Searching for column song.name for "almost cut my hair" took 16ms
   2023-01-23 12:05:54,218 [7292141]  FullTextSearch: Searching for for "deja vu" took 11ms
   2023-01-23 12:05:54,221 [7292144]  FullTextSearch: Searching for column song.name for "deja vu" took 14ms
   2023-01-23 12:13:07,519 [7725442]  FullTextSearch: Searching for for "eight miles high" took 19ms
   2023-01-23 12:13:07,521 [7725444]  FullTextSearch: Searching for column song.name for "eight miles high" took 21ms
   2023-01-23 12:22:17,511 [8275434]  FullTextSearch: Searching for for "guin" took 5ms
   2023-01-23 12:22:17,513 [8275436]  FullTextSearch: Searching for column song.name for "guin" took 7ms
   2023-01-23 12:22:18,113 [8276036]  FullTextSearch: Searching for for "guinn" took 1ms
   2023-01-23 12:22:18,113 [8276036]  FullTextSearch: Searching for column song.name for "guinn" took 1ms
   2023-01-23 12:22:19,753 [8277676]  FullTextSearch: Searching for for "guinnevere" took 1ms
   2023-01-23 12:22:19,753 [8277676]  FullTextSearch: Searching for column song.name for "guinnevere" took 1ms
   2023-01-23 12:41:28,516 [9426439]  FullTextSearch: Searching for for "have you seen the stars" took 410ms
   2023-01-23 12:41:28,517 [9426440]  FullTextSearch: Searching for column song.name for "have you seen the stars" took 411ms
   2023-01-23 12:49:45,300 [9923223]  FullTextSearch: Searching for for "hero" took 52ms
   2023-01-23 12:49:45,349 [9923272]  FullTextSearch: Searching for column song.name for "hero" took 101ms
   2023-01-23 12:54:22,217 [10200140]  FullTextSearch: Searching for for "i see you" took 449ms
   2023-01-23 12:54:22,270 [10200193]  FullTextSearch: Searching for column song.name for "i see you" took 502ms
   2023-01-23 15:39:21,828 [20099751]  FullTextSearch: Searching for for "it happens each day" took 30ms
   2023-01-23 15:39:21,829 [20099752]  FullTextSearch: Searching for column song.name for "it happens each day" took 31ms
   2023-01-23 16:01:04,063 [21401986]  FullTextSearch: Searching for for "long time" took 61ms
   2023-01-23 16:01:04,084 [21402007]  FullTextSearch: Searching for column song.name for "long time" took 82ms
   2023-01-23 16:01:05,802 [21403725]  FullTextSearch: Searching for for "long time gone" took 12ms
   2023-01-23 16:01:05,802 [21403725]  FullTextSearch: Searching for column song.name for "long time gone" took 12ms
   2023-01-23 16:10:39,376 [21977299]  FullTextSearch: Searching for for "p" took 5439ms
   2023-01-23 16:28:01,487 [23019410]  FullTextSearch: Searching for column song.name for "p" took 1047550ms
   2023-01-23 16:28:23,756 [23041679]  FullTextSearch: Searching for for "psychodrama" took 2ms
   2023-01-23 16:28:23,756 [23041679]  FullTextSearch: Searching for column song.name for "psychodrama" took 2ms
   

   Since I am in the process of releasing v5.2.31, I have decided to delay the search for single characters a little bit, so that search is not triggered (as quickly) while still typing. Just FYI, currently, search is always triggered when you stop typing for more than half a second.

   Cheers,

   -hendrik

   • Edit

3. 3 Posted by Richard on 26 Jan, 2023 07:53 PM

   

   Hendrik,
   Thanks for the reply and the explanation. I do know that single letter searches will take a long time.
   I wanted to say, though, that on the last one ("psychodrama") where it started searching for just "p". I KNOW I typed that one in almost continuously (p-s-y-c-... etc). Was I just a slow typist and took 501 ms between the "p" and the "s"? I didn't think so, but maybe.
   I think the 1 second delay on single-character input will be very helpful.
   The problem on "almost cut my hair" was that I made a typo "akl", I knew I mistyped, backed up to correct it (with the backspace key to the "a"), and then resumed my input as desired. There is going to be some delay between critical keystrokes in that situation. It's unavoidable. As a user, I guess the better approach would have been for me to highlight the bad "akl" input, and then type over it "almost", etc., to eliminate triggering the search on "a". That's a workaround I'll try to keep in mind, but it's unnatural.
   On "guinnevere" (which wasn't a problem), I wasn't sure how to spell the title, so I was typing more slowly. I see that it searched on "guin", then on "guinn", then on the full title. Again, not a problem since it didn't take much time.
   I still wish the user could abort an undesired search. Or, maybe a different approach would be, that you could make a change in beaTunes so that search would check for new user input every so often (maybe every 5 seconds?), and if it sees input different from what it is currently searching for, it aborts the in-process search and starts anew. Clearly, searches that take less than 5 seconds would just display the results and never hit the "check for new input" path.
   I know these are problems only your users with very large libraries encounter.
   Thanks,Richard
       On Thursday, January 26, 2023 at 04:54:59 AM CST, hendrik <[email blocked]> wrote:
    
      
   |

   • Edit

4. Support Staff 4 Posted by hendrik on 26 Jan, 2023 08:45 PM

   

   Hey Richard,

   I have released v5.2.31 today. Could you please give it a shot and let me know how the changed behavior works for you?

   Thanks!

   -hendrik

   • Edit

5. 5 Posted by Richard on 26 Jan, 2023 09:49 PM

   

   Much better, hendrik. Thank you so much.
   I started out with the title "zulu". Even when I delayed appreciably on "z" and then continued with "ulu", It didn't have a problem. The "z" search alone took about 4 seconds to display 1422 results, which is perfectly fine. Then I tried "vincent". Again, I really had to pause after the "v" for it not to let me continue with the "incent" part, which is good.
   I decided to take the plunge and do "psychodrama" again. "Psychodrama" itself comes up right away. When I typed "p", counted a long 2, then typed "s" following, it took about 6 minutes to come up with 58000 "p"-only titles, then immediately started searching for "ps" which only took a few seconds to display 330 results.
   I'm not going to try "a" and "almost" right now as "a" alone will still no doubt lock me up for awhile. But again, thanks for the change. I'm happy I made it in to the 5.2.31 release you were just about to put out.
   Richard
       On Thursday, January 26, 2023 at 02:53:48 PM CST, hendrik <[email blocked]> wrote:
    
      
   |

   • Edit

6. Support Staff 6 Posted by hendrik on 27 Jan, 2023 08:44 AM

   

   Thanks, Richard, for reporting, providing logs and testing!
   Much appreciated,

   -hendrik

   • Edit

7. hendrik closed this discussion on 27 Jan, 2023 08:44 AM.