MediaMonkey forum

Hi

I've had this minor problem several times now, but only now have DbgView running to capture it. The problem does not happen every time, but does occur about once a week with steady use.

Here's the sequence of events:

• Working with the Main List in All Files with a sorted list format.

• Open a new tab

• Type a targetted search in the search box at top right, eg artist: James Taylor, and press Enter.

• Normally the search text gets replicated in the tab, but now the tab shows a pair of double quotes, ie "", indicating a null string.

• The search finds nothing, yielding a list with no tracks, even though the text of the original query is still present in the search box.

• Returning to the search box and pressing Enter again yields the same null search result.

Fixing this is simple - return to the edit box and change the search string, eg artist: Taylor. The tab name is now populated and the list returns all of James Taylor's tracks, along with a couple of other Taylors.

Repeating the search with the original search text, ie Artist: James Taylor, now works correctly with the tab and list populated.

So, this is just an inconvenience but detracts from the perceived stability of product and should be fixed in slow time. The DbgView log is available if you want it.

Cheers

Matt

Which Build (Help > About) of MediaMonkey are you using?

Does this require multiple tabs and if so, does it matter what's in the other tab. I've not been able to reproduce on 3049, not have I seen this in the past.

EDIT (Rusty): I can't replicate this either Can you confirm what 'Search mode' is configured (Options > Library:Search) ? (note: a screen capture showing the bug might be helpful)

Ticket #7530: "Search returns Null Result" submitted. Ticket has both the DbgView log and a screenshot showing the search text at the top right and the null search tab at top left.

Builds are 3044 for the log and 3049 for the pic (taken later)

Yes multiple tabs, generally about 8. I can't tell whether it depends on what is in the other tabs, but in my case most of those will also be the result of a top right search. The text for the search that failed in the pic was "Artist: Clearwater". Note that in this specific instance (and as in others), simply adding a space character to the text of the query at top right made it work correctly.

Search mode options are:

• ignore diacritics/Match beginning of words

• Show results only after pressing enter

• When typing in a view: Filters matches

• Search fields Artist, Album, Album Artist, Title, Original Artist

Cheers

Matt

Thanks! I still can't replicate, but we're looking into the log.

-Rusty

OK, I've got a sequence that reliably reproduces both the original plus a new issue.

To reproduce a null search:

• See pic "Start state", four tabs in main list: at left is Entire Library > All Files, then three other tabs, each with a subset of All Files filtered by a search in the top right search box, in my case "artist: James Taylor", then "artist: clearwater revival", and "artist: rickie lee".

• Click on + to get another tab. Sometimes that copies the filter from the previous tab, sometimes it shows All Files, I can't tell which and when. Click on the All Files subnode(?) of the Entire Library node, and turn off Column Filter if it shows.

• In the new tab showing all files, click in the top right search box to filter for another artist name, eg "artist: purple". A null search is returned for the new tab, with the tab title showing "". See pic "Null List" showing the entered search text versus the null title of the tab.

• Click in the search text box and press enter again, same null result.

• Click in the search text box and make any edit, including say a trailing space to the artist name, and the search works properly.

Observations:

• Note here that I have used lower case for "artist:" - to my limited testing this appears to be a factor - "artist: xxx" can yield a null whereas "Artist: xxx" seems to work properly.

• This seems to be more of an issue early in a open mm / do stuff / close mm cycle. I reproduced the issue about 5 times in a row first up and then it just started behaving normally.

And here's the second search issue, which I just found today:

• With the new tab for which the search had mis-behaved, click on All Files in left panel to remove the filter, see pic "All Files again ...".

• Click on the search tab to filter this All Files list again for another artist, eg "artist: led".

• The new issue here is that the tab and file list reflects the previous search for "purple", not the new search for "led"

• Editing the search text by say adding a trailing space ie "led " causes the search to work correctly again.

• Even after the null result problem started disappearing, this "previous search" problem remains. Its not hard to overcome - just add a space to the search text, but it is annoying.

Note the display issue in that last pic - the screen fails to automatically populate the last fifth of the list space unless I click in there, and has done so for the past several versions. That's not fatal and is easily overcome and so I ignore it, and it isn't the issue being reported here.

If you still need a screen video then I'll have to look into how to do that.

Cheers

Matt

Hi Matt,

Thanks for the detailed steps and screengrabs. Unfortunately, I'm still unable to replicate either issue (and I've tried many times and with many variations)

If you're willing to spend a bit more time on this, I'd suggest:
- Recording a video of this (using the latest debug build). A great free tool is sharex
- Running dbgview in the background to collect a debug log as you do this

Also, one point of clarification: when you click '+' to add a new tab, MediaMonkey generates a copy of whatever Tab was previously in focus.

Thanks for all of your efforts!

-Rusty

Hi Matt,

Is this issue resolved in the most recent builds? I see that the ticket was closed and that you're satisfied with the resolution, but didn't see a confirmation from you that it's no longer occurring.

Thanks!

-Rusty

Hi Rusty,
Currently on 3061. Might have seen one instance but that was more than a week ago and to a first approximation it is working as expected, and if anything faster than it has in the past.
Will let you know if it reoccurs.
Cheers
Matt