After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 555120 - Genre rules do not work
Genre rules do not work
Status: RESOLVED FIXED
Product: banshee
Classification: Other
Component: Smart Playlists
git master
Other All
: Normal normal
: 1.4.2
Assigned To: Gabriel Burt
Gabriel Burt
: 567403 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2008-10-05 16:39 UTC by Ivan Zlatev
Modified: 2009-01-11 19:47 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
Correct case sensitivity (711 bytes, patch)
2008-11-14 21:24 UTC, Félix Velasco 		committed Details | Review

Description Ivan Zlatev 2008-10-05 16:39:29 UTC 
Please describe the problem:
Smart Playlist Genre rules (such as "Genre is Pop") simply doesn't work.

Steps to reproduce:


Actual results:


Expected results:


Does this happen every time?


Other information:
Comment 1 Bertrand Lorentz 2008-10-05 17:57:33 UTC 
It looks like the "Genre is Pop" condition is translated into the following SQL :
CoreTracks.Genre = 'pop' AND CoreTracks.Genre IS NOT NULL

This should probably not be case-sensitive.
Comment 2 Gabriel Burt 2008-10-06 15:44:02 UTC 
Ivan, is the issue that it's case sensitive?
Comment 3 Ivan Zlatev 2008-10-06 19:11:46 UTC 
(In reply to comment #2)
> Ivan, is the issue that it's case sensitive?
> 

The genre search should be case insensitive yes. Looking at what Bertrand wrote about the query it seems banshee doesn't perform a case insensitive search also lower-cases the genre search word.
Comment 4 Félix Velasco 2008-10-27 22:29:45 UTC 
I've been looking at the code, and I think the problem is in QueryField. In the line 159, why is caseSensitive negated? Shouldn't the condition just be (column_lowered || caseSensitive) ????
Comment 5 Félix Velasco 2008-11-14 21:24:35 UTC 
Created attachment 122696 [details] [review]
Correct case sensitivity

Case sensitivity flag was negated, reversing the expected functionality
Comment 6 Sandy Armstrong 2008-12-18 17:23:15 UTC 
Felix's patch seems correct to me (and works, too, assuming == is supposed to be case-insensitive in the search field).
Comment 7 Sandy Armstrong 2008-12-18 17:26:45 UTC 
Got approval from Gabriel to commit this patch after the current freeze (I'm not sure when that will be).  Marking patch to indicate this.
Comment 8 Gabriel Burt 2008-12-29 22:19:30 UTC 
Thanks for the patch Felix, I committed a slight variant on it.
Comment 9 Gabriel Burt 2009-01-11 19:47:24 UTC 
*** Bug 567403 has been marked as a duplicate of this bug. ***