Closed Bug 780379 Opened 8 years ago Closed 7 years ago

Firefox mobile cannot open .m3u8 file (broken file?)

Categories

(Firefox for Android :: Download Manager, defect)

ARM
Android
defect
Not set

Tracking

()

VERIFIED FIXED
Firefox 27

People

(Reporter: mcsmurf, Assigned: blassey)

References

Details

Attachments

(9 files, 11 obsolete files)

16.88 KB, patch
mfinkle
: review+
Details | Diff | Splinter Review
4.48 KB, patch
mfinkle
: review+
Details | Diff | Splinter Review
88.12 KB, image/png
Details
1.38 KB, patch
mfinkle
: review+
Details | Diff | Splinter Review
2.37 KB, patch
mfinkle
: review+
Details | Diff | Splinter Review
5.03 KB, patch
wesj
: review+
Details | Diff | Splinter Review
1.81 KB, patch
mfinkle
: review+
Details | Diff | Splinter Review
156.07 KB, image/png
Details
317 bytes, text/html
Details
To reproduce:
1. Install MX Player from App Store (might be optional, not sure)
2. Try to open http://zdf_ios_de-i.akamaihd.net/hls/live/204576/de03_v1/med/playlist.m3u8 with Firefox (in my case I used an Aurora build and a mozilla-central nightly to test)

Actual results:
Firefox seems to try to open that file with MX Player as the screen (sometimes) briefly turns black; shortly after that Firefox appears again. When I tap on the download notification, MX Player tells me that it cannot play that file

Expected results:
To behave like Chrome (in this case :-). Chrome asked me the first time if I want to use the Android Video player or MX Player to open that file. The second time it remembered my decision. Playing the .m3u8 file worked fine.

Maybe this bug is a dupe of another bug, not sure. I will attach HTTP headers plus file content to compare Firefox

I tested this on a Samsung Galaxy S2 with Android 4.0
It looks like Chrome and Firefox get the same data.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Duplicate of this bug: 823933
http://ib7.islambox.tv/vod/_definst_/mp4:peter/1.mp4/playlist.m3u8
http://qthttp.apple.com.edgesuite.net/1010qwoeiuryfg/0150_vod.m3u8

this urls work fine in android browser(suggests to open it with Media Player), but Firefox just downloads them

tested on galaxy tab gt-p7510
Brad, this bug leads to audio/video compatibility issues. Can you please have someone review the request?
Flags: needinfo?(blassey.bugs)
Am I right in assuming that if we pass this file off to another app on the system everyone would be happy?

The reason that isn't happening right now is that the system is telling us that there are no handlers for "application/x-mpegurl". Given that the media player handles it when clicked from the stock browser, that is surprising to me.
Flags: needinfo?(blassey.bugs)
(In reply to Brad Lassey [:blassey] (use needinfo?) from comment #5)
> Am I right in assuming that if we pass this file off to another app on the
> system everyone would be happy?

Seems to me that would make everyone happy but I would like Hallvord to confirm.

> The reason that isn't happening right now is that the system is telling us
> that there are no handlers for "application/x-mpegurl". Given that the media
> player handles it when clicked from the stock browser, that is surprising to
> me.

Right. I would have thought that the apps would have specified a handler.
Flags: needinfo?(hsteen)
Naive(?) question on this: Does Firefox mobile pass on only the file itself or the URL of the file to the external media player(, too)? Just wondering how resolving relative URLs within playlists works in this case. As you can see from the attached http log, the playlist in question only contains some relative URLs (as far as I see this) that were resolved by the media player then (or was this done by the native browser?).
(In reply to Lawrence Mandel [:lmandel] from comment #6)
> (In reply to Brad Lassey [:blassey] (use needinfo?) from comment #5)
> > Am I right in assuming that if we pass this file off to another app on the
> > system everyone would be happy?
> 
> Seems to me that would make everyone happy but I would like Hallvord to
> confirm.

iPhone seems pretty happy to play it in fullscreen, so that should be ok.

Frank Wein points out an important gotcha..
Flags: needinfo?(hsteen)
Assignee: nobody → blassey.bugs
Attachment #806704 - Flags: review?(bugmail.mozilla)
Attached image whatDoYouWantToDo.png (obsolete) —
ui review please (flag doesn't exist????)
Attachment #806709 - Flags: review?(ibarlow)
just a note, this will show up when we have a mime type that Firefox can't handle. We currently just download it, which is broken for many mime types
this applies on top of the previous two patches. The effect is to not have Firefox offering to view things it can't actually display. Notice in the screenshot I'll attach next that fennec_blassey is not listed as an option.
Attachment #806726 - Flags: review?(mark.finkle)
Attached image whatDoYouWantToDo_Mime.png (obsolete) —
Comment on attachment 806708 [details] [diff] [review]
patch to give option of passing a URI to a helper app

Review of attachment 806708 [details] [diff] [review]:
-----------------------------------------------------------------

As much as I hate other languages, I think we probably should support them.

::: mobile/android/components/HelperAppDialog.js
@@ +25,5 @@
>  
>    show: function hald_show(aLauncher, aContext, aReason) {
> +
> +    var p = new Prompt({
> +	title: "What would you like to do with this? "

Localize this

@@ +28,5 @@
> +    var p = new Prompt({
> +	title: "What would you like to do with this? "
> +    });
> +    var handlerOptions = [{
> +	label: "save to disk",

And this

@@ +32,5 @@
> +	label: "save to disk",
> +        handler: null
> +    }];
> +    let defaultHandler = new Object();
> +    let handlers = Services.androidBridge.getHandlersForURI(aLauncher.source.spec, "", defaultHandler);

If there are no handlers, I think we want to just download?

@@ +43,5 @@
> +	    item.selected = true;
> +	handlerOptions.push(item);
> +    });
> +      
> +      p.setSingleChoiceItems(handlerOptions);

Looks like the tab spacing switches here?

@@ +48,5 @@
> +      p.show(function show(data) {
> +	  if (data.button == 0)
> +	      aLauncher.MIMEInfo.preferredAction = Ci.nsIMIMEInfo.saveToDisk;
> +	  else
> +	      aLauncher.MIMEInfo.preferredAction = Ci.nsIMIMEInfo.useHelperApp;

Should this cancel the download? (aLauncher.cancel()) Talked to you about just removing this.
Attachment #806708 - Flags: review?(wjohnston)
Attachment #806708 - Flags: review-
Comment on attachment 806704 [details] [diff] [review]
pattch to add getHandlersForUrl to nsIAndroidBridge

Review of attachment 806704 [details] [diff] [review]:
-----------------------------------------------------------------

r=me with comments addressed

::: widget/android/AndroidBridge.cpp
@@ +1569,5 @@
> +                                   nsIHandlerApp * *aDefaultApp, bool *aSuccess,
> +                                   uint32_t *aHandlerCount, nsIHandlerApp * **aHandlersArray)
> +
> +{
> +    __android_log_print(ANDROID_LOG_INFO, "GeckoURL", "url: %s", NS_ConvertUTF16toUTF8(aURL).get());

Remove logging of URL, this is a privacy concern

@@ +1571,5 @@
> +
> +{
> +    __android_log_print(ANDROID_LOG_INFO, "GeckoURL", "url: %s", NS_ConvertUTF16toUTF8(aURL).get());
> +    nsresult rv;
> +    nsCOMPtr<nsIMutableArray> handlers = do_CreateInstance(NS_ARRAY_CONTRACTID, &rv);

We should check rv here

@@ +1581,5 @@
> +    handlers->GetLength(&handlerCount);
> +    *aHandlersArray = new nsIHandlerApp*[handlerCount];
> +    for (uint32_t i = 0; i < handlerCount; i++) {
> +        rv = handlers->QueryElementAt(i, nsIHandlerApp::GetIID(),
> +                                   (void**)(*aHandlersArray + i));

Do we need to check rv here? If not then there's no point even assigning it here.
Attachment #806704 - Flags: review?(bugmail.mozilla) → review+
Comment on attachment 806823 [details] [diff] [review]
patch to give option of passing a URI to a helper app

Review of attachment 806823 [details] [diff] [review]:
-----------------------------------------------------------------

Needs some cleanup, and better strings before it lands, but the code looks fine.

::: mobile/android/components/HelperAppDialog.js
@@ +28,5 @@
> +    let bundle = Services.strings.createBundle("chrome://browser/locale/browser.properties");
> +    var p = new Prompt({
> +      title: bundle.GetStringFromName("helperApp.pick")
> +    });
> +    var handlerOptions = [{

let here and above.

@@ +32,5 @@
> +    var handlerOptions = [{
> +      label: bundle.GetStringFromName("helperApp.saveToDisk"),
> +      handler: null
> +    }];
> +    let defaultHandler = new Object();

{} instead of 'new Object();'

@@ +34,5 @@
> +      handler: null
> +    }];
> +    let defaultHandler = new Object();
> +    let handlers = Services.androidBridge.getHandlersForURI(aLauncher.source.spec, "", defaultHandler);
> +    handlers.forEach(function(handler) {

If you wanted to be slightly fancier here, you could do something like:

handlerOptions.concat(handlers.map(function(handler) {
  return {
    label: handler.name,
    handler: handler,
    selected: (handler == defaultHandler)
  }
}));

@@ +53,5 @@
> +
> +    // Spin this thread while we wait for a result
> +    let thread = Services.tm.currentThread;
> +    while (retval == null)
> +      thread.processNextEvent(true);

Insert a blank line here.

@@ +54,5 @@
> +    // Spin this thread while we wait for a result
> +    let thread = Services.tm.currentThread;
> +    while (retval == null)
> +      thread.processNextEvent(true);
> +    if (retval.button == 0) {

A slightly safer version of this would be. (i.e. changing the order of the list won't break):

if (handlerOptions[retval.button].handler) {
  // call the handler
} else {
  // download
}

@@ +58,5 @@
> +    if (retval.button == 0) {
> +      aLauncher.MIMEInfo.preferredAction = Ci.nsIMIMEInfo.saveToDisk;
> +      aLauncher.saveToDisk(null, false);
> +    } else {
> +      aLauncher.MIMEInfo.preferredAction = Ci.nsIMIMEInfo.useHelperApp;

I still think we probably need to cancel the download here.

::: mobile/android/locales/en-US/chrome/browser.properties
@@ +291,5 @@
>  
>  #Open in App
>  openInApp.pageAction = Open in App
> +
> +helperApp.pick = What do you want to do?

This string feels a bit... out of place for us. Maybe we can just show the filename. Also we'd typically name the field something like "helperAppDialog.title" to give some context of where its shown to localizers.

@@ +292,5 @@
>  #Open in App
>  openInApp.pageAction = Open in App
> +
> +helperApp.pick = What do you want to do?
> +helperApp.saveToDisk = Save to disk
\ No newline at end of file

'to disk' also feels a bit technical. "Save"?
Attachment #806823 - Flags: review?(wjohnston) → review+
Per our discussion, I would suggest making this look like the other Android intents menus. It's a somewhat more expected UI to see for a choice like this. http://cl.ly/image/0p0l46213C1g
This moves HelperApps.js to a jsm module. Rips the UI specific parts of it out into the (already existent) ExternalApps object. And (yeah I know, too much), cleans it up a bit, including adding a prompt method. Relies on bug 920170 for the prompt.
Attachment #810780 - Flags: review?(mark.finkle)
This uses HelperApps.jsm to do something pretty similar to what brad was doing.
Attachment #648984 - Attachment is obsolete: true
Attachment #806704 - Attachment is obsolete: true
Attachment #806708 - Attachment is obsolete: true
Attachment #806709 - Attachment is obsolete: true
Attachment #806726 - Attachment is obsolete: true
Attachment #806729 - Attachment is obsolete: true
Attachment #806823 - Attachment is obsolete: true
Attachment #806709 - Flags: review?(ibarlow)
Attachment #806726 - Flags: review?(mark.finkle)
Attachment #810781 - Flags: review?(mark.finkle)
Attached image Screenshot
This needs the buttons added from ian's mockups. I'm still trying to figure out the best way to fit them into Prompt.java and PromptInput.java's interaction. I decided that I'd save that for at least a separate patch.
Comment on attachment 810780 [details] [diff] [review]
Move HelperApps to a jsm

>diff --git a/mobile/android/chrome/content/browser.js

>+  _setForUri: function _setForUri(uri, apps) {

Rename to _setUriForPageAction, so we are more explicit about what the method is about to do

>diff --git a/mobile/android/chrome/content/HelperApps.js b/mobile/android/modules/HelperApps.jsm

>+const Cc = Components.classes;
>+const Ci = Components.interfaces;
>+const Cu = Components.utils;
>+const Cr = Components.results;

Can we use the new, cool way?

const { classes: Cc, interfaces: Ci, utils: Cu, results: Cr } = Components;

>+Cu.import("resource://gre/modules/XPCOMUtils.jsm");
>+Components.utils.import("resource://gre/modules/Services.jsm");
>+Components.utils.import("resource://gre/modules/Prompt.jsm");

Use Cu

>+  prompt: function showPicker(apps, promptOptions) {
>+    var p = new Prompt(promptOptions).addIconGrid({ items: apps });

var -> let

>+  getAppsForProtocol: function getAppsForProtocol(scheme) {

>+    var results = {};

var -> let

>+    for (var i = 0; i < protoHandlers.length; i++) {

var -> let
Attachment #810780 - Flags: review?(mark.finkle) → review+
Comment on attachment 810781 [details] [diff] [review]
Patch 2/2 - Use HelperApps.jsm in HelperAppDialog

>diff --git a/mobile/android/locales/en-US/chrome/browser.properties b/mobile/android/locales/en-US/chrome/browser.properties

> helperapps.pick=Complete action using
> helperapps.saveToDisk=Download
>+helperapps.pick=Complete action using
>+helperapps.saveToDisk=Download

Remove the dups (I think you're just testing me)
Attachment #810781 - Flags: review?(mark.finkle) → review+
Status: NEW → ASSIGNED
Attached patch Patch 1/3Splinter Review
Forgot to add the "Always" and "Just once" buttons here. But while I was doing it I wondered why I wrote the HelperApps.prompt method to be synchronous. This undoes that.
Attachment #818140 - Flags: review?(mark.finkle)
Attached patch Patch 2/3 (obsolete) — Splinter Review
Update the ExternalsApps code to the new API (and add a button). This makes the little Android icon

1.) Show the prompt if its got multiple options. Its useful here because it can filter out HTTP handlers.
2.) Show an Ok button on the prompt so that you can close it. I'd like to remove that and just make clicking close the dialog. Lets do that somewhere else though.
This adds always/just now buttons to the Helper Apps dialog. It also supports setting a pref if you select always.
Attachment #818141 - Flags: review?(mark.finkle)
Attachment #818143 - Attachment is patch: true
Attachment #818143 - Flags: review?(mark.finkle)
Attachment #818140 - Flags: review?(mark.finkle) → review+
Comment on attachment 818141 [details] [diff] [review]
Patch 2/3

>diff --git a/mobile/android/chrome/content/browser.js b/mobile/android/chrome/content/browser.js

>     this._pageActionId = NativeWindow.pageactions.add({

>+          HelperApps.prompt(apps, {
>+            title: Strings.browser.GetStringFromName("openInApp.pageAction"),
>+            buttons: [
>+              Strings.browser.GetStringFromName("openInApp.ok")
>+            ]

Shouldn't we add the "Cancel" button too?

>diff --git a/mobile/android/locales/en-US/chrome/browser.properties b/mobile/android/locales/en-US/chrome/browser.properties

>+helperapps.alwaysUse=Always
>+helperapps.useJustOnce=Just once

These are not used in this patch. They are used in the next patch. You should move them just in case the patches land in weird ways.

>+openInApp.ok = Ok

Ok -> OK

r- to get the "Cancel" button. And we should get Ian to approve a screenshot.
Attachment #818141 - Flags: review?(mark.finkle) → review-
Comment on attachment 818143 [details] [diff] [review]
Patch 3/3 - Make the HelperAppDialog also show button

>diff --git a/mobile/android/components/HelperAppDialog.js b/mobile/android/components/HelperAppDialog.js

>+      if (data.button == 0) {
>+        this._setPref(aLauncher, apps[data.icongrid0]);
>+      }
>+      });

Indent the "if" block

>+  _getPrefName: function getPrefName(mimetype) {
>+    return "browser.download." + mimetype.replace("\\", ".");

We hang a lot of prefs directly off of "browser.download." so let's use "browser.download.preferred."

But I wonder if we should be using the Launcher's preferredApplicationHandler settings?

>+  _getPref: function getPref(launcher) {

_getPref -> _getPreferredApp

>+  _setPref: function _setPref(launcher, app) {

_setPref -> _setPreferredApp


r+ with the nits fixed and move the strings into this patch, but think about why we shouldn't use the HandlerApp's system for remembering preferred apps
Attachment #818143 - Flags: review?(mark.finkle) → review+
(In reply to Mark Finkle (:mfinkle) from comment #28)
> r- to get the "Cancel" button. And we should get Ian to approve a screenshot.

Yeah. I was actually avoiding this because we're not including "Cancel" on the other dialog. We also don't include it in the crash reporter dialog either. And I've seen a few random Google apps not include it at times either (Calendar in particular). Instead, they just back to exit the dialog. I've kinda grown to like the idea of reducing some clutter by removing it.

But digging around, a lot of apps (most) DO include it all the time. And its in screenshots for Android's UX guidelines [1]. Probably better to include it and avoid confusing users.

https://developer.android.com/design/patterns/confirming-acknowledging.html
Attached patch Patch 2/3 (obsolete) — Splinter Review
Fixup. Also, there's a screenshot of this at:

http://dl.dropboxusercontent.com/u/72157/intents.png

I think the blue highlight needs tweaking :)
Attachment #818141 - Attachment is obsolete: true
Attachment #818529 - Flags: review?(mark.finkle)
Also, our preffered application handler stuff comes from Android itself [1] (incorrectly right now, filing...). There USED to be interfaces to request something be made the preferred handler in PackageManager. They've all been deprecated at this point :( So I need to fix getting the handler, but with these custom dialogs, we can't set the preferred handler.

Maybe these pref should be handled by HelperApps.jsm instead (with an optional prefix so that we can have separate behaviour in different boxes?).

[1] http://mxr.mozilla.org/mozilla-central/source/uriloader/exthandler/android/nsMIMEInfoAndroid.cpp#52
(In reply to Wesley Johnston (:wesj) from comment #31)
> Created attachment 818529 [details] [diff] [review]
> Patch 2/3
> 
> Fixup. Also, there's a screenshot of this at:
> 
> http://dl.dropboxusercontent.com/u/72157/intents.png
> 
> I think the blue highlight needs tweaking :)

It looks like just removing the border should do it.
Attachment #818529 - Flags: review?(mark.finkle) → review+
Comment on attachment 818529 [details] [diff] [review]
Patch 2/3

Wait. This is the wrong patch. This is Patch 1/3.
Attachment #818529 - Flags: review+ → review-
Attached patch Patch 2/3Splinter Review
Whoops. Thanks. This handles the page action.
Attachment #818529 - Attachment is obsolete: true
Attachment #818685 - Attachment is obsolete: true
Attachment #818686 - Flags: review+
Attachment #818685 - Attachment is obsolete: false
Attachment #818685 - Flags: review?(mark.finkle)
Attachment #818143 - Attachment is obsolete: true
My brian is obivoulsy not working right now. Here's the right patch here. The other one updates the icons to not have a border. Fixing...
Attachment #818691 - Flags: review+
Comment on attachment 818686 [details] [diff] [review]
Patch 3/3 - Make the HelperAppDialog also show buttons

I assume this is the wrong patch. Obsolete?
Attachment #818685 - Flags: review?(mark.finkle) → review+
Yeah. You beat me to finishing the upload :) This just removes the bright border. 

http://dl.dropboxusercontent.com/u/72157/intentchooser.png
Attachment #818706 - Flags: review?(mark.finkle)
Attachment #818706 - Flags: review?(mark.finkle) → review+
Comment on attachment 818686 [details] [diff] [review]
Patch 3/3 - Make the HelperAppDialog also show buttons

Obsoleting this one
Attachment #818686 - Attachment is obsolete: true
Attachment #818686 - Attachment is patch: true
(In reply to Wesley Johnston (:wesj) from comment #39)
> Created attachment 818706 [details] [diff] [review]
> Patch 3/3 - Update graphics
> 
> Yeah. You beat me to finishing the upload :) This just removes the bright
> border. 
> 
> http://dl.dropboxusercontent.com/u/72157/intentchooser.png

Looks great Wes. Ship er :)
https://hg.mozilla.org/mozilla-central/rev/0cc4a019835f
https://hg.mozilla.org/mozilla-central/rev/aec9897dc66d
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 27
Keywords: verifyme
I've tried to verify the fix, but not sure if this now works as expected as the UI does not work at all on some test page with an m3u8 file: I went to http://www.tagesschau.de/multimedia/livestreams/livestream-eins100.html and clicked on the Play button with a 2013-10-20 nightly build. Then I get the result in the screenshot. I get two options: Download the file or use the app "Filme" ("Movies" in English, some app from Sony). And at this point I'm stuck. I've tried to tap on an option/app, tap and hold on an app, nothing happens. I've also now installed "MX Player" as I was not sure if "Filme" can actually open m3u8 files (MX Player should be able to). But nothing changed. I'm a bit puzzled how this UI should work, a bug?
To make testing easier: It opens this m3u8 file when tapping on the play icon: http://tagesschau-lh.akamaihd.net/i/tagesschau_1@119231/master.m3u8 (not sure if this is a stable URL or just something that changes every few days; it's a live stream from a German TV program)
Comment on attachment 819651 [details]
Bug with the new feature?

this looks as expected.
I've attached a Firefox (remote) debugger to the main process, in the Console (with Net/CSS/JS/Security/Logging enabled) it says when tapping on the play icon on that page:
[16:54:09.377] Sending: {"type":"Intent:GetHandlers","mime":"application/vnd.apple.mpegurl","action":"","url":"http://tagesschau-lh.akamaihd.net/i/tagesschau_1@119231/master.m3u8","packageName":"","className":""}
[16:54:09.395] Unexpected selection from grid: undefined

No further log messages appear when tapping on any icon/app in the UI from the screenshot. Maybe I should file a new bug about this issue?
I forgot the
[16:54:06.288] GET http://tagesschau-lh.akamaihd.net/i/tagesschau_1@119231/master.m3u8 [HTTP/1.1 200 OK 635ms]
part of the log.. (appears before the "Sending: " part).
Yeah. Tree was closed during my first push. I tried a new trick to reapply and push and apparently lost this bit. Thanks. Pushing :)
Depends on: 929488
Did everything land here? This is more or less not entirely working for me, see dependancy.
The link at http://qthttp.apple.com.edgesuite.net/1010qwoeiuryfg/0150_vod.m3u8 works fine for me on nightly, but you're right the ones in bug 929488 have trouble loading.
>+    63       app.launch(aLauncher.source);
>     64       if (!app.launch(aLauncher.source)) {

doesn't this launch the app twice?
Depends on: 930179
Depends on: 931469
Depends on: 932641
This bug doesn't seem a suitable place for handling <video src="foo.m3u8">, so I've filed bug 941351. Will move the dependencies there.
No longer blocks: 804994, 902883
See Also: → 957963
As a heads up, m3u8 is an extended playlist file.  There's no need for a media element to have to handle these natively; playlist files can be parsed in JavaScript and fed 1 by 1 to a media element.  See: https://github.com/nickdesaulniers/javascript-playlist-parser
Further, m3u8 is possibly the stupidest of playlist types; playlist files such as m3u were used before we had nice file containers that had metadata; the playlist file was used for adding metadata when the container did not allow for it.  But parsing metadata from the container is pretty easy nowadays; ffmpeg can be used server-side to parse this information.
Nick: that's interesting, thanks! I suppose it might be a quick fix to bug 941351 (if there isn't more Apple-specific things in the way the video itself works) to add some JS like yours to run the <video> element? I suppose it would need to run in chrome to make sure we do not run into cross-domain issues.
> I suppose it would need to run in chrome to make sure we do not run into cross-domain issues.

Indeed, the biggest challenge with supporting playlist files is not the assets they refer to, as the src attribute of a media element my be cross origin (not sure about cross protocol ie. mixed content), but with fetching the playlist file cross origin as text/plain to parse.

Now, I had first stumbled upon this bug as the weekly meeting mentioned support for HLS, or HTTP Live Streaming, which is something that I find very interesting.  If we could make Firefox support the HLS protocol as the client, like we did recently with the ICY protocol (also extensively used for streaming audio), now that would be interesting.
See Also: → 955980
Verified as fixed in builds:
32.0a1 (2014-06-04)
31.0a2 (2014-06-04)
30.0b10
29
Device: Galaxy Nexus (Android 4.2.1)

Notes: I used http://qthttp.apple.com.edgesuite.net/1010qwoeiuryfg/0150_vod.m3u8
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.