Hi dcsai,

I have maybe better solution. You could use /discover/movie with a vote_average.gte (to make sure you get at least one with a rating).

And here's where things would need to be decided on by you but you could introduce your random element a few different ways.

1. Use a date as your random seed data. Randomly pick a date and use something like primary_release_date.gte then pick a page and item from the results array.
2. A bare discover with vote_average.gte of 0.0 yields over 1000 pages which means you can reliably count on 1000 pages of 20 items to pick from. Randomly pick a page and an item.

Both of those options can be done making a single HTTP query.

Do either of those help?

Hello, appreciate the quick answer. If I understand correctly a query on /discover/movie outputs an array of movies, which is longer to fetch and parse than a /movie/id/XXXXX kind of query. Keep in mind I'm showing only one element at the time, so fetching an array is not needed.

Anyway it looks more solid that my actual random search as the /discover node doesn't seem to output movies without an overview.

So I was thinking about doing a mechanism like this:

1. Randomize between tv and movie
2. Pick a random first_air_date_year or primary_release_year (depending on the previous result)
3. Pick a random page nad send the query
4. Parse a random object from the query in the range 1-20

Do you confirm this is the most "random" way possible?

I wouldn't worry about the size of the request. A full page of results if you're using gzip (all browsers for instance) is only around 5.5KB. Sure, you have to parse the entire JSON blob but JSON parsers are pretty fast. You're going to have other parts of your system that are way slower than the JSON deserialization time.

more solid that my actual random search as the /discover node doesn't seem to output movies without an overview

Discover will show items that don't have an overview, but what you're noticing is because you're looking at the most popular items, they tend to be the most complete. So the chances of them not having an overview is slim. Then again, since you just pulled down 20 items, even if the one you picked between 1..20 doesn't have an overview, you can just pick another on the page. There's 19 more to try without making an extra HTTP request.

Do you confirm this is the most "random" way possible?

Ya, I don't think there's much of a difference in either proposed way. The downside to any query that will yield less than 1000 pages is that you won't know the total pages without making an initial request meaning you might go out of bounds on your first try. I keep bringing up 1000 because that's the max page you can query. My second proposal deals with this because the query you're making has more than 1000 pages meaning you can randomize 1..1000 on your first and only attempt.

Cheers.

I am implementing your second solution right now as it seems the most complete. May I ask a side question? In the docs it is not specified whether &language falls back to en-us in case there is not data present. I'm asking because I queried a show in english and it has an overview. But the same show queried with &language=sp or it (or any other minor languages) has an empty overview that does not fall back to english.

If this is the case I will have to do to who knows how many queries for any obscure language.

Cool!

Unfortunately at this time we do not support language fallbacks. I recently answered this here, if you want to read a little bit more detail about it.

I'm happy to say I got the random feature working (it is actually faster than the previous implementation) thanks to you :), will push update for the app shortly.

Anyway this languages situation is disheartening since while searching, for example, with &language=it-IT it needs at least 3-4 different page queries to find a complete show overview.

Anyway good work with the api, looking forward to v4.