View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0007876 | MMW v4 | Playlist / Search | public | 2011-05-25 18:40 | 2011-09-14 22:36 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | minor | Reproducibility | sometimes |
| Status | closed | Resolution | fixed | ||
| Product Version | 4.0 | ||||
| Target Version | 4.0 | Fixed in Version | 4.0 | ||
| Summary | 0007876: Focus problems in the quicksearch bar | ||||
| Description | The search bar sometimes changes by itself from whatever text the user is currently typing (in black) to 'Current Collection' (greyed out). e.g. 1 click music node 2 click search bar 3 Type 'If I knew' -->'Current Collection' appears in grey with the cursor positioned at the 9th character 4 Type 'Love' (i.e. the rest of the search term) -->Search term is 'Current CLove' (in grey instead of black)! I can't figure out exactly what causes this to occur--it doesn't occur consistently. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1390 | ||||
|
|
I tested this for half an hour and I haven't been able to reproduce the problem. Nevertheless I added a prevention in build 1381 that should prevent from possible problems like this. |
|
|
On occasion MediaMonkey hangs after typing If (not always), while hanging any characters typed seem lost, then when coming out of hang it will have If selected and any subsequent typing will wipe the If. |
|
|
I can't seem to reproduce, but just for sure, do you mean the 2 seconds long freeze between 108.505 when you typed "if" and 110.685 when you continued typing "if a" in the debug log? I was able to reproduce the two seconds long UI freeze when I slowly continued typing "if a a a a a a a a a a a a a". This way it seems to be consistently reproducable. BTW: It seems that you have some non-default fields like Comment, Lyrics enabled in Options->Search panel therefore the filling of search results is slower for you because of the additional SQLs: "SELECT Lyrics, Comment FROM Songs WHERE Songs.ID=?" but this most probably isn't related to the 2 seconds long UI freeze. |
|
|
Fixed in build 1383. |
|
|
Yes, the interface actually hung (standard windows titlebar appears instead of skinned one). And yes, for testing I have pretty much all fields enabled, but results load fairly quickly though. |
|
|
Re-opening--Petr indicated that he had to revert the fix due to a critical regression. |
|
|
Fixed in build 1384. |
|
|
Testing on 1385 by typing continuous aaaa's I still get a long hang, after which typed search text is highlighted (thus new typing would overwrite it. |
|
|
Fixed in build 1386. |
|
|
I still see the same on 1388. |
|
|
Martin, your MM.DB is in a network location, isn't it? This is probably the cause why I cannot reproduce with your DB as I use it from local HDD. Nevertheless the problem is on the DB layer when it is trying to open several SQLs queries (from several threads) where each takes several seconds and needs to be performed in the critical section. We can improve it to the future by reviewing the DB layer and we could for example try to terminate opening SQL that is waiting just because of the SQLiteLock while its thread has been already terminated. But it seems to be too risky to do something about it at this point, what do you think, Jiri? |
|
|
Fixed in build 1390. - Added terminating of unneeded background queries, which should prevent sluggish MM reactions. |
|
|
Yes I have the DB on a network location. |
|
|
On 1390 there is no longer a hang when typing continuous aaaaaaaa, but if you press a key and hold it depressed it will show the first letter and then take a moment and show you a whole set of characters instead of continuously adding characters while the key is depressed. |
|
|
I can't reproduce. I don't think we can do any better anyway. Btw, it should be better than MM 3.x, isn't it? |
|
|
Verified 1432 Much faster than in MM3 1307 |
