That rule could be ignored when Length: is used in the search. Otherwise it could be forced by using "" for the search string. I think that technically this should be possible to implement.

The search might have to be like this because of the colon (which I think is ignored from the search).

Please don't get into a fight about what is a bug with CrisJJ. This has been done before and we just have to have our different opinions on the matter.

It's now up to the developers to implement this or not.

> I find it logical that it would present as a "broken search." *Shrugs*

http://www.mediamonkey.com/forum/viewto ... =7&t=34847
-Note that the term 'bug' refers to both design and implementation deficiencies.

I don't think I would classify this as a bug, and more just a limitation. The search feature uses the colon character to separate the property and the search criteria, given a minute and second search contains a colon, I find it logical that it would present as a "broken search." *Shrugs*

You're saying because this has never worked, it's not a bug?

chrisjj wrote:> This is not a bug.

How so?

Bex wrote:MM has always only accepted seconds when using Length in searches

> This is not a bug.

How so?

> MM has always only accepted seconds when using Length in searches.

I've found many bugs that have been present for years.

> It could be better described in the help

It could be accurately described in the help.

> Please also correct the summary heading in mantis, currently it contains an URL.

Thanks for the bug report Now fixed.

This is not a bug. MM has always only accepted seconds when using Length in searches. It could be better described in the help though and not only within the property dropdown of the Search Criteria form.

Please also correct the summary heading in mantis, currently it contains an URL.

1 In quick search, enter Length:1:23..3:45

Expected: only tracks matching
Observed: all tracks

Workaround: Length:83..225 (thanks NH).

Tracked at http://www.ventismedia.com/mantis/view.php?id=6206