Search Each Library Individually

[Davey's 40]

Also would be nice to search for artist, filename or  title only

[Lyfesaver 135]

2 minutes ago, Davey's said:

Also would be nice to search for artist, filename or  title only

Okay now you are just talking crazy... get out!!

 

 

Honestly, not a bad idea

[brothom 211]

19 minutes ago, Davey's said:

Also would be nice to search for artist, filename or  title only

Agreed. I also miss the functionality to filter / search by text field. Currently the filters only consist of selects/dropdowns/checkboxes and it would be nice to be able to search by text in the library itself as well.

I believe there's also some other FR's that have this exact question and by providing (at least one, for the title) textfield per library that would resolve those FR's as well.

[ebr 16344]

We have plans to improve this. We just have a LOT to do and cannot get it all done at the same time.

Thanks.

[Davey's 40]

@ebrThanks for the update

[IAmHugh 64]

4 hours ago, ebr said:

We have plans to improve this. We just have a LOT to do and cannot get it all done at the same time.

This has been in the works since avt least 2018

[l4kr411 1]

Is there a way to not show episodes from TV Shows in search? 

[IAmHugh 64]

6 hours ago, l4kr411 said:

Is there a way to not show episodes from TV Shows in search? 

Short answer NOPE

[IAmHugh 64]

GEE after getting fed up once again with Emby's BS over permissions I gave Jellyfin another look. Sure enough as usual Jellyfin don't and doesn't have any issues with the default permissions. Jelly fin has a per library search. Jellyfin logs cover everything, no having a issue and having to switch to trace or debug and wait and see if the issue happens again so you can post the logs. The only issues I see with Jellyfion are no folder view under movies, episode view for TV on the server app but no in the app for the TV, linking to themes and theme components instead of end-user editable code. There may be some features Emby has that would be nice to have in Jellyfin but overall Jellyfin seems to fit my needs just fine.  

[Music100 35]

 

Following up on this topic, the ability to search within a specific library remains an essential and unresolved need. In practice, the current all-library search continues to slow down workflows, surface irrelevant results, and make it unnecessarily difficult to locate known items in large, organized collections. For users managing multiple libraries by type or quality, this is not a minor convenience but a fundamental usability gap. Adding library-specific search would materially improve precision, speed, and overall efficiency, and still feels like a missing core feature. I hope I have not missed any recent developments on this.  Cheers.

[IAmHugh 64]

7 hours ago, Music100 said:

Following up on this topic, the ability to search within a specific library remains an essential and unresolved need. In practice, the current all-library search continues to slow down workflows, surface irrelevant results, and make it unnecessarily difficult to locate known items in large, organized collections. For users managing multiple libraries by type or quality, this is not a minor convenience but a fundamental usability gap. Adding library-specific search would materially improve precision, speed, and overall efficiency, and still feels like a missing core feature. I hope I have not missed any recent developments on this.  Cheers.

Unfortunately you have not missed any developments on this, muchless any movement in years or if at all. We still also have the issue of searching in settings and only getting media results. It's a sad state as far as I'm concerned, hence why it's one of many reasons that I have moved to Jellyfin.

[Luke 42254]

Hi, library specific search is something that we plan to add. Thanks.

[IAmHugh 64]

9 hours ago, Luke said:

Hi, library specific search is something that we plan to add. Thanks.

Yea since 2018 at minimum. 

Edited Wednesday at 07:42 AM by IAmHugh

[Teredactle 40]

I have 3 main reasons why I'm looking to moving off Emby, and exploring Jellyfin.  This is one of them.

I'd like to hear from developers why such a basic search function is not given more priority. I find this a basic function, and getting cookie cutter responses on fixing basic functionality seems to a be a brush off; it's why initially move away from Plex - focusing on anything else but fixing basic functionality. 

[IAmHugh 64]

16 hours ago, Teredactle said:

I find this a basic function, and getting cookie cutter responses on fixing basic functionality seems to a be a brush off;

It is a brush off because a I and others have stated Emby is a one man show. What he wants and everyone else be damned.

[visproduction 336]

I know, no one likes to read detailed info on getting a search function to work, but everyone likes to ask why can't you do it.  This is a classic, easier said than done, issue.  Big online companies typically spend a lot of time and money to get search to work and such big online sites search code with Google is a big part of their company value.  They have easily spent millions of dollars on their searches.

If you all listed exactly the functionalitity you would like, that would be a big help.  Otherwise, in going through design options, every possible way is on the table and that is messy.

Here are some of the search commands using what is called Select query in a SQL dbase.

 https://blog.devart.com/how-to-search-for-database-objects-and-table-data-in-sql-server.html

If you happen to be on an Emby library page, then the function would be to search within this library only.  There are a few problems with that.

The page link is hidden in the URL for better site security.  The URL location is ...videos?servierId=438234442[some long link name]...&parentId=3

The name of the library is created via .js script on page load and is written as a title on the page.  Then all the directories for this library are nested, further into the admin setup code where the admin has attached subdirectories from the library edit selection.  Search is now setup to look everywhere.  So, how would search know to look only in these subdrectories when the user is on this particular library page and it is not easy to see from the URL what page you are on? 

The URL link is an encrypted tag, so that is not really ideal. It's possible to send the encrypted URL to get the lookup and then add to the lookup, but it's an extra step.  It would be better to have the original select lookup for each library.

The name of the library is pulled from a js file and added to the page, so finding the title name on the page is not really ideal either, you would still have to reverse look up what sbdirectories are listed that belong to that title.  If the title is long with spaces or strange characters, then that reverse search lookup for subdirectories function has to work with any possible long name that the admin might choose...  possible, but not ideal and would probably break.

You could create a pull down list or check boxes of what library to search.  That might not look so nice if the admin has 50 libraries with long name.  Then the same issue can apply for searching within Collections or Playlists.  A lot of long names, strange foreign languages characters would make any long list look like the page is broken.  So, that is not ideal. 

So, ideally you would want the selective search to automatically know what page the user is on, search accordingly and maybe have an option button to widen the search results.  If the process to find what page, the user is on, causes additional function to reverse look up, then it would be perhaps better to save and reuse the select SQL lookup that created the library page pull that select query, to search further.  I think that search is probably thrown away and not saved anywhere.  Saving that SQL select lookup and adding more search requests to it, is perhaps a good solution.  To do that, you would have to create a store and cache variable function for every time any library or collection page is called to attach this select query somehow on the page or a reference to it so that, even if the user has other pages open, when they eventually come back to the open page for a particular library, then the search within this library will still work, hours later.

Those are some of the problems.  The question is how do you design this so the extra cached data does not slow down the page load, everytime any user opens each library or collection.  For an online server based product, the server would handle it, but Emby is based on the user having a server, so any page load and cache additional lookup has to work for every server design, server speed and OS and not slow the page load.  Perhaps only cache this data several seconds after the page loads and only if the user has not clicked on something for say 10 seconds.  Also, only show the search button after this delay.  That might help.

OK, now solve this in a way that can most easily be run by anyone with any list of libraries, collections and playlists, inside genre or tags pages on any version of the server and not have the search code break.  Make sure that the user's server does not increase the page load cache right away, so there is no noticible delay.  Make sure that all search sub-directories in all locations to all attached hard drives doesn't break when the select query targets only these sub-directories.  Then test this new advanced limited search function for all OS, on Web, TV, mobile, different browsers and make sure that any new info that comes up when running the search doesn't cause any page to break or have any part of the search window run off the screen or overlap anything for all screen sizes, mobile, tablet, workstation and TV apps.

So those are just the steps to plan it. Maybe stop thinking that it should be easy.

 

Edited 28 minutes ago by visproduction