Oh wow, this is huge! Can't wait to start integrating these features into my app. Awesome work.

Yes! Thanks for the video progress stuff, I already have some ideas for using this data.

It's surprising to see you exposing the stream URL officially. What are the rules for using it? Mobile only?

How about bulk list of saved progress? That would allow something like "Continue watching" on Netflix with a list of recently watched stuff.

This is ace! I was already working on my own limited playback position syncing stuff, so this is great to see!

This is the best. THANK YOU

@szlifier: we have had devs asking for that feature for a long time. I like to try and be more open whenever possible. We've put it behind API authentication so hopefully it won't be a problem. If we see any problems we'll just have to track down the API keys being used and ban them. Worst case scenario we can enable authentication on the stream URL itself but hopefully it won't come to that. As far as rules for using we would like to see it only used in apps like mobile and set top boxes, if we see sites re-hosting our content for free we'll have to shut down those API keys.

@szlifier: Getting a bulk list of saved progress would be great. Something like http://www.giantbomb.com/api/video_progress/?api_key=<USERS_API_KEY> that returns a list of all videos (just the IDs would suffice?) that user currently has progress for and the progress for each video.

@alecgdouglas: That's a good point, we're investigating that functionality for the site but aren't there yet, as soon as that functionality is available on the site we'll create an API for it!

@wcarle: Hey, I tried to use the video progress stuff on my site, but JSONP seems to be missing, so I can't make any requests from the client side.

Awesome! Perfect timing to roll support for this into our new app. Great work!

@szlifier: Ah good point, didn't think about JSONP for that one, I'll get that in there soon!

I'm rolling this in today,

@wcarle - Is it too late to change this?

GET Response for an id which you have no saved time returns "savedTime" as an int.

{

"success": 1,

"savedTime": -1,

"message": "No saved time for this video id"

}

--- GET Response for an id which you have saved some time against - returns a string with a Float or Double? Is it possible to unify and get them to both return the same type? Not a big thing but it'd be slightly nicer for those of us using statically typed languages.

{

"success": 1,

"savedTime": "20.186404"

}

Update: S'fine really, I support both now - leaving up in case you find the suggestion useful for some future enhancement. Working perfectly btw :D

@wcarle Are you planning on adding "last updated" timestamps to the video progress API? Should make syncing more robust, as apps can then discard out of date progress (in cases where the user was offline then came back online).

@wcarle: Hey, just wanted to ask again for JSONP for get-saved-time. I can't really utilize this great feature on a website without it.

And since you already implemented the Continue Watching idea, how about making that list available through API? :)

I also have another request. It's not urgent, but I would love to have it.

Almost all videos and most podcasts (and podcast videos) are attached to wiki pages, mostly game pages. It would be great to have those associated wiki pages in the video endpoint. For example: the API info for Quick Look: Snake Pass would include "3030-57504" - indicating a game resource and the id.

Right now it's only possible the other way around. A game info in the API includes videos, podcasts and other wiki resources. EDIT: It looks like podcasts are not included in that list, only video versions of podcasts. Unfortunately this can only be done on a per-game basis (/game and not on /games).

This is something I've been asking for a very long time and it would be an awesome thing to have for my site. It would make game <-> video associations finally complete. Thanks.

@szlifier: Hey, sorry I forgot to post about the updated endpoints, JSONP should now work:

http://www.dev.giantbomb.com/api/video/get-saved-time/?video_id=11863&format=jsonp&callback=asdf

The get saved times api is available here (but it doesn't currently include the video information):

http://www.dev.giantbomb.com/api/video/get-all-saved-times/?format=jsonp&callback=asdf

I'll put that other API Request in on the list!

@wcarle: Thanks! This is fantastic.

Looks like the api key isn't required if you're logged in on GB in that browser. Cool stuff. I implemented it already on QLCrew.

@wcarle:That get-all-saved-times API is exactly what I was hoping for.

Quick question: the "savedOn" field - does that have a fixed timezone? (PST I'm guessing?)

@wcarle: Any plans to add the ability to delete/reset progress on a video?

I currently have that functionality in my app with saved time stored locally and I'm not sure how provide the same functionality with the save-time API since passing in time_to_save=0 fails (returns success = false).

Using time_to_save=-1 works fine (I could ignore results from get-saved-time/get-all-saved-times if savedTime = -1) but I don't want to be using the API in an unintended way and modifying user data to invalid values.

@alecgdouglas: Yes saved on is set to PT. We don't currently have a way to reset progress. I'm not sure why it's failing when you set it to 0, I'll look into that

@wcarle: Thanks for looking into it.

Regarding the live API, I've noticed that it's pretty consistently returning a result long after the live stream is actually over (e.g. Giant Beastcast is advertised as live via the API for many hours after the stream ends), and sometimes long before a live stream has actually started (e.g. it's been returning the April 28 GBE Playdate video as the live stream URL since last night with the title "GBE Megadate" which doesn't start until 11 AM today).

This is a bummer since there's not really a good way for an app to know if the current-live API is returning an actual live stream or not, which results in my app basically deceiving and confusing users by saying there's a live stream ongoing when there actually isn't.

Are there any plans to tighten up the results of the current-live API?

@wcarle is it on purpose that only the last 100 times get saved? Seems like older data just gets lost.