PDA

View Full Version : T9 or similar "smart" text entry



cckanne
2005-08-22, 08:11
Hi.

I really like the look and feel of my squeezebox2, and the way it evolves (smooth scrolling for menus is cool). I also love hacking slimserver (answering machine, caller ID display, the works). However, there is one thing I would love to have that cannot, I think, be easily addressed without hacking the firmware: A smarter text entry tool for searching.

I'm guessing because I didn't look deeper into the slimserver source, but it seems to me that currently, there is some kind of simple text entry widget that is handled entirely on the sb2 side, which returns the string, e.g. when searching music, and slimserver then does a query and returns the result as a scrollable menu.

Is there any way to get results _while_ typing? I'm looking for something similar to T9 (or whatever it's called these days) on cell phones, where the phone guesses word completions after the first few letters have been typed.

I guess the reason why you guys didn't implement it yet is scalability. While it probably would work for artists and genres, you'd send maybe 10K for a collection with a few hundred artitsts, it wouldn't work for album or title search, as sending the titles of all albums before the text entry prompt is displayed would be too slow.

Some brainstorming bits:
- lossy compression (I think the phones do something like that) that does not always perform accurate lookups but is good enough in most cases
- caching on the sb2
- asynchronously sending typed letters to the server and asynchronously receiving and displaying the results - there is some latency before you get results, but it would probably still be faster than the current method
- user interface prototype: take a look at a few cellphones
- quick&dirty solution: relax character comparison strictness, such that I can send 723464323 to the server and will get "radiohead" as result. Although ugly, I would just have to press 9 buttons instead of the current 17 (*)

Am I the only would who thinks this would be nice? Would it be too complicated/expensive to implement?

best,
C-C

(*) yes I use vi as editor :-)

radish
2005-08-22, 08:43
The problem with using T9 is that you have to license it. It may be possible to come up with something close enough without being sued though :)

AFAIK the entire interface (including text entry) is handled by the server. With the exception of the setup screens of course.

kdf
2005-08-22, 09:48
Quoting radish <radish.1u6a4z (AT) no-mx (DOT) forums.slimdevices.com>:

>
> The problem with using T9 is that you have to license it. It may be
> possible to come up with something close enough without being sued
> though :)

Though, as is often the case, the more you talk about the potential of being sue
while designing something, the more you show awareness of wrongdoing. At
least, as far as a lawyer is concerned. Right or wrong, it's a costly expense
to defend.

> AFAIK the entire interface (including text entry) is handled by the
> server. With the exception of the setup screens of course.

http://bugs.slimdevices.com/show_bug.cgi?id=386

a patch was submitted a while ago to create one type of method.

-kdf--
NOT a Slim Devices employee

hickinbottoms
2005-08-29, 02:02
I've finally produced a 6.2-compatible version of my "lazy searching" patch for SlimServer, which I originally made available in January for SlimServer 5.4.1 (and referenced by kdf for bug#386).

For those not familiar, it lets the user very quickly search using the remote control without having to "multi-tap" to get at non-first letters, or to wait/press right-arrow between letters on the same key. Note this isn't "predictive text" as seen on mobile phones as there's no suggestion of alternatives that are narrowed as the user is typing (in my opinion - if anyone knows different then let me know and I'll cease to make it available).

I hope it may be of some use. You can find it on my webpage here: http://hickinbottom.demon.co.uk/SlimServer/lazy_searching.htm

Whilst not a complete solution for bug #386 (http://bugs.slimdevices.com/show_bug.cgi?id=386), I believe it's as close as we might get with SlimServer.

I'm going to add a preference to allow the user to control whether this functionality is enabled or not - I'll post an updated patch to the bug when I've made some progress so subscribe to it for updates.

giulianoz
2005-08-29, 07:07
Hi,
couldn't this be done using regular expressions ? One should enter 1234 and the server searches for title/file/artist/etc containing "[1][2a-cA-C][3d-eD-e][4f-iF-i]"

giuliano

hickinbottoms
2005-08-30, 04:23
Regular expressions? Yes and no, I think. You could perform the actual comparison like that in Perl but I don’t think you can be that rich in SQL (SlimServer 6 offloads the actual searching to an SQL query). When I first cobbled it together for SlimServer 5.4.1 I could have saved myself some trouble by doing it your way, though.

I did look at whether there was some ‘tr’-like SQL functionality that I could use in a similar way, but came to the conclusion that there wasn’t anything SQL-portable enough and anything that generates column values dynamically like that would kill performance because it would require a full table-scan and wouldn’t take advantage of index searching.

So, I think that it’s best to pre-process the strings at database build-time to simplify the SQL searching later on.

giulianoz
2005-08-30, 07:39
Another way this could be done:
add a filed in the songs table wich contains the numeric representation of the title/artist/song/whatever and do the seaqrch query on this field.

i.e.:
db field : "metallica" -> "638255421"
user input "etall" -> "38255"
query: select fields from table where db_field like '%user_input%';

this should solve the regexp missing sql function, but adds some data to the database and slows the search engine.

giuliano

Robin Bowes
2005-08-30, 07:47
giulianoz wrote:
> Another way this could be done:
> add a filed in the songs table wich contains the numeric representation
> of the title/artist/song/whatever and do the seaqrch query on this
> field.
>
> i.e.:
> db field : "metallica" -> "638255421"
> user input "etall" -> "38255"
> query: select fields from table where db_field like '%user_input%';
>
> this should solve the regexp missing sql function, but adds some data
> to the database and slows the search engine.

How is this different from:

select fields from table where artist_name like '%etall%' ?

R.

--
http://robinbowes.com

If a man speaks in a forest,
and his wife's not there,
is he still wrong?

hickinbottoms
2005-08-30, 07:54
That's pretty much what my patch does. I initially added columns to the albums, contributor and track tables and stored an encoded version there. However, to save changing the schema and simplify the searching I now store both the original (text) and encoded (numeric) versions in the existing 'search' database columns.

This might seem to add a risk of false positives, but because they're encoded numerically unless you've got a lot of artists/albums/songs called "4258646" or whatever you'll not notice the difference!

Keeping it all in the one column also means the SQL search remains simple and quick - on my low powered server (~400MHz Celeron), I can't notice any slowdown when lazy searching is enabled.

giulianoz
2005-08-30, 08:37
How is this different from:

select fields from table where artist_name like '%etall%' ?


well... you can press each button only once instead N times for each letter :)

is: "etall" is 3 8 2 5 5 and not "3 8 2 555 555". in this case to select the "l" you have to press 5 only once and not three times

giuliano

chris
2005-08-30, 08:54
It'd be great to add this as a search option into the main code - I use the latest nightlies, updated each night, and it's a pain to patch this in for every release.

The idea behind it is great.

hickinbottoms
2005-08-30, 09:01
I have a preference added that enables the lazy searching to be optional per-player. I'll get an updated patch posted to the bug #386 later tonight.

Id like to be able to code this as a plugin instead, but I think that would require some more plugin hooks to be pacthed in anyway (pre-processing the "search" text before insertion into the database, and hooks into the code that constructs the database query, for example).

As for updating to the nightlies - I do that, but if you do it through Subversion (ie "svn update"), it will keep any non-conflicting local modifications you might have made. That way I don't need to keep reapplying this patch, just deal with the occasional conflicts.

hickinbottoms
2005-09-26, 04:57
Based on previous discussion and suggestion here I've reworked my patch into two parts:

1. A core SlimServer patch that adds hooks into the database storage and remote control search 'button' to allow plugins to get involved.

2. A plugin that uses these hooks to provide "lazy searching".

For those not familiar, as an example this method cuts down the number of remote button presses required to search for the text "SQUEEZE" from 20 to just 7. Note this isn't in any way predictive (it won't show "SQUEEZE" on the screen as you're pressing the buttons, and isn't statistical in what it matches), but it does save a *lot* of time and has very few false positives.

The plugin can be enabled and disabled on a per-player basis (player UI is provided for this), and some user-level help is provided through the SlimServer web UI.

I would appreciate some feedback on this. I'd really like to get the hooks into the trunk SlimServer if at all possible, and I'm more than willing to do some more work on the patch if it makes it any more likely to get included. With the current patch applied, users see no difference unless they also install a suitable plugin, so it's pretty inert.

I've posted the patch and plugin to bug#386 (http://bugs.slimdevices.com/show_bug.cgi?id=386).

giulianoz
2005-09-26, 05:06
i'll give it a try ASAP (the water pump that cools my server down died yesterday...). I hope I'll give some feedback in a couple of days

giuliano