From: Boris Maras <maras_at_netcourrier.com>
Date: Thu, 8 May 2003 16:36:40 +0200

Hi everybody,

A patch has been submitted to implemented a search feature on the jukebox
(in order to search a particular song on the hard disk).
I has been coded by Stefan Meyer (calpefrosch) :

http://sourceforge.net/tracker/index.php?func=detail&atid=439120&aid=723682&group_id=44306

I'm currently trying to improve it and would need some help (Stefan, are you
there?)
Currently, it uses index files (.idx) and searches inside those files. Then
it creates a playlist with the matching mp3s.

My first idea was to get rid of those .idx files, and search directly in the
directories. I was told it would be too slow
As there's already a feature that creates a playlist with all the mp3s of
the hard-disk, I thought it would be a better idea to search inside this
playlist (and use it as a kind of index file). In fact, the .idx files seem
to have the same structure as m3u files, except that there aren't any
commented lines (beginning with #)
This is already done : I added an "onplay" option on .m3u files that
launches the search feature. You type your search string and then it creates
a new m3u with the matching results

Anyway, there seems to be a flaw in the search algorithm (sometimes it gives
me mp3s that do not match). And I don't manage to find where. So I was
thinking of re-coding it.
I was told to implement a Boyer-Moore algorithm, and found several examples
of implementation on the web.
But I'm a newby developer on the rockbox so I would need help.
What I need is typically a "grep -i searchstring playlist.m3u", and then
remove the lines beginning with #

Here are my questions :
1- Do you have any other ideas/suggestions about making a search feature?
2- As I'm a newby, I would need a kind of "debug" mode : how could I do? I
did not manage to compile the win32 simulator : would it help me? I also
found in the code some "//fprintf(stderr ..." : is there a way to see the
stderr on the jukebox?
3- the current algorithm seems to buffer the i/os : it reads 1024 bytes of
the file at a time. I would tend to read the file line by line, but I
suppose it's slower. Anyway, a matching line could be broken into two
buffers and it might be hard to handle it correctly. Reading the file line
by line would be so bad? (I will probably make the first version this way)
4- if you find the flaw in the current algorithm (you can download it with
the link above), perhaps is it no use re-coding it. I can send my test-case
if necessary

A few ideas of improvements :
- being able to handle the id3 tags. I think it would be too slow to read
them for each file. But some playlists put them in a commented line above
the file path (#EXTINF...). We might search in this commented line, and also
copy it in the generated playlist
- searching directly in the directories if we find a not-too-slow way to do
it
- instead of creating a playlist, we might display the list of results, in
which the user could make a choice : probably not easy

Thanks !

sb69 (Boris Maras)
Received on 2003-05-08