*** Bug 4798 has been marked as a duplicate of this bug. ***

Thanks Philip, I am going to assume that advanced search has always worked this way and change this bug to an enhancement request.  If it did work in the past please let me know.

normally a form will reset due to the page reloading on submit.  However, looking at the template, there is some attempt to parse the search params passed through the server. The template is looking for search.bitrate.value as a match.  The params being sent aren't quite matching up, but clearly the intent was there.  I think we are talking bug in this case, if nto for the case of the >,<,equals selections.  Looking further, it seems that the search query hash is somewhat broken.  The returns params are sometimes 'op', sometimes 'value'.  Could use a bit of a once over.

I'll be happy to spend some time on it, but let me know what you want for a target.  I'll assume 7.0 unless told otherwise.

I also notice that the Clear button doesn't do anything (looks like the Fishbone skin style isn't applied to it either?).

style is fixed.  clear button...can't have cake and eat it too.  If the form is loaded with the values set to the last submitted values, clear will only reset to those values.  It is probably mislabelled.  What it does is reset the values to the defaults (ie, the ones from the last page load erasing what has been changed but not submitted).  It cannot clear the form unless the form started as cleared.

fix committed to trunk at change 11574 and 6.5.2 at change 11575.  Please test and confirm. 

I've done nothing with the "clear" button as this is doing what the reset button type is supposed to do.  The button text might be better as "RESET" or something could be done as a result of clicking CLEAR that reloads the page with wiped values.  Either way, that does fall into the enhancement range.

changelog will have to wait until this gets cleared up.  possible idea is to close this as fixed, pushing the "clear" thing to a NEW bug report.

Thanks KDF, that is working, with one observation.

I notice that if I filter by "Date Modified before 03/03/2007", I get no results.  The "before" option is remembered, so I'm guessing this is another bug unrelated to your change.

I suspect that before/after options have opposite effect.  I changed to "Date Modified after 03/03/2007", and the search is still running (I suspect it will return all songs).

Index: Slim/Web/Pages/Search.pm
===================================================================
--- Slim/Web/Pages/Search.pm    (revision 11577)
+++ Slim/Web/Pages/Search.pm    (working copy)
@@ -145,8 +145,8 @@
                                $params->{$key} *= 1000;
                        }
 
-                       # Duration is also special
-                       if ($key =~ /age$/) {
+                       # Timestamp is also special
+                       if ($key =~ /timestamp$/) {
                                $params->{$key} = str2time($params->{$key});
                        }
 


that should fix the timestamp/date modified problem a bit, as the formatted date needs to be altered to timestamp format.  However, if the result is sitll the whole library (as was probably the case you suspected) it will still take a very long time.

Did your patch get applied to trunk?

I think it's working in 6.5.2, but I notice one thing that was confusing me.

I tried to search for files that I modified yesterday, so I did a search for "06/04/2007".
This found no results.  I realised that it's expecting the date in American format, so "04/06/2007" found recent music changes.

I think that will catch a lot of non-American users out.  Is it possible to use the correct localisation for searching, or as an alternative use "yyyy-mm-dd" as a more universal format for entering dates?  (Even better would be a proper date-picker control, but that's probably optimistic!).

it went into trunk at change 11580, 6.5.2 at change 11581.
it wasn't intended to be a complete fix, which is why this was left open.

not sure localising the date entry is a good idea, as the timestamp would instead be based on the file system timestamp, not the slimserver language setting format.

I am not working on this bug any more, as I have no interest in flogging myself with date mangling and localisations.

in future, this bug summary should be reviewed and reworded to reflect what is desired as a final solution. whether altering the "clear" button behaviour, or rearranging the timestamp (during scan requiring a rescan every time language is changed, or during search requiring some sort of check on the formatting of the filesystem vs language pref and munging the entry)

*** Bug 6113 has been marked as a duplicate of this bug. ***

rewording and opening target for review.

actually, most skins can do the "clear" by clicking the pwd_list and reloading a fresh search.
the default skin, however, uses the pwd to show the form (which is hidden after results are given)
perhaps it can reload the page IF the form is shown?

*** Bug 6229 has been marked as a duplicate of this bug. ***

I"m marking this as a bug, though it's been a long-standing, albeit minor, one.  The search results should include a pre-filled form from the last search.

Will look at this post-7.0

Targetting to 7.1 so I don't forget it.

Kevin/Phil - going through the comments and trying to reproduce, I wonder what the bug is still about? All seems to be working fine here.

Here's what I find to still be broken in the Default skin:

1. If I want to do a filter on Date Modified After 30/01/2008, I get no results.  This is because it is expecting dates in American format, so if I enter the date as 01/30/2008 it works.  There's an example date on the form "ex: 26/04/2008", which suggests that date localisation should work.

2. Perform an advanced search.  Click "Advanced Search" to reveal the advanced search form with the search criteria displayed - great.  However, the Clear button Doesn't clear the fields; it resets the form back to what was used in the last search.

I think the Clear button should probably clear all fields, otherwise there's not much point having a clear button.

change 20203
- don't localize date query - too expensive, would need additional modules to reliably parse the date
- make the Clear button clear the form, not reset it to the load time values (as is html default)

This bug has now been fixed in the 7.1 release version of SqueezeCenter!  Please download the new version from http://www.slimdevices.com if you haven't already.  

If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.

Reduce number of active targets for SC