[confirm] Search method not working? Ideas for improvements... (1 Viewer)

[ge2301]

the search function from menu in movies does not find anything for me.
The "-" just changes to "?" after some times without any result. The "searching" text remains until I press "back".

 

[Timhoh1234]

the search function from menu in movies does not find anything for me.
The "-" just changes to "?" after some times without any result. The "searching" text remains until I press "back".
View attachment 178266

I realized the same problem, the search function is not working for me. I think it was posted somewhere else in the past.

 

[Timhoh1234]

Did somebody correct the search function so it'll be working with next weekly?

 

[morpheus_xx]

Maybe someone should create a bug report thread and attach log files?

Search is working here (local dev setup), so if it doesn't do for you there must be something different...

 

[TheBatfink]

You really should just look at MovPic code for 'remote filtering' and implement that.. Search boxes you have to type into are last century things! That search function is sooo good..

 

[morpheus_xx]

You really should just look at MovPic code for 'remote filtering' and implement that

Are there more details what this function does? Screenshots? (No, I don't have MP1 installed since years)

 

[TheBatfink]

There was a link to the wiki with documentation but I think it died when googlecode closed (not sure if anyone got a copy maybe @ltfearme knows). Sure he could explain it better than me.

So you execute a filter and you are left with a list of movies. You then begin typing on the remote like a mobile phone from some years ago that used to have predictive text. So if I was to press the number 1 key then number 2 key I believe it does this..

AD, AE, AF, BD, BE, BF, CD, CE, CF... these are terms which are searched and immediately the list view is filtered to results where these terms appear anywhere within the movie.. if you press another key say '4' it extends further and narrows the list even more,

ADG, AEG, AFG, BDG, BEG, BFG, CDG, CEG, CFG, ADH, AEH, AFH, BDH, BEH, BFH, CDH, CEH, CFH, ADI, AEI, AFI, BDI, BEI, BFI, CDI, CEI, CFI

so the more keys you enter the more it narrows down the results.. Also because it uses the predictive text like function you have even less key presses to return your result (1 can be A, B or C, no need to be that specific). Which each key press the terms are grown exponentially. Every key press updates the filter immediately so you see the results changing immediately as you type. To back out of the search you just hit the back button and it cancels this dynamic filter and returns you to the unfiltered list.

This way you do not even need a separate search view (unless you are searching globally and not within what is already contained in the filter I suppose). It's hard to do the feature justice describing it this way, probably a dirty thing to suggest to you but it is worth installing MovPic to try this out, it's surprising how intuitive it feels and the speed and ease of searching using it is insane. I have 2000 entries in my unfiltered collection and it's returning results instantly on key press with next to no latency.

Hope this kind of makes sense.. Bear in mind this is simply what my perception is when in use, I have not actually seen the code..

Maybe this https://github.com/damienhaynes/moving-pictures/tree/master/MovingPictures/MainUI/Filters

Thanks!

 

[morpheus_xx]

I took a first look into search routines:

The way it is implemented now is a "global search" among all (!) attributes of current category (series, movie, video...). So an entered query string will be applied for 16 attributes. This includes the m:n attributes like actors, writers, genres...

So if you search for "James Spader" you will find episodes of "The Blacklist".

While this is very flexible, it comes with a drawback: the performance goes bad on large libraries. One involved query looks like:

SELECT
   T0.MEDIA_ITEM_ID A0,
   T6.ATTRIBUTE_VALUE A1
FROM NM_ACTORS T0
  INNER JOIN V_ACTORS T6 ON T0.ID = T6.ID
  INNER JOIN M_PROVIDERRESOURCE T7 ON T7.MEDIA_ITEM_ID = T0.MEDIA_ITEM_ID
  INNER JOIN M_MEDIAITEM T8 ON T8.MEDIA_ITEM_ID = T0.MEDIA_ITEM_ID
  INNER JOIN M_VIDEOITEM T9 ON T9.MEDIA_ITEM_ID = T0.MEDIA_ITEM_ID
  INNER JOIN M_SERIESITEM T10 ON T10.MEDIA_ITEM_ID = T0.MEDIA_ITEM_ID
  LEFT OUTER JOIN NM_GENRES T11 ON T11.MEDIA_ITEM_ID = T0.MEDIA_ITEM_ID
  LEFT OUTER JOIN V_GENRES T1 ON T11.ID = T1.ID
  LEFT OUTER JOIN NM_AUDIOLANGUAGES T12 ON T12.MEDIA_ITEM_ID = T0.MEDIA_ITEM_ID
  LEFT OUTER JOIN V_AUDIOLANGUAGES T2 ON T12.ID = T2.ID
  LEFT OUTER JOIN NM_ACTORS T13 ON T13.MEDIA_ITEM_ID = T0.MEDIA_ITEM_ID
  LEFT OUTER JOIN V_ACTORS T3 ON T13.ID = T3.ID
  LEFT OUTER JOIN NM_DIRECTORS T14 ON T14.MEDIA_ITEM_ID = T0.MEDIA_ITEM_ID
  LEFT OUTER JOIN V_DIRECTORS T4 ON T14.ID = T4.ID
  LEFT OUTER JOIN NM_WRITERS T15 ON T15.MEDIA_ITEM_ID = T0.MEDIA_ITEM_ID
  LEFT OUTER JOIN V_WRITERS T5 ON T15.ID = T5.ID
WHERE
   (
   (
   UPPER(
   T7.SYSTEM_ID
) LIKE UPPER(
   '%arr%'
) OR UPPER(
   T7.PATH
) LIKE UPPER(
   '%arr%'
)
  OR UPPER(
   T8.TITLE
) LIKE UPPER(
   '%arr%'
)
  OR UPPER(
   T8.MIMETYPE
) LIKE UPPER(
   '%arr%'
)
  OR UPPER(
   T8.COMMENT
) LIKE UPPER(
   '%arr%'
)
  OR UPPER(
   T1.ATTRIBUTE_VALUE
) LIKE UPPER(
   '%arr%'
)
  OR UPPER(
   T9.AUDIOENCODING
) LIKE UPPER(
   '%arr%'
)
  OR UPPER(
   T2.ATTRIBUTE_VALUE
) LIKE UPPER(
   '%arr%'
)
  OR UPPER(
   T9.VIDEOENCODING
) LIKE UPPER(
   '%arr%'
)
  OR UPPER(
   T3.ATTRIBUTE_VALUE
) LIKE UPPER(
   '%arr%'
)
  OR UPPER(
   T4.ATTRIBUTE_VALUE
) LIKE UPPER(
   '%arr%'
)
  OR UPPER(
   T5.ATTRIBUTE_VALUE
) LIKE UPPER(
   '%arr%'
)
  OR UPPER(
   T9.STORYPLOT
) LIKE UPPER(
   '%arr%'
)
  OR UPPER(
   T10.IMDBID
) LIKE UPPER(
   '%arr%'
)
  OR UPPER(
   T10.SERIESNAME
) LIKE UPPER(
   '%arr%'
)
  OR UPPER(
   T10.SERIESSEASONNAME
) LIKE UPPER(
   '%arr%'
)
  OR UPPER(
   T10.EPISODENAME
) LIKE UPPER(
   '%arr%'
)
)
)

and produces 1.200.000 records in my case

So the "broken" search is a result of a timeout in the communication between client and server and a way to long running query.

One easier way would be to search title only, but it would be bad to loose the global filter (but it has to perform better )

 

[ge2301]

One easier way would be to search title only, but it would be bad to loose the global filter (but it has to perform better )

I think this would be pretty much, what most people would expect. Alternatively users could define what they prefer to be included within search function in settings.

 

[morpheus_xx]

The current "simple search" does automatically address all string fields for search. The logic here is straight forward:

    public MediaItemQuery BuildSimpleTextSearchQuery(string searchText, IEnumerable<Guid> necessaryMIATypes,
        IEnumerable<Guid> optionalMIATypes, IFilter filter, bool includeCLOBs, bool caseSensitive)
    {
      IFilter resultFilter;
      if (string.IsNullOrEmpty(searchText))
        resultFilter = new FalseFilter();
      else
      {
        IMediaItemAspectTypeRegistration miatr = ServiceRegistration.Get<IMediaItemAspectTypeRegistration>();
        ICollection<IFilter> textFilters = new List<IFilter>();
        ICollection<MediaItemAspectMetadata> types = new HashSet<MediaItemAspectMetadata>();
        if (necessaryMIATypes != null)
          foreach (Guid miaType in necessaryMIATypes)
            types.Add(miatr.LocallyKnownMediaItemAspectTypes[miaType]);
        if (optionalMIATypes != null)
          foreach (Guid miaType in optionalMIATypes)
            types.Add(miatr.LocallyKnownMediaItemAspectTypes[miaType]);
        if (types.Count == 0)
          types = miatr.LocallyKnownMediaItemAspectTypes.Values;
        foreach (MediaItemAspectMetadata miaType in types)
          foreach (MediaItemAspectMetadata.AttributeSpecification attrType in miaType.AttributeSpecifications.Values)
            if (attrType.AttributeType == typeof(string) &&
                attrType.MaxNumChars >= searchText.Length &&
                (includeCLOBs || !_miaManagement.IsCLOBAttribute(attrType)))
              textFilters.Add(new LikeFilter(attrType, "%" + SqlUtils.LikeEscape(searchText, ESCAPE_CHAR) + "%", ESCAPE_CHAR, caseSensitive));
        resultFilter = BooleanCombinationFilter.CombineFilters(BooleanOperator.And,
            new BooleanCombinationFilter(BooleanOperator.Or, textFilters), filter);
      }
      return new MediaItemQuery(necessaryMIATypes, optionalMIATypes, resultFilter);
    }

I see in principle following solutions:

1. Using a search from Client that affects only a specific attribute (i.e. movie title) (this is possible with available code already)
   
2. Keep the global approach but define attributes to be included in full text search (either at declaration time or manually inside search screen)
3. Keep the global search but rework the underlying query building i.e. to use "exists" subqueries instead of joins

What do our @Developers think about this?