changes to streaming API at put.io won't load Avia

[ldeviator]

I have been using this app and Avia to sling video from put.io to my Chromecasts. Ever since mid-day yesterday 2/11/2014, hitting Play in the put.io app on mp4's won't give me the option to load Avia like it did before that. However, mkv (video/x-matroska) and avi (video/x-msvideo) work fine.

I contacted put.io thinking something had changed and they confirmed they had: "We changed the links to https from http"... not sure that would break it, but maybe that would mess up the put.io app?

I've checked the headers at put.io API with mp4/mkv/avi like so:

https://api.put.io/v2/files/######/download?oauth_token=XXXXXX

And nothing looks weird in the responses (filenames/sessions/etags changed to XXXX):

MP4:

HTTP/1.1 200 OK Server: nginx Date: Wed, 12 Feb 2014 19:49:23 GMT Content-Type: video/mp4 Content-Length: 377569013 Connection: keep-alive Keep-Alive: timeout=60 Content-Disposition: attachment; filename="XXXX.mp4" Set-Cookie: session2=XXXX Domain=.put.io; HttpOnly; Path=/ Last-Modified: Sun, 09 Feb 2014 03:46:47 GMT ETag: "XXXX" Accept-Ranges: bytes

MKV:

HTTP/1.1 200 OK Server: nginx Date: Wed, 12 Feb 2014 19:47:35 GMT Content-Type: video/x-matroska Content-Length: 2106167945 Connection: keep-alive Keep-Alive: timeout=60 Content-Disposition: attachment; filename="XXXXXXXX.mkv" Set-Cookie: session2=XXXX; Domain=.put.io; HttpOnly; Path=/ Last-Modified: Sat, 23 Nov 2013 06:54:12 GMT ETag: "XXXX" Accept-Ranges: bytes

AVI:

HTTP/1.1 200 OK Server: nginx Date: Wed, 12 Feb 2014 19:45:09 GMT Content-Type: video/x-msvideo Content-Length: 1415067648 Connection: keep-alive Keep-Alive: timeout=60 Content-Disposition: attachment; filename=XXXXXXXX.avi Set-Cookie: session2=XXXX; Domain=.put.io; HttpOnly; Path=/ Last-Modified: Fri, 17 Jan 2014 18:37:02 GMT ETag: "XXXX" Accept-Ranges: bytes

[DSteve595]

This is the second report I've seen about this. Thanks very much for all the logging stuff and especially the notice about the API change. I emailed the Avia team a few hours ago about it.

[curreta]

As a side to the "We changed the links to https from http" - I believe this was the fix for that contest they ran for fixing the multi-threaded downloads in that one downloader (slipping my mind now).

Not sure if that helps this issue, but I think that was the reason.

[DSteve595]

Makes sense. Avia probably has an HTTP intent filter for videos but no HTTPS. I'm assuming put.io changed it for a reason, so now it's up to Avia to push out an update. Thanks again for the info, guys.

[ldeviator]

Hmmm.. I'm not sure https is really the issue... it seems like there's contradictory evidence... for instance if I ask put.io's API for the above AVI (video/x-msvideo), it first responds with an HTTPS redirect link also.

HTTP/1.1 302 FOUND Server: nginx Date: Thu, 13 Feb 2014 13:53:08 GMT Content-Type: text/html; charset=utf-8 Content-Length: 611 Connection: keep-alive Keep-Alive: timeout=60 Location: https://atlanta2.put.io/download/[PUTIOFILEID]?tunnel=1&storage=s09&token=[PUTIOTOKEN]&u=[PUTIOU]&attachment=1 Access-Control-Allow-Origin: ://None Set-Cookie: session2=[COOKIE]; Domain=.put.io; HttpOnly; Path=/

and then that redirect loads the actual AVI:

HTTP/1.1 200 OK Server: nginx Date: Wed, 12 Feb 2014 19:45:09 GMT Content-Type: video/x-msvideo Content-Length: 1415067648 Connection: keep-alive Keep-Alive: timeout=60 Content-Disposition: attachment; filename=XXXXXXXX.avi Set-Cookie: session2=XXXX; Domain=.put.io; HttpOnly; Path=/ Last-Modified: Fri, 17 Jan 2014 18:37:02 GMT ETag: "XXXX" Accept-Ranges: bytes

So does mkv (video/x-matroska), which works and MP4 (video/mp4) which doesn't.

MP4 is the same:

HTTP/1.1 302 FOUND Server: nginx Date: Thu, 13 Feb 2014 14:08:40 GMT Content-Type: text/html; charset=utf-8 Content-Length: 605 Connection: keep-alive Keep-Alive: timeout=60 Location: https://atlanta.put.io/download/[PUTIOFILEID]?tunnel=1&storage=s02&token=[PUTIOTOKEN]&u=[PUTIOU]&attachment=1 Access-Control-Allow-Origin: ://None Set-Cookie: session2=[COOKIE]; Domain=.put.io; HttpOnly; Path=/

followed by:

HTTP/1.1 200 OK Server: nginx Date: Wed, 12 Feb 2014 19:49:23 GMT Content-Type: video/mp4 Content-Length: 377569013 Connection: keep-alive Keep-Alive: timeout=60 Content-Disposition: attachment; filename="XXXX.mp4" Set-Cookie: session2=XXXX Domain=.put.io; HttpOnly; Path=/ Last-Modified: Sun, 09 Feb 2014 03:46:47 GMT ETag: "XXXX" Accept-Ranges: bytes

Interestingly, AllCast, the effort by the clockworkmod guys, also craps out on the same MP4s when casting to Chromecasts. AllCast will let you launch the MP4s, but then causes a crash 100% of the time in "Google Play Services". The files that work with Avia also work in AllCast when launched from putio.

[DSteve595]

The app resolves the redirect before handing it off to the video player.

[ldeviator]

So in all cases, MP4/MKV/AVI, an https link is handed to the video player, right? ... i.e. the app hands off the "Location" header (via resolveRedirect()) from the first message, and all those Location headers are now https, which look like:

https://atlanta2.put.io/download/[PUTIOFILEID]?tunnel=1&storage=s09&token=[PUTIOTOKEN]&u=[PUTIOU]&attachment=1

yet only MKV and AVI work, but MP4s don't... so that's why I'm not certain https is the issue... I'd expect all 3 to fail if https was the issue since https is always handed off.

I was flipping through the put.io app code... it looks like some of the https's are being changed to http's in the code though... I wonder if something is up there?

PutioUtils.java @ line 610: resolveRedirect(getFileDownloadUrl(id).replace("https://", "http://")))

looks like there's a few of those kinds of things in that file : url.replace("https://", "http://") in there.

also... mp4's mime type should be video/mp4 I think... that's the mime type coming off put.io's servers.. wondering if something is getting a mismatch?

libraries/aFileChooser/src/main/res/xml/mimetypes.xml @ line 53:

[ldeviator]

more testing... now all my different file types don't pull up Avia, so it's no longer just mp4s. Maybe my Android was caching or something? I dunno.

So you're right, Avia must not listen for https links.

I set up a local test just to confirm: I made a webserver that sets the MIME type for .mp4 to "video/mpeg". Using HTTP, this pulls up Avia. Using HTTPS, it doesn't.

[DSteve595]

Yep, it's something the Avia guys have to take care of. I'm still waiting for a response, but I wouldn't worry about it; I've started adapting to the new Cast API, which finally came out today. Should have it ready very, very soon!

[ldeviator]

awesome news... won't have to worry about this middle man stuff :)

[DSteve595]

First beta's in the Play Store!