Hey Petr,

First, it was not my intention to change the behaviour for 2.1. So I will look into restoring the year as part of the search query. The change was to only affect v3 as there's been a proper query parameter for searching with a year since day 1 and adding the year to the query string was never something we claimed to support.

Second, having said that, 2.1 was EOL'd around 14 months ago and next week is actually when I was going to notify everyone of the official shutting down of 2.1. I'll be giving developers around 120 days (4 months) to get updated so if you are still on 2.1, you might as well just switch over to v3 now. 2.1 is not long for this world.

Thanks Travis,

that would be appreciated. I'm in the middle of work on a new release, so I'll change over to v3, but it might indeed be a few months before I get there, so keeping the current behaviour for v2.1 would be great.

Thanks.

Travis, do you have any ETA on when/if we could get back the 2.1 behaviour?

I came here to post the same problem, because the search for 3.0 used to work like 2.1 where you could have the year the query. I now use the "new" year parameter and removed it from the query, but I wonder if it's possible to make this optional instead of forcing the year. I don't have much influence on what people type in the searchbox and sometimes they search using the wrong year.

For example:

http://api.themoviedb.org/3/search/movie?api_key=KEY&language=en&query=Matrix&year=1999 (this is the correct one)

http://api.themoviedb.org/3/search/movie?api_key=KEY&language=en&query=Matrix&year=2000 (this should still return a movie maybe?)

http://api.themoviedb.org/3/search/movie?api_key=KEY&language=en&query=Matrix&year=2000&year_optional=true (to not break existing implementations)

Hey Petr,

Travis, do you have any ETA on when/if we could get back the 2.1 behaviour?

I'm hoping to get time to start looking into this today.

Ruud,

Interesting idea. I'm trying to think how this could be implemented without having to do 2 separate searches on my end. The primary way would be if a param like year_optional was present, it would work more like an "ignore the year param" option and only search with the query. I'm not sure there would be a way to do this without executing 2 searches because in reality, what you're asking for here is if there is a movie with that year show it, otherwise try without. Our old search did things like this which is why we're moving away from it.

It's a hard balance of making sure we have a powerful API but at the same time, let our consumers build solutions that are unique to their problems. We can't be a the swiss army knife and still kick ass very easily :D

I don't know your implementation on the backend, but the 2.1 (and 3.0 a few days back) search did ignore the year if it wasn't a perfect match. Searching for "query=Matrix 2000" on 2.1 returned the matrix fine. Of course with a lower score as it didn't match as perfect.

You could make the year a range so it can defer slightly "&query=Matrix&year=2000&year_margin=5" allowing 1995 till 2005. This way people can determine the quality of results in their own apps and I think this can be done more easily with a single search/sqlquery on your backend.

Just that you know my background and why I need this: CouchPotato (my app) uses the folder name to search and get movie information when IMDB url is missing. Some movies have an off year because different sites/people gave back different years. So their folder is named "Moviename (2001)" while, when you go to TMDB or IMDB, the year is suppose to be 2002.

I don't know your implementation on the backend, but the 2.1 (and 3.0 a few days back) search did ignore the year if it wasn't a perfect match.

It didn't ignore it, it did 3 separate searches. As TMDb has become as popular as it has, it was unsustainable to keep it working that way from an infrastructure perspective.

I'll still consider ways to get the search to be more broad yet more specific (ummm, ya…) but it's a tricky problem to solve.

I understand.

Please consider my "margin" example above. Normally that would be set to 0 so your query is "WHERE year = $year". While setting margin would be "Where year >= $year-margin AND $year+margin". Then of course the results should be higher if it's a perfect match.