It seems that Licensed JWPlayer 6.12 and iOS don't get along. When using JWPlayer 6.12 and iOS playback on some devices is broken. When either using an unlicensed version or 6.11 it works fine.
As of this writing the cloud version of JWPlayer is 6.12..
I don't think anyone else has reported this problem, which would indicate that it's unique to you. Please give us a link to your site.
Base URL http://goo.gl/TrhCz7
/jw-cloud-key.php
/jw-no-key.php
/jw-key.php
The base URL is now using 6.11
"The base URL is now using 6.11"
Well, that's certainly no help at all.
How so?
Ohhhh geeze......
Base URL = 6.11
Base URL + /jw-cloud-key.php = JWPlayer Licensed using the cloud player (6.12)
Base URL + /jw-no-key.php = JWPlayer Unlicensed using the cloud player (6.12)
Base URL + /jw-key.php = JWPlayer licensed using the non cloud player (6.12)
Sorry, I just didn't understand the links you were posting. I was expecting a simple, "here's a link that shows the error," along with some description of the failure symptoms you're getting.
For the benefit of anyone else trying to check this, who doesn't want to through the fol-de-rol of a shortened link, and then having to copy and paste directories to it:
http://livefromsonoma.com/jw-cloud-key.php
Your 6.12 demo pages don't appear to have a valid DOCTYPE. I don't think that will produce errors, but it should be fixed, in any event. Ditto for using strings instead of booleans for true and false on various attributes.
Super.... I was trying to avoid posting the URL... That is why I went through the fol-de-rol
Gee, I didn't realize that you were running a super-double-secret website. Certainly wouldn't want anyone to see it, after all.
MisterNeutron: While I appreciate your snarkyness and assumption from the start that this iOS problem is just me... none of this is helpful in resolving my problem and or most likely bug.
Yes I want traffic to my site on the front end, but not looking to draw attention to the development and debugging of problems. Hopefully you can respect that and be helpful rather than mock me. Otherwise I have no clue why JWPlayer would allow you to troll these forums..
So.... can anybody helpful confirm an iOS playback problem on JWPlayer 6.12 Licensed?
Best of luck in your endeavors.
@ted
Yes, this does appear to be a bug with JW6.12.
Specifically to do with using the Ad Schedule block on mobile.
Symptoms are that when you click the player the first time, it just appears to buffer forever, and then if you click again *sometimes* the video will play, sometimes it won't - it depends on how long you leave between clicks.
I've not yet explored whether it's just Google IMA within a Schedule block which exhibits this problem, or whether VAST tags cause the issue too.
The problem won't appear for you on JW6.11 because you need JW6.12 to support HTML5 Googima Ads. It won't appear on a setup without a key (even JW6.12) because you need an Ads licence.
The workaround is to setup the "advertising" block using the basic (non-scheduled) configuration - which works for you as you are only running a pre-roll currently:
advertising: {
client: "googima",
tag: "http://googleads.g.doubleclick.net/......"
}
Here's a working example:
http://dev.powered-by-haiku.co.uk/jw-html-config/debug/ted/
If you are intending on expanding your Ads schedule in the future, then I'd suggest you create two advertising blocks outside of the player, and conditionally load the mobile one for mobile users, desktop one for desktop...
James Herrieven
@ted: Sorry I was snarky - it was uncalled for. Long day....
@James: Would it help / hurt / make no difference if ted used only an HLS stream? I couldn't help but wonder why he would provide both an RTMP and an HLS, since the HLS should be playable on any platform. It sounds as if the bug in 6.12 would show up in either case, but it's not clear.
@MisterNeutron - Yes indeed, given that Ted has an Ads licence there is (in principle) no need to provide an RTMP version of the stream as the HLS will use Flash on desktop to play.
However, there are reports of HLS via JW's flash player being a bit "hit and miss", and so maybe if the RTMP is readily available, it could be a conscious decision to prefer that over HLS on desktop.
In relation to the bug, this would make no difference.
James
@MisterNeutron: - We're good, thanks!
@James: I will try rewriting the ad block.
In the past we have had mixed results with lots of buffering when using HLS on desktops.. However that would be ideal to just offer and HLS feed.
-Ted
