dbr/Ben

> I would rather the unsafe part be largely wrapped in solid library code rather than forcing the intellectual burden and also some safely risk onto the user. I think...

> This could easily be feature-gated though, so there is no hard dependency True, although I think there is some benefits to having it be a separate crate, mainly the...

A way to catch this at compile time would be to abstract away the SQL string, like with an ORM framework - which I would suspect is out-of-scope for this...

> We can add support for zooming in even further based purely on scaling rather than rendering the whole page at higher resolution Personally I think this is a good...

Glad you find it useful! Do you mean looking it up by the TVDB ID number? If so, you just pass it as an integer instead of the show name...

Ahh, I see what you mean. Nope, this currently isn't exposed by `tvdb_api` - currently it only gets data via the `/series/` thing, not `/episode/`, http://thetvdb.com/wiki/index.php/Programmers_API#File_Structure

This is still valid with the new API, there is a [`/episodes/{id}`](https://api.thetvdb.com/swagger#!/Episodes/get_episodes_id) endpoint

Thanks for the info - I didn't get that message (despite having up-to-date contact info with my old v3 API keys) I have no idea what is happening with the...

That's a good idea. Currently you can do this in a semi-reasonable way by changing the config keys: ```python t = tvdb_api.Tvdb(...) t.config['api_url'] = "https://api.thetvdb.com" ``` (there is also a...

Thanks for this! I'll look at merging this in as soon as I can - I may implement it slightly differently, I'd rather a more specific check than catching tvdb_error...