MediaMonkey forum

1 Ensure search options has Album ticked
2 Quick search for "-" (including quotes, for exact match)

Expected (here): tracklist shows the many tracks having "-" in Album
Observed: tracklist blank.

EDIT(TC) Tracked at http://www.ventismedia.com/mantis/view.php?id=6840

This is actually correct as it's a misunderstanding of the double quotes query. A double quotes query means the results have to have an exact field match, not be part of the field. So in your example only albums that would be called - would be returned.

In your case as previously described on the forum you should be able to search for - itself and have all albums returned that include -. This as it was suggested to allow single character searches to search for special characters as well. Trying this I don't see it working so I don't know if it has been implemented or not. Tried - and album:- without results.

See Mantis Bug 5186 for the explanation. I did ask if there can be some form of solution that would allow a forced search including special characters.

> See Mantis Bug 5186 for the explanation.

It does find partial matches as long as partial matches have a space leading/trailing.

Ah, so my bug report was not precise enough. I'll try again.

1 Ensure search options has Album ticked
2 In Quick Search enter "-" (including quotes, for ""A" : finds tracks with A only. It does find partial matches as long as partial matches have a space leading/trailing."))

Expected (here): tracklist shows tracks having " -" in Album
Observed: tracklist blank, missing tracks having " -" in Album

Actually expected is that no tracks are shown as this feature is meant to only find full matches. The partial/leading space issue is not a feature and as such reported as a bug. Well, okay, I asked if it's expected or not. As this is unexpected behavior to have any matches it might work on certain searches while not on others. I think we should wait to see what the developers respond to see if a "" search means:
- Full field match
- Full word match
- or something else.

> The partial/leading space issue is not a feature

Since when?? Excluding this feature would severly prang searching music libraries e.g. "AC/DC"

> and as such reported as a bug

Where was it reported as a bug???

As indicated now in several posts using "" is a full field match not partial. That it currently matches partial field can be caused by 2 things:
- "" is for full word/field match instead of only full field match
- "" is resulting full word (leading/trailing space) matches where it shouldn't

That's why I'm waiting for a clarification on this feature.

From Mantis Bug 5186

It also seems that what I indicated is true as well. It does find partial matches as long as partial matches have a space leading/trailing.
"Flac" returned all tracks with /xxxx FLAC xxxx/ in filename, which would be incorrect per spec?

> As indicated now in several posts using "" is a full field match not partial.

Indicated by only by you, Lowlander. Whereas if the bug report you claimed does exist, Id like to see it please.

From Ludek's reply

and "A" means exact match

in that same bug report.

Based on my understanding of exact match I'd expect that query has to match full field, based on behavior experienced it seems to be full word.

Lowlander wrote:From Ludek's reply

and "A" means exact match

That is not a bug report.

No as that's a response to the bug report.

There is now also a response from the developers and "" is full word search.

Following on from http://www.mediamonkey.com/forum/viewto ... 23#p185523, also:

Expected (here): tracklist shows the many tracks having " - " in Album, i.e. containing "-" as a seperate word.
Observed: tracklist blank.

This is a bug because it fails to accord with the definition:

Ludek (developer) @ 2009-01-13 13:42 in http://www.ventismedia.com/mantis/view.php?id=5186

It is ok that FLAC is found within /xxxx FLAC xxxx/, but should not be found within /xxxxFLACxxxx/.

That's correct it fails, whereas "A" works. Don't know if it's a bug or undocumented limitation as it could be a special character and thus treated differently.

> Don't know if it's a bug

Fine.

Please add it to Mantis.