XSearch gives poor results

[BobAtTorrey]

Jorm,
XSearch gives undesired results in certain modes. As an example, I used the keyboard (via the MVP remote) to enter the search text "hanks", intending to search for anything with Tom Hanks. Then I used the yellow button to switch to Cast mode. XSearch displayed numerous shows that were irrelevant, such as The Waltons. Upon looking at the description for the shows, they tended to have the word "Thanksgiving" in their text of the Description. Second, it displayed many episodes of The Waltons, only one of which had "Thanksgiving" in it.
Some suggestions:

1. When searching for Cast (where the search text is always a name), it seems preferable to assume that the search text is bracketed by \Word break characters. E.g., when searching in Cast mode, a text of "hanks" should result in a regular-expression search like \Whanks\W .

However, someone might argue that they don't want to have to type the entire name, and want to find "Lolabrigetta" by typing "lola", and would therefore object to my suggestion. If you want to allow that, then I think you would need to do one of two things:

A. Have an on-screen 'Word-boundary-mode' button of some sort that overrides the default search mode -- E.g., switches 'Word-boundary' off or on. (Yuck.)

B. Select a button on the remote control (and key on the keyboard) that is unused on the search screens, and use it to signify \Word boundary. The user could then specify \Word boundary at the beginning, end, both or neither. For example, if you choose the '>>' (fast-forward) symbol on the remote, then
1. >>hanks>> would find only " hanks ", or " hanks, " etc.
2. hanks>> would find "hanks" and "Thanks" (but not "Thanksgiving")
3. hanks would find all of "hanks", "Thanks", "Thanksgiving", "shanks"

If you choose this type of solution, then you don't need to treat the "Cast" mode search differently than any of the other modes.

[Note that equally you could adopt the opposite convention. That is, you could assume before and after word boundaries, but the special character could override it. I.e., typing "hanks" would mean searching for regular-expression '\Whanks\W', whereas typing ">>hanks" would mean searching for regular expression '*hanks\W' thereby matching "hanks", "thanks", "shanks".]



[Incidentally, am I correct that "Cast" search is really no different (partly because of the above issue) than "Description" search? I looked at the Programme table in gbpvr.mdb and there is no separate field for Cast, so you must be searching the Description field. (??) ]


2. A second problem with XSearch results is that it returns episodes that don't match. This seems to occur when searching in "Cast" mode, but not when searching in Description or Subtitle modes. For example, if I search Cast for "hanks", and it finds an episode of The Waltons with "Thanksgiving" in the Description text, XSearch lists ALL episodes of The Waltons, not just the episode(s) that have "Thanksgiving". Whereupon I have to scroll through each of the many episodes and read each Description to see which episode really contains "Thanksgiving". Clearly incorrect, IMHO; only episodes matching the search text should be returned.

Thanks in advance.

Bob

[jorm]

cast info is stored in zapdata.mdb (or something like that). The logic I had adopted is you specify what you want to search and based on the category it means different things, if you change categories the list changes as well. It either means check the description or cast etc...

I am relying on the database search call to find the items that match. I dont know if they can specify a word boundary or not.

as for #2. I have seen this and agree. I will address it.

[BobAtTorrey]

Jorm,
I haven't done my homework, but I'd guess you're correct that regular-expression searches are not built into Access. I think Oracle has it, and I'd guess SQL Server might if it supports POSIX RE's, but likely Access doesn't.
That doesn't mean that searching as I've suggested isn't possible, but it probably is a 2-step process. First, do the search as you are now, which is returning some unwanted (by my definition) records, and then loop through the returned records, discarding those which don't match the regular-expression criteria. It should be pretty easy, and there is probably a RE-matching library routine that would make it very simple.

On your other point, I don't understand what you do with zapdb.mdb. At least on my system, zapdb.mdb consists only of empty tables. Am I missing something?

Cheers .... Bob

[jorm]

cast is supposed to work with zapdb.mdb. If it is not present it might only be searching the description. Xrecord comes with the zapimport tool.

zapimport zaplogin zappassword

it downloads the cast, genre info that xsearch records.

As for the two pass it is easy. The issue is speed. I am trying to return relevant info in the fastest manner possible. I will play around with it and see if I can make it work.

[BobAtTorrey]

Jorm,
Well, that's an improvement! I didn't know about the zapimport stuff. It greatly augments the value of XRecord. It also mitigates my suggestions about searching in Cast, since with the zapdb.mdb populated the searches for names are now meaningful.
Now, below is one suggestion, one request, and a bug (I think).

1. May I suggest that the Wiki page for XRecord include at least a sentence to the effect of "To gain the full advantage of XSearch, download and install the ZapTools utility (found under Utilities in this Wiki)."

2. The next time you're editing in XSearch, would you replace "Genere" (misspelled) with "Genre"?

3. A bug (I think): It seems to me that if I have a List Type selected and enter search text via the keyboard, that XSearch should only return shows that fit in that List Type. Example: If I have the Genre list-type selected, and in the left column have "Animals" selected, and then enter search text with the keyboard of "cro" it should only return shows with, for example, "Crocodile", in the title. I.e., only shows that match the text in title (or perhaps in title or description) and which fit with the selected genre (Animals) should appear. Instead, it looks like the returned shows includes anything that match "cro" anywhere in the title or description of the universe of shows, regardless of the selected List Type.

4. A bug: It appears there is some field displayed by XSearch that the skins don't expect. I noticed it first in the "Flat Blue - High Vis" screen. If I select any List Type, then scroll down the shows seen in the middle column, very horizontally long and narrow boxes appear in the third column to the right of some of the shows as they are highlighted. The boxes vary in length by show, but don't appear for all the shows.

I tried the same thing in the Blue skin. There is still a problem, but the display symptom is different. In the Blue skin, the small 'box' seems fixed at the right edge of the screen at the same height as the top of the keyboard.

Cheers .... Bob