

A fast, modern API for TV, Movies, Podcasts and more - codebeaker
http://openmedia.io/

======
codebeaker
I'm working on an API that doesn't suck that will represent TV, Movies,
Podcasts, WebTV, and other forms of media.

A stack-overflow inspired reputation system will reward community members to
contribute translations, new shows, movies and corrections.

Background workers interface with EPGs, other APIs and streams of data from
other sources.<p>An image proxy server means openmedia.io will do the heavy
lifting delivering images in the dimensions that you want, backed by a speedy
CDN.

~~~
ClayM
are you thinking about other forms of media, maybe something like comic books?

there's actually a pretty large need for a comic api and there's only one
right now (comicvine) that has been neglected for 2 years.

~~~
codebeaker
I'm keen for any media which is a) structured and b) is an essentially append-
only dataset.

I fear that existing APIs, through design and coincidence fail to address the
needs of flexibly covering media of all types.

Join the list, look me up, or feel free to contact me to discuss

------
codebeaker
@carbuncle - If TMDB's licence allows, I can absolutely imagine offering the
webhooks, and changes stream and a Movie type backed by TMDB. It's something
I'll have to take up with their moderators.

@theallan - It depends whether that would be a _competing service_ under
liberal interpretations of the law, when the legal chap has drawn up the API
permission guidelines, I'll be sure to notify the mailing list. Under German
law we have to be quite explicit about granting permission, but the beta list
will be notified of the full terms of usage before the API opens. (My gut-
feeling, no problem with using the data to back an app, that's sort-of what
the data's for!)

~~~
theallan
Super - I look forward to hearing more about it!

------
victoknight
Have you made any direct effort to integrate with home media solutions like
XBMC or Plex?

Edit: I would also very much like to see something like this in ifttt.com

~~~
codebeaker
Plex and XBMC would be ideal candidates for this API, each user could easily
maintain their own pointer to the data set, and their synchronisation would be
faster and more efficient than it is right now.

There's also a provision with the API (for personal use, so far) which turns a
filename (and metadata, if you have it) into a JSON hash (or msgpack, of
course) of the episode, show and season, etc.

This is also a potential avenue for being more widely made available.

------
ashray
I'm wondering about the kind of data you provide and what it's applications
would be. Just to be sure, would this API somehow let me know if a new episode
of say.. Mad Men comes out ?

Or is it only for me to query info regarding a specific episode ? What kind of
data are you going to provide ? Some examples would really help!

~~~
codebeaker
One would be able to look up a complete representation of the current known
state of Mad Men, all known airing dates in all countries, places where it
might be available to (legally.) steam in your jurisdiction, etc, etc.

These are all the features of a normal API. As well as access to the above,
you could (selectively) register for updates to be pushed to a URL of your
choosing when there are additions or amendments to the data held about the
show. (or all shows, or all shows matching your criteria, etc)

------
codebeaker
A word to the critics (thanks!), the copy has been modified to be less
rhetorical and to be absolutely gender neutral. I've also switched away from
Raleway as a body font, it looked a lot better on a retina display than on
something with a more widespread resolution.

------
kreutz
Do you see music releases being available on this at any point in time?

------
lovamova
Stop using Raleway as a body font. Please.

------
niteshade
Doesn't trakt.tv do the same thing?

~~~
codebeaker
I believe trakt.tv is the kind of service that might benefit from a simplified
back-end system if it were to use openmedia.io. They likely use thetvdb, or
epguides or similar now, or may even have their own integrations with EPGs.

Similar services: * Web: trakt.tv, watched.it, watched.li, gomiso.com,
getglue.com * Android: TV Series, TV Show Favs, Twee, DroidSeries, MyEpisodes

I don't think that trakt.tv is really competing on an API level, but the data
from openmedia.io would make building and maintaining a TV and movie tracker
trivial.

~~~
niteshade
Yeah, they use TVDB as a source, definitely. I'm just having trouble seeing
what your app does, mind explaining it a bit more?

~~~
codebeaker
The intention is to provide an API that requires little or no work on the part
of the service relying on the data. Having had to work with thetvdb's API I
can attest to having to download ~100 XML files (all languages…) in order to
determine if anything is new, their API is often 2/3 days out of date, some
internal caching problems and problems with scaling, they only deliver XML,
poorly compressed (owing to key structure).

I believe services such as trakt.tv and similar should be able to do one
thing, and do it well, offer a to-do list of shows you should watch, and
summarise what you have watched. And they shouldn't have to write thousands of
lines of code to interface with an API for what's actually quite simple.

In my (admittedly contrived, and not representative) benchmarks the JSON
representing a typical TV series is 76% smaller, and parses 56% faster (that
is probably representative of years of research and work into making fast XML
parsers, and JSON being a relatively young format)

Also, I find it strange that they don't provide a notifications API or changes
stream.

I don't want to call thetvdb specifically, many API and data providers make
the same mistakes, if one can call a missing feature a mistake. (TradeDoubler,
many financial APIs, etc)

Another departure from typical API design is to accept that many movies,
shows, books and so forth are provided simultaneously (or, close to
simultaneously), world wide, in multiple languages.

Therefore any API that purports to represent them must acknowledge that
English isn't the _default_ language, but it may have been the language in
which the media was authored, and that airing dates, shipping and printing
dates are worthless without timezone and language information.

My goal is to make an API that is easy to use, and can open the creativity of
the community up, by allowing something that is now rather difficult to become
easy.

To call out some of the problems I've tried to solve: timezones; networks;
outlets (web); airing dates vs. availability dates (locale specific); actors
vs. hosts vs. cameos; returning series under the same name; specials vs.
pilots vs. shows about a series; treating different languages with equal
weight; encoding (utf-8 naturally); gzip; msgpack... I'm sure there are many
more which I've forgotten, but that's the gist of it :-)

------
RyanMcGreal
> supported on every platform known to man.

How about some non-sexist boilerplate?

~~~
RyanMcGreal
Dear Hacker News: this persistent blind spot about the many casual,
unconscious and dismissive ways the tech community excludes women - and get
nerd-rage defensive about it when confronted - is a big part of why there are
not more women in tech.

~~~
quesera
The habit of grepping all content for keywords without understanding context
or definition inhibits rational discourse. Getting third-party apologist about
it when confronted is a dead stop appeal to authority.

~~~
RyanMcGreal
I understand the context and definition. It's still sexist. It's unnecessary
and would be extremely easy to replace with a non-sexist term that is
equivalent in both meaning and elegance. The extreme resistance even to
acknowledge that there's something wrong with using "man" to mean "humans" is
very telling.

