Bug 341661

Summary: Recent build from git if length is used to build filter it is always show as zero
Product: amarok Reporter: robert marshall <robert>
Component: Collection BrowserAssignee: 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 Packages   
OS: Linux   
Latest Commit: Version Fixed In:

Description robert marshall 2014-12-08 16:50:53 UTC
Build filter (using edit filter)
Select length (drag into condition building area)
Type values in the condition (e.g 0:20:00) I used less than though any of the pull down <=> options have same effect
The Search filter at the foot of that dialog doesn't reflect the value you've set (for me it displayed length:<0
Click ok and that condition with length:<0 ends up filtering the collection

If you try typing the value directly in the search filter in the edit filter dialog and ok it still uses the value zero. 
If you type the required length in the filter without opening the edit filter dialog it will work correctly

Previous build (Oct '14) and pre kubuntu 14.10 upgrade  was ok; new build Dec '14 and with 14.10 exhibits this behaviour. A change in the signal/slot interface with Qt 4.8.6?


Reproducible: Always
Comment 1 Myriam Schweingruber 2014-12-09 13:04:16 UTC
hm, we need to check what changes in that code were committed to master after October 14, then...
Comment 2 robert marshall 2014-12-24 12:17:35 UTC
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
Comment 3 robert marshall 2015-05-28 09:03:00 UTC
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.
Comment 4 Myriam Schweingruber 2015-05-28 11:43:48 UTC
Indeed, I can reproduce this here as well, marked as a regression
Comment 5 robert marshall 2015-05-28 14:37:50 UTC
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)
Comment 6 Stefano Pettini 2016-06-18 22:32:10 UTC
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/
Comment 7 robert marshall 2016-06-19 08:08:31 UTC
Yes, this patch fixes it for me - thanks!
Comment 8 Matěj Laitl 2016-08-07 09:39:07 UTC
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