Searching for titles with zeros in them is not possible

[stuarth]

Originally reported by Dieter on the forums.

I tried to find a song that has a "0" (zero) in the title (1001 Arabian night, that's from a album of my daugther!). The song is not found with the keyword search although it is found with the title search. Probably a problem since 0 is the delimiter for different keywords.

[stuarth]

Yes, this is a 'feature' of how keyword search works - '0' is always interpreted as a delimiter between keywords.

One alternative is to change the keyword delimeter for another button the remote, but whilst that's possible it's got to be intuitive.

There is the 'HOLD' equivalents of the buttons, however. I could enhance it do the following:

• Normal '0' - enter a '0' as the search text (so you can search for your daughter's song). Note that since '0' is also how spaces are lazy-encoded it will also match spaces, but that's probably quite unlikely to happen by accident.
• Hold '0' - enter a ',' as a keyword separator.

Actually, as I write this I think that's quite a good idea and I'll probably take a look at it.

[stuarth]

Dieter has suggested UP or DOWN as the separator. Whilst I think I could make that work I know that the SlimServer folks have been uncomfortable with 'overloading' the normal useage of remote control buttons by plugins. They always say that the buttons shouldn't surprise the user by doing something that only that plugin does.

So, I think I'll try for '0' held down, but I'll see how I get on. I'll have to remember to add an FAQ entry for entering multiple keywords, though.

[dieterp@…]

Hold "0" for entering a keyword separator sounds good to me. Thus you don't loose the possibility to search for "0" in a search string.

Dieter

[stuarth]

OK, I think I've got that working (short press of '0' for entering the '0' character, long press of '0' for the keyword separator [shown as ',']).

Can you test that Dieter? You can find a beta release here:

source:tags/2.2.2b2

If you could report back in this ticket I'd be grateful. Thanks.

I've still got to tidy up the code a bit (there are a few debug messages still going to the log in case you get any problems, but I'll get rid of those before release).

[Dieter]

Works great (as expected).

One surprising effect was that searching for keyword "1001" found not only the song "1001 Arabian Night" but also "Piano Concerto 1 - 1. Allegro maestoso". I assume the reason is that "0" matches not only "0" but also " " (blank) and that characters like "-" are excluded by the search, so the part "1 - 1" matches "1001". Is that assumption correct?

One further question: The song "1001 Arabin Night" is on a compilation album. I always set for compilation albums the COMPILATION flag equal 1 and the ALBUMARTIST flag to "Diverse" (German for "Various"). When searching for "1001" the resulting artist list shows now one entry for the artist "Chipz" which is the artist of the song and in addition an entry for "Diverse" (which is the albumartist). Pressing RIGHT leads on both entries to the same album and pressing RIGHT again to the same song "1001 Arabian Night". Is that for purpose or should the "Diverse" entry not be shown in the resulting artist list (I tend that it should not be shown)?

[anonymous]

Glad to hear it's working, thanks for trying it.

Yes, I think you're right about '0' matching zeros or spaces - that's a side-effect of the way I encode things I'm afraid. It also does ignore punctuation in the way you suggest (this was a very recent change). It should have collapsed multiple spaces after removing punctuation, though, so "1 - 1" should have been encoded as "101", so I'll look into that.

The chances of this kind of ambiguity should be quite low, however, so hopefully it's not a huge pain. Suggestions of alternative encodings welcome, but I didn't really want the user to have to enter zeros and spaces differently on the remote (too many overloaded button behaviours and not enough buttons on the remote, again!).

I think the 'multiple artists with same album/track' is a consequence of the way I search. I don't specify what kind of artist I'm looking for so any that SlimServer has associated with that track will be returned. The database, however, does state the role of the artist and so the album and track artists can be differentiated.

I think I agree that only the actual track artist should be returned, so I'll look into revising that query - thanks for spotting it.

I'm going to have a busy weekend if I'm going to try to get the next version out for the official launch of 6.5!

[stuarth]

I think I've got the "1001" and "1 - 1" issue resolved - it wasn't working quite the way I intended. Changes are in changeset:183 (beta to follow when I've looked at the other thing).

Note that since the lazified format has changed a database clear-and-rescan will be necessary. Also, I've not thoroughly tested this yet, so I'll need to look at it more closely before pushing out the next beta.

[Dieter]

I tried rev183 and after a clear-and-rescan "1001" now finds only the correct songs (and no longer the "1 - 1" songs). That's great.

I then search for "101". Since the mininum number of search characters for keywords is set to 4 I forced the search with the SEARCH key and the "1 - 1" song was correctly found. There were 2 further songs matching "101", one of Billy Joel, and I thought I will check whether the search separator (hold 0) also works. I thus input "101", "hold 0" and "24559" (for BILLY) and there were 9 matching results instead of the one expected result from Billy Joel! All results comprised a string matching BILLY but only the Billy Joel song in addition matched "101".

I assume the reason is that the "101" is ignored in the search since it has not the minimum search length of 4 characters. However, the 9 search results are unexpected since 8 of them do not match the first keyword. In my opinion the minimum word length should be ignored for ALL keywords if at least one of the keywords exceeds it or if the search is forced with the SEARCH key. Since inputting more than one keywords results in an AND search the mininum word length is not necessary since the search always restricts the (at least) one result which has more then the mininum keyword length.

Why must there always be so strange side effects when developing new features...

[Dieter]

Although "hold 0" works as separator, in my opinion simply pressing the RIGHT key would be more apparent for inputting the next keyword. As far as I see the RIGHT button has no other function while in layzsearch so there should be no side effects (hopefully).

[stuarth]

I'll have a think about the "Billy Joel" question, but on the subject of pressing RIGHT for the keyword separator - that would work before you've put in the minimum search length, but once you've put at least 4 characters in and there are some search results then pressing RIGHT browses into those results so isn't really suitable.

[anonymous]

Oops, of course you are right (what a stupid proposal). You should never propose something without explicitly testing it. I was thinking about using RIGHT when I was on my way to the office this morning, so I couldn't test it.

[stuarth]

Not as stupid as you might think! I thought "oh yes, that's obviously the thing to do" and was already in the code. It was only when I about to add a handler for RIGHT that I spotted there was already one there then went to check why - I'd forgotten as well!

So, there are no stupid ideas, only bad memories!

[stuarth]

I've mulled over the Billy Joel/101 problem and I agree with your suggestion of ignoring the minimum length if there's at least one keyword that meets the minimum or the search is forced.

Implementing it might be easier said than done, however, but I'll take a look.

[stuarth]

Right... This has had almost no testing at all (a quick bit of work during the lunch hour...):

 http://hickinbottom.demon.co.uk/lazysearch/browser/trunk/LazySearch2.pm?rev=186

I've only tried keyword searching so non-keyword searching might have broken altogether!

[Dieter]

The Billy Joel/101 problem is solved. I did not see any new issue. Great work! Dieter

[stuarth]

OK, on that basis I'll close this ticket. This will be in the next formal release which I'm hoping to make in a few days when I've done a little more testing.

[anonymous]

Don't you forget the open problem that for compilations having an albumartist set only the track artist shown be shown in the result list (see my post of 09/14/2006 and your answer of 09/15/2006 above)?

[stuarth]

Oops - you're right... I'd done some work on the artist roles under ticket:45 that I hoped was the same problem, but looking into it I can now see it isn't.

To confirm, you just want to be able to ignore the ALBUMARTIST in the list of artists returned for a keyword search?

If so, I think I can do that, but I need to provide a preference as I can imagine that wouldn't be to everybody's taste.

[anonymous]

I guess that's what I want :) In the above example it was the specific case that the ALBUMARTIST was "Various" (to be exact the German equivalent "Diverse" I use). It makes no sense to me to include in this case the ALBUMARTIST (Various) and the ARTIST (Chipz) for the same song. I guess this is also true it the ALBUMARTIST is something different than "Various". I set ALBUMARTIST e.g. also in albums of a specific artist (e.g. Tony Bennett) if there is for one (or some) song(s) an additional artist (e.g. a duet with Diana Krall). In this case ALBUMARTIS is set to "Tony Bennett" and ARTIST is set to "Tony Bennett & Diana Krall" (and & is set as mulitple items separator). If ALBUMARTIS is ignored in the result list I assume that the duett song is listed once under ARTIST Tony Bennett and once under ARTIST Diana Krall. That would be ok.

As far as I remember, in the last case (having an ALBUMARTIST set but no COMPILATION flag) slimserver does not use ARTIST but TRACKARTIST. TRACKARTIST is however not shown in squeezebox display (see bug 4024). Is TRACKARTIST shown in the result list? That would be necessary, otherwise the searched song would not appear in the list.

[stuarth]

I think that all seems to hang together. Ignoring ALBUMARTIST seems to do the trick.

My test tracks have an ALBUMARTIST set but no COMPILATION tag or TRACKARTIST. It seems to work OK in this situation and so I don't believe bug 4024 is applicable here as I think that just relates to web/squeezebox display (which is separate to what this plugin does).

I'm just rattling in a new preference and I'll have a beta for you to test before too long...

[stuarth]

OK - here's a new beta:

source:tags/2.2.2b3

 http://hickinbottom.demon.co.uk/lazysearch/browser/tags/2.2.2b3

Could you give this a test and see whether it solves your ALBUMARTIST problem? You should be able to test that without a full clear-and-rescan (which makes a nice change, doesn't it?)

[anonymous]

Unfortunately there are some problems with the new version. The first is newly introduced since it does not occur with rev 186 and the second occurs in both versions:

1. I have an album named "Snowflakes" of Tony Braxton which comprises one song which is a duet of Tony Braxton and Shaggy. For all songs the ARTIST tag is set to "Tony Braxton" and for the duet the ARTIST tag is set to "Tony Braxton & Shaggy". In Slimserver the separator for multiple items in tags is set to "&". All songs are mp3 files.

In order to prevent slimserver to identify this album as compilation I set ALBUMARTIST to "Tony Braxton". I use in addition MediaMonkey? for managing my music files and MediaMonkey? sets in addition for all songs BAND to "Tony Braxton". If you look in slimserver into the song info page all songs have set ALBUMARTIST, BAND and TRACKARTIST (it seems that slimserver uses TRACKARTIST instead of the original tag ARTIST in this case) to "Tony Braxton" except the duet which has ALBUMARTIST, BAND and TRACKARTIST set to "Tony Braxton" but in addition a second TRACKARTIST set to Shaggy.

If I make a keyword search for "Snowflakes" with the 2.2.2b3 version of layzsearch the result is empty. If I use rev186 there are two resulting artists, namely Tony Braxton and Shaggy. If I search in the new version for album instead of keywords the album "Snowflakes" is correctly found. If I set the new option to include album artist in the keyword search to YES the results are as in rev 186. So it seems that the new option to hide ALBUMARTISTS in keyword search hides too much.

2. If I make a keyword search for "Braxton" all Tony Braxton albums including Snowflakes are correctly found. But when I then go into Snowflakes all songs of this album are shown three times. The reason seems to be that all songs have ARTIST, ALBUMARTIST and BAND set to "Tony Braxton".

In another album of Tony Braxton for all songs ARTIST is set to "Tony Braxton" and BAND is also set to "Tony Braxton" (I assume again by MediaMonkey?). In this case each song is listed twice if I make a keyword song for Tony Braxton and go into this album.

As mentioned, this second problem also happens with rev186.

[Dieter]

The last post was from me. I forgot to add my name. Dieter

[stuarth]

Oh dear, more to do, then.

I'll go and try to reproduce that... Thanks for the report.

[stuarth]

Can I confirm you've got at least the "band" extra tag selected at the top of "server settings->behaviour"?

I believe I've fixed the second problem (multiple results where there is more than one matching contributor tag). It's simply a matter of looking for 'distinct' results, I think (it seems to work for my small test, anyway).

For the first problem, I can't reproduce that with my small test library (I think I followed the tagging you reported above, however). Can you check exactly what tags you have set? I've set the following (just showing my one test track that was supposed to look like your Braxton/Shaggy? duet):

• ALBUM=Snowflakes
• ALBUMARTIST=Tony Braxton
• ARTIST=Tony Braxton & Shaggy
• BAND=Tony Braxton
• GENRE=Pop
• TITLE=Road
• TRACK=3
• YEAR=1972

Other tracks are the same with the exception of the ARTIST tag being just "Tony Braxton".

Could you check that with your library? If you'd like to try the version where I've fixed the duplicate results it is r195:

 http://hickinbottom.demon.co.uk/lazysearch/browser/trunk?rev=195

Also, although I said a clear-and-rescan shouldn't have been necessary, it might be best to try one as there could have been other changes to the way keyword searches were lazified in the database that I can't remember, I'm afraid. Sorry about that.

[Dieter]

I have to check if I have the "band" extra tag selected in server settings this night (I will only be at home during midnight).

The tags of your sample file look ok to me but I will also check this night.

To be on the safe side I made a clear-and-rescan after I detected the problems. This did not help. I will do a clear-and-rescan when I try your new version.

[stuarth]

Thanks. If things look the same at your end, but you're still getting this bad behaviour, I wonder if you could let me have a look at your database? That way I can certainly reproduce it and understand what's going on.

If you're not sure how to do that I've got a page explaining it - wiki:ExportingYourDatabase - I'm just completing the instructions for Windows users at the moment.

 http://hickinbottom.demon.co.uk/lazysearch/wiki/ExportingYourDatabase

Thanks for the continued testing - I really appreciate it.

[Dieter]

In "server settings, behavior" I have none of the three checkboxes set, neither composer nor director nor band/orchestra.

The tags you have used are identical to mine except that I don't use genre Pop but always Rock, the number tag I use is TRACKNUMBER and foobar shows DATE instead of YEAR. But these differences shouldn't be relevant.

The second problem (multiple results) is solved with r195. That's the good news. The first problem still exist. So I will send you my library.

I found one further minor issue (sorry for that). If you search for keywords the resultng track list of a found album is a list of tracks without preceding track numbers. If you search for interpret or album the tracks have leading tracknumbers in the display.

[stuarth]

Thanks for your database copy. I'm just about to go to bed, but I gave that database a quick try and can reproduce your problem. I believe it definitely is related to the most recent change to hide album artists - I note that with 'BAND' turned on in the 'server settings->behaviour' page the search actually works.

I'd noticed the lack of track numbers as well - I suspect I'll be able to do something about that.

I'll try to get time to take a look tomorrow.

[stuarth]

I think I've got the problem of missing results solved in r196 - for some reason SlimServer? doesn't look for TRACKARTISTs by default, only ARTIST. I'm sure there's some subtle reason for that, but I don't see it.

I'll now have a look at the track numbering issue.

[stuarth]

Right, the track formatting for display should be in r197. Could you give these things a bit of a workout, if you wouldn't mind? No rush - you've done a lot of testing for me already.

Thanks once again.

[anonymous]

Some text - is this OK?

[stuarth]

I think I've tamed the spam filter...

[stuarth]

Dieter has reported that there don't appear to be any problems. On that basis I'll finally close this one - I can always reopen it again if necessary.