| Summary: | Recent build from git if length is used to build filter it is always show as zero | ||
|---|---|---|---|
| Product: | [Applications] amarok | Reporter: | robert marshall <robert> |
| Component: | Collection Browser | Assignee: | Amarok Developers <amarok-bugs-dist> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | stefano |
| Priority: | HI | Keywords: | regression |
| Version: | 2.8-git | ||
| Target Milestone: | 2.9 | ||
| Platform: | Ubuntu | ||
| OS: | Linux | ||
| Latest Commit: | http://commits.kde.org/amarok/6c49cfdfd97faa146ce7b0d8e95ce2bf596f2b0d | Version Fixed In: | |
|
Description
robert marshall
2014-12-08 16:50:53 UTC
hm, we need to check what changes in that code were committed to master after October 14, then... I'm also seeing the issue in dynamic playlists - those constraints which specify a length now display as length:<0 in spite of my not editing them - it looks as if the 'real' value here is correct and is just displayed incorrectly - dynamic.xml looks to have sensible values I'm also seeing this bug with both tracknumber and discnumber in the collection filter, the values in the search filter remain as zero no matter what (numeric) value you set the condition to. Indeed, I can reproduce this here as well, marked as a regression Also if you use 'between' rather than 'equals/greater than/less than' the increment/decrement buttons work and the value limits are reflected in the search filter. Once you OK the dialog and re-edit then the 'between' connection is broken and you've again lost the ability to set values based upon that attribute. (adding just in case losing the 'between' on a re-edit isn't expected behaviour but using between gives a workaround to the bug) The bug was due to what sounds like an "optimization" that swapped the first and second value of a "between" condition, to make sure the smaller value was always the first value and the larger always the second. The problem was that this was applied also to non-between conditions, actually swapping the length or disc number with 0, making 0 appear in the textual representation of the condition. The fix makes sure that this "optimization" is applied only in case of actual "between" conditions, leaving the values "unoptimized" for any other kind of condition (=, <, > and similar). https://git.reviewboard.kde.org/r/128245/ Yes, this patch fixes it for me - thanks! Git commit 6c49cfdfd97faa146ce7b0d8e95ce2bf596f2b0d by Matěj Laitl, on behalf of Stefano Pettini. Committed on 07/08/2016 at 09:34. Pushed by laitl into branch 'master'. Handle numeric fields properly in filter creation dialogs Every numeric field, like length, disc number and track number, were not properly parsed by the filter dialog or by the dynamic playlist dialog into the textual query string used to then apply the filter. The bug was due to what sounds like an "optimization" that swapped the first and second value of a "between" condition, to make sure the smaller value was always the first value and the larger always the second. The problem was that this was applied also to non-between conditions, actually swapping the lenth or disc number with 0, making 0 appear in the textual representation of the condition. The fix makes sure that "optimization" is applied only in case of actual "between" conditions, leaving the values "unoptimized" for any other kind of condition (=, <, > and similar). REVIEW: 128245 M +2 -0 ChangeLog M +5 -1 src/widgets/MetaQueryWidget.cpp http://commits.kde.org/amarok/6c49cfdfd97faa146ce7b0d8e95ce2bf596f2b0d |