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 458941 - Banshee returns partial search results
Banshee returns partial search results
Status: RESOLVED FIXED
Product: banshee
Classification: Other
Component: general
Legacy Branch
Other All
: Normal minor
: 2.x
Assigned To: Banshee Maintainers
Banshee Maintainers
Depends on:
Blocks:
 
 
Reported: 2007-07-21 10:17 UTC by Pavel Šefránek
Modified: 2008-04-16 18:45 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Pavel Šefránek 2007-07-21 10:17:24 UTC
Please describe the problem:
In Czech language, there is the letter "ch" as a single char. Not like in English, where this is two chars: "c" and "h". This causes that the search feature doesn't work well -- it only shows some titles (not all), where the char "ch" (in metadata) is presented. 

Switching to LC_ALL="en_US" fix that since there is no char like "ch".

Maybe this is because of different Unicode interpretations between "c" and "h" (two normal letters) and "ch" (one single letter).

Steps to reproduce:
1. Make sure you have some songs with the "ch" inside their metadata.
2. Run banshee with LC_ALL="cs_CZ.UTF-8" and try to to search a string containing songs described in 1)
3. Run banshee with LC_ALL="en_US" and repeat step 2

Actual results:


Expected results:


Does this happen every time?
Yes

Other information:
This could be a Sqlite's issue??
Comment 1 Pavel Šefránek 2007-10-29 21:39:53 UTC
Rhythmbox seems to work well. I am currently using newer version (Banshee 0.13.1) and the problem is still remaining.
Comment 2 Andrew Conkling 2008-02-07 02:04:42 UTC
Seems that special characters should be matched to equivalents where possible. For example, Šefránek should also be matched by "Sefranek", etc.
Comment 3 Pavel Šefránek 2008-02-07 10:51:36 UTC
Andrew: All other specials chars work well, except for that typically czech "ch"
Comment 4 André Klapper 2008-02-25 11:40:08 UTC
(In reply to comment #3)
> Andrew: All other specials chars work well, except for that typically czech
> "ch"

oh wait... how does banshee does that? we had that discussion for evolution some months ago (searching for a message with s/t does not bring up chars like š/ť) and wondered if there are some kind of matching tables or low-level implementations for this.
Comment 5 Andrew Conkling 2008-02-25 18:28:42 UTC
On Mon, Feb 25, 2008 at 12:42 PM, Gabriel Burt <gabriel.burt@gmail.com> wrote:
    Search in stable was implemented as a C# loop iterating over all the
    TrackInfo objects in a Source (eg Library, Playlist, etc) and doing
    string comparisons - the code is here:
    http://svn.gnome.org/viewvc/banshee/branches/banshee/stable/src/Core/Banshee/PlayerInterface.cs?revision=3124&view=markup
    - see OnSimpleSearch and DoesTrackMatchSearch.  What allows it to
    ignore accents etc is the use of
    CultureInfo.CurrentCulture.CompareInfo.Compare in
    src/Core/Banshee.Base/StringUtils.cs.

    However, in trunk search has been completely rewritten.  It is parsed
    and turned into SQL using src/Libraries/Hyena/Hyena.Query.  So, we
    don't have the advantages of the CultureInfo library.  What we really
    need is a custom sqlite function for doing both case-insensitive
    matching (currently only works for ASCII chars) and for accent-less
    matching.  Should probably google some more since it's quite likely
    others have solved this for sqlite already.  If not, I would suggest
    either looking into making a C/C++ function for sqlite, or see if it
    can be done efficiently enough in C# -
    http://anonsvn.mono-project.com/viewcvs/trunk/mcs/class/Mono.Data.Sqlite/Mono.Data.Sqlite_2.0/
    - SQLiteFunction.cs
Comment 6 Pavel Šefránek 2008-04-16 18:45:14 UTC
Fixed as of Banshee 1.0 Alpha 3 (0.98.3)