API search quality

A place for developers to advertise their TheTVDB.com enabled app and get help from other developers with the API.
Forum rules
This forum is now read-only. Support for TheTVDB.com is now available at https://support.thetvdb.com/
Locked
mlaggner
Posts: 9
Joined: Sun May 19, 2013 10:31 am

Sat Mar 01, 2014 5:21 am

Hi,

I am the main developer of the tool tinyMediaManager (http://www.tinymediamanager.org). I've got some feedback from my users concerning the search results of your API and here are some suggestions for you.

A) the search engine is not flexible as it should be:
e.g. when searching for "19 2" it finds nothing; the API returns only the right result when searching for "19-2" (id=276360).
Same goes for "The L A Complex"; the show will only be found when searching for "The L.A. Complex" (id=255045)

B) the search string should also being checked against the ID of the series (e.g. if a user does not get any useful search result, he switches over to the tvdb homepage, searches the ID and tries to get a search result through the id)

apart from that, congratulations to the super fast and stable API! I can't remember that I got any feedback from a user saying the TVDB API wos down or anything else ;)

Best regards,
Manuel
Coco
Site Admin
Posts: 2472
Joined: Tue Mar 13, 2007 8:16 pm
Location: Canada

Sat Mar 01, 2014 8:51 am

We are currently working on a new search. It's actually really difficult but it's something we're doing.

As for your second point. If I'm understanding you correctly I doubt we'll ever do that. If someone knows the series id there is no reason for them to search. You use the search to get the seriesid once you have it you just request the xml file you want. If you want to make searching a series ID work you could just check for it in your program and skip using the search if detected.
mlaggner
Posts: 9
Joined: Sun May 19, 2013 10:31 am

Mon Mar 03, 2014 4:18 am

Thanks for your response.

ad A) Are there any plans when the new search will be available?

ad B) See it from an other side: If a user got the TVDB id from somewhere else, he is unable to get to the show details by the "standard" ways. As on your web page, we also offer one search field for the user-input. If the user now inserts the TVDB id, he would expect that the right show appears as a search result (or he is redirected to the details page like IMDB does). This does not work either on your web page nor in my tool.
Coco
Site Admin
Posts: 2472
Joined: Tue Mar 13, 2007 8:16 pm
Location: Canada

Mon Mar 03, 2014 9:15 am

A) No, when it's ready.

B) If you want this feature add it to your program. I think the chances of someone doing this are very small and I'm not going to add extra overhead to the search if it's not going to benefit most people. There is no reason you can't do it with your app if you think it's worth doing. The .001 second it'll take to do really doesn't matter if it's done client side.
mlaggner
Posts: 9
Joined: Sun May 19, 2013 10:31 am

Mon Mar 03, 2014 10:18 am

okay, I try to include it into my app
simpman
Posts: 7
Joined: Tue Mar 17, 2009 12:30 pm

Sun Mar 16, 2014 3:21 am

With all due respect mlaggner is correct. Your API search methods are not working the way they should. I recently had a heck of a time trying to find "The Mole" (id=78160). No tool I used that used your API could find this show at all, with any search terms, except by ID. And that's not all, when I searched for "Law & Order" The first result is Law & Order Trial By Jury, a show that lasted one season and way down the list is the original Law & Order that was an exact match to the query I entered. There is something wrong with the way your search engine finds and prioritizes shows, and I hope you can address this issue in the future, but for the most part it works as expected.
User avatar
szsori
Site Admin
Posts: 2298
Joined: Fri Nov 03, 2006 2:23 pm

Sun Mar 16, 2014 4:12 pm

Like Coco said, we're reworking search as a part of our new site. I'll likely include the series id as an indexed string as well, since I don't think the overhead matters much in this case. But you're really re-addressing the part of the discussion that was already resolved.
Locked