jPlayer 2.0.0

[Mark P]

jPlayer 2 is up, but the DNS change is taking its sweet time to
propagate.

It should be available in the morning. Lets hope so. It is already on
jQuery plugins and on GitHub, but the docs are not there so you might
as well get a good nights rest too and take a look in the morning.

http://www.happyworm.com/jquery/jplayer/

jPlayer 2.0.0 is a beta release since it is a little green still. I
also noticed a few issues with the iPad on my final testing round, but
made the decision to release rather than spend another day coding
followed by another testing.

We will be making updates in the new year. The API is in place, so if
you want to start using it then go ahead. It works fine on every Win
and OSX browser we tested. The iPhone handles it really well. The iPad
does not appear to like the multi instances much, but I will have to
look into that. The numbers it was telling me appeared to be lies I
tell ya' lies!

So then.. jPlayer 2 has been rewritten from the ground up. The Flash 8
AS2 has been replaced with Flash 10 AS3. This enables support for MP3
and M4A audio media and M4V (H.264) video media. The Flash seems
pretty solid, but we will have to test the performance more for low
bandwidth. Some days you miss your old dial-up access heh.

The JavaScript along with the Flash has been changed to be event
based. The Flash raises events, the browsers HTML raise events, and
jPlayer uses many of them and bubbles all of them up to the jPlayer
element. jPlayer even raises some events of its own, such as the ready
event along with errors and warnings. This allows you to bind handlers
to the events.

The system for prioritizing the HTML and Flash solutions has been
changed so that you can control which is dominant. Along with being
able to define the format priority I believe this enable a high decree
of control over what gets picked 1st. It is still all dependent on the
browser too of course.

I'll leave you there now. I am off to get some rest. More tomorrow.

Best regards,
Mark P.

[audioknocker]

On the demo page: http://www.happyworm.com/jquery/jplayer/latest/demo-01.htm
that there's an error in Firefox 3.6.13. File doesn't play and the
inspector shows an error. Works in Chrome/IE9.

Inspector shows status.formatType = 'oga' for FF and status.formatType
= 'm4a' for Chrome/IE so it seems like its just a error related to
the .ogg file. The .ogg url returns as not found when entered directly
in browser (http://www.happyworm.com/audio/ogg/Miaow-07-Bubble.ogg)

Noticed this on most of the demo pages..not specific to this one. Just
thought I'd point that out.

[Mark P]

Thank you for pointing it out. I will correct any missing files now.

The media moved location as well in the server switch, so i must have
forgotten those files or something.

Will post when corrected.

Best regards,
Mark P.

[Mark P]

I uploaded the missing ogg files. All 10 of them <blush>.

The audio album poster for the media player was also missing, so I
fixed that too.
I did a quick once over in Firefox and it looks like all the media is
working correctly now. I also checked the mpa, mp3, m4v and ogv
folders and they had all the media already.

The jPlayer Inspector is pretty handy hey. It showed the error event
correctly, it's just that the demos do not act on the error event in
any way. The jPlayer Inspector is actually a jQuery plugin for the
jPlayer plugin. I expect to improve the code quality and features as
time goes on, but for now it does everything I need and certainly
helped figure out bugs and such. I designed it so that you could
easily add it to your page somewhere during development.

Best regards,
Mark P

[Dalton]

Congratulations on the big release! I can't wait to dig into this.
Unfortunately I need to launch the site I've been working on for
months next week so I'll be sticking with 1.2 for now, but the next
version of my WP plugin will definitely incorporate 2.0.

Dalton

[Maboa]

Thanks and good to hear you're launching too Dalton. Good luck with it - are you considering a video version too ? :)

To all on the group, as jPlayer 2 is a complete rewrite - we are looking for as much feedback as possible. Like something / don't like something - just us let us know, we'd be very happy to hear from you.

Cheers

Mark B

[Jonathan2]

Hi Mark & Mark,

I know it's disappointing when you launch something and people don't
all flood the groups with "it's amazing" messages, but it is!

I really like the look of this. I've just started having a play this
morning. I think perhaps more "examples for newbies" might be good,
but I worked out the new constructors.

One thing the player I use does it play a variety of internet streams,
not all of which are identified by a filetype suffix.

So, what I *think* I should now be able to do with this version is
throw the file at the player, and if it's not playing after 10
seconds, assume it's a stream or filetype that can't be played.
Then change the file to play a message that it's not possible to
stream this file and provide a url link to click.

I'll let you know how it works out :)

Thanks again.

[Maboa]

Well, this is an early release, we still have to put together a quick start guide and make clear what the benefits are of using the new jPlayer library are. I don't think it is yet obvious to the casual observer.

So it's a bit of a soft launch to try and gather feedback from the community at large before we build the resources around the new library.

Many people in this group may be concerned that now we have video capabilities the audio side of things will be neglected. This is not the case at all, firstly jPlayer has been re-written from the ground up to be more powerful regardless of media type, also adding video capability does not add much to the overall size of the library as the <audio> and <video> API are very similar.

So a lot of changes and still quite a bit to absorb for many. Our job going forward will be to explain and demonstrate all the new cool things and make upgrading as painless as possible for developers.

Looking forward to the new year.

Cheers

Mark B

[kirkland]

Thanks for the release. I'm trying to get the jPlayer package in
Ubuntu updated.

Unfortunately, I'm not able to compile the Flash from source.

Previously on jPlayer 1.2.0, I used:
mtasc Jplayer.as -swf Jplayer.swf -main -header 120:20:40 -v -version
8 -group

Now, when I try to compile similarly:
$ mtasc Jplayer.as -swf Jplayer.swf -main -header 120:20:40 -v -
version 10 -group
Classpath : /usr/bin/std8/;/usr/local/share/mtasc/std8/;/usr/share/
mtasc/std8/;/usr/bin/std/;/usr/local/share/mtasc/std/;/usr/share/mtasc/
std/;/usr/bin/;/usr/local/share/mtasc/;/usr/share/mtasc/;;/
Parsed /usr/share/mtasc/std/StdPresent.as
Parsed /usr/share/mtasc/std/Object.as
Parsed /usr/share/mtasc/std/Boolean.as
Parsed /usr/share/mtasc/std/String.as
Parsed /usr/share/mtasc/std/Number.as
Parsed /usr/share/mtasc/std/Array.as
Parsed /usr/share/mtasc/std/Function.as
Jplayer.as:23: characters 0-7 : parse error Unexpected package

No dice.

Any help would be appreciated. Thanks.

:-Dustin

[Mark Panaghiston]

@kirkland:

MTASC is a Flash 8 compiler for AS2.
http://tech.motion-twin.com/mtasc.html#as3

jPlayer 2 has Flash 10 written in AS3.
The Flash is compiled through the Adobe Flash Pro CS4 compiler. The FLA is an empty file with the Jplayer.as class.

I understand there is a OS AS3 compiler in http://haxe.org/ but I never got round to replacing the Adobe FLA file with the haxe alternative.

I will look into it, but I am not sure when I'll get round to making that change.

Best regards,
Mark P.

[Dustin Kirkland]

Thanks, Mark.

We in the Ubuntu community would very much appreciate that!

Please let me know when and if you have compilation instructions
available for jPlayer using an open source compiler. Whenever you do,
I can update the jPlayer version in Ubuntu from 1.2.0 to 2.0.x.

Thanks!
Dustin

[Mark Panaghiston]

I just took a peek at the instructions at:
http://haxe.org/doc/start/flash/as3migration/part1

They would require quite a few changes.

Parts 2 and 3 of as3migration are not even written yet!

In the past people have asked for the FLA file too... Although I am not sure exactly why.
The code is either 1 or the other... It can never work for both. I will try and take a look at it again after I have addressed the first set of known bugs. I had always planned for the compiler to be open source like with jPlayer 1 and MTASC. It kinda got de-prioritized along the way.

I am confused though...
Why do yo need to compile the AS3?
The compiled SWF if given in the plugin.

They only need to compile it again if they edit the code.

Best regards,
Mark P.

[Mark Panaghiston]

jPlayer 2.0.1 patch released on GitHub

Minor Bug Fixes:
1) The warning alerts are now controlled by warningAlerts instead of incorrectly by the errorAlerts setting.
2) The css selectors are now associated before the Flash is inserted. Previously, any warningAlerts would interfere with the Flash ready event, causing it not to occur.
3) The data structure is now complete before any event is generated. Previously, the gate and active properties were undefined. Affected the NO_SOLUTION error event.

New file:
jquery.jplayer.js

https://github.com/happyworm/jPlayer

[Mark Panaghiston]

jPlayer 2.0.2 patch released on GitHub

Major Bug Fix: The jPlayer ready event now only ever occurs once. Previously, using setMedia in the jPlayer ready event when the Flash solution was being used, would generate an extra ready event.

[Mark Panaghiston]

The demo ZIP file has been updated. The previous one still had in the HTML files the code for Google Analytics and Flattr.

The files now only contain the minimum HTML structure and code for jPlayer.

Best regards,
Mark P.

[cicer...@gmail.com]

problem with google chrome seekpercent solved by editing the line 744 as shown below:

744: sp = (this.status.duration > 0) ? 100 * media.seekable.end(media.seekable.length-1) / this.status.duration : 100;

744: sp = (this.status.duration > 0) ? 100 * media.buffered.end(media.seekable.length-1) / this.status.duration : 100;

[Mark Panaghiston]

jPlayer 2.0.3 patch released on GitHub.

Minor Bug Fix: Corrected the jQuery UI widget.bridge code.

Feature Change: jPlayer's size is no longer read from the CSS.

New Feature: Enabled changing the video size.
The full/restore screen sizes are set through the options: size and sizeFull, both being objects containing: width, height and cssClass. The cssSelectorAncestor determines the element that the cssClass is switched onto. The option fullScreen determines which setting is used. Added default values for the HTML css selectors restoreScreen and fullScreen, along with their methods.

Changed the cssSelectorAncestor default value to jp_container_1.

[Mark Panaghiston]

Rough notes on how to use jPlayer 2.0.3 and the backward compatibility changes.

The CSS no longer controls the size of jPlayer. The values are now given explicitly in the constructor options. This is because jQuery returns width/height values in pixels, rather than the actual CSS definition, such as "100%". The default size values have 2 settings, depending whether audio or video formats are given in the supplied option. The audio default is simply zero size and an empty cssClass for both sizes.

The new constructor options are listed here with their Video defaults:

cssSelectorAncestor: "#jp_container_1",
fullScreen: false,
size: {
    width: "480px",
    height: "270px",
    cssClass: "jp-video-270p"
},
sizeFull: {
    width: "100%",
    height: "90%",
    cssClass: "jp-video-full"
}

Take note of the new cssSelectorAncestor default value. This was changed since its position in the standard HTML structure has changed from being the same as the interface element and has moved to the outer most element. ie., the container.

Since jPlayer now controls its own size, there is a page load display consideration. jPlayer sets its own <div> size and adds a class to the cssSelectorAncestor. It is recommended that you continue to set the initial size and class through CSS/HTML. ie., size.cssClass is the class given in the HTML for the outer div element, which is also referred to by the cssSelectorAncestor. Otherwise, the display will not look correct until jPlayer is instanced at jQuery doc ready.

Two new default css selectors have been added along with their methods.
cssSelector: {
  restoreScreen: ".jp-restore-screen",
  fullScreen: ".jp-full-screen"
}

These methods can be used via code if you want, but the official way to change either the size settings or the full screen setting is via the jPlayer("option") method. Eg.
$().jPlayer("option", fullScreen, true);

Do not confuse the two properties in the options with the same name...
fullScreen
cssSelector.fullScreen


At present, we are still working on the actual CSS for the full screen mode. Also, our interface sprites need to be updated to include the new control icons. We plan to release these with 2.1.0.

Best regards,
Mark P.

[Kirill]

I don't understand why jplayer 2 has to be this complicated.
There's no proper documentation regarding on how to get things going,
you have to rely on demos which are extremely confusing.

You have to copy paste a huge js code which you have to really really
dig deep into, just to understand ANYTHING at all.

Wouldn't it be easier if you could load jplayer with something like
this:

$(document).ready(function()
{
$(something).jplayer({
different options
});
};

Or at least make a proper dev guide.

My 2 cents. If I can get it working, I love it. But it's too
complicated.

On Feb 21, 5:22 pm, Mark Panaghiston <mark.panaghis...@gmail.com>
wrote:

[Mark Panaghiston]

Hello Kirill,

jPlayer is designed to be very flexible, allowing  complete control over how it looks. As a result, you do require a little more to get started.

I wrote a Quick Start Guide that gives a blow by blow account of setting up a simple audio or video player.
http://www.jplayer.org/latest/quick-start-guide/

You will notice that jPlayer already works as you suggested. It takes in some options and goes from there. The main difference is that you need to add the HTML as well. We are considering ways of auto-inserting a standard set of HTML.

Really only steps 6 and 7 of the quick start guide pertain to jPlayer. The other steps are spoon feeding novices so that they do the bleeding obvious, such as include the JavaScript for jQuery and jPlayer, along with the CSS.

The dev guide is more of an API guide. It focusses on giving the details of the methods available in jPlayer.
http://www.jplayer.org/latest/developer-guide/

As for external code being huge. You must be referring to the Playlist demo. They are an example of how you can use jPlayer to perform such a function. The functionality is nothing to do with jPlayer itself. jPlayer is designed to take a single piece of media and play it. I also has some useful commonly used features, such as associating an interface with the functionality. It was deemed that playlists are not part of the core functionality since it would merely bloat the core with specific code that is useless if not used in the specific way. Instead, we are considering a jPlayerPlaylist plugin that is an addon to jPlayer... But that is a way off.

Thank you for the feedback.

Best regards,
Mark P.

[Maboa]

Hi Kirill,

As Mark P says jPlayer can be used to create completely customized solutions as well as allowing to you create a default like player in a few lines of code. There are many applications of jPlayer and combining it with a playlist is just one of them.

jPlayer 2 was a huge jump for us, it was a complete rewrite plus a venture into the heady world of video, we are still refining some aspects of this new version and are actively working on version 2.1 as part of this push we have decided to give the documentation some love and revise some of the demos. 

It's not easy to get the balance between complexity and flexibility right and this is one of the ways that an active community like this one can really help so thanks for your feedback and feel free to contribute at any time.

Cheers

Mark B

[Maboa]

I think feedback is insanely useful and I think this is a general way in which the whole group can help. While we appreciate the complimentary stuff, we really need to know what folk consider it is that we are doing wrong and especially how we could improve.

The more feedback like Kirills that we get, the more we can build up a picture of what needs doing, so don't be afraid of letting us know what's on your mind! Let it all out :)

Cheers

Mark B

[Mark Panaghiston]

jPlayer 2.0.4 released on GitHub:

Code Review: Consolidated code to use the _cssSelectorAncestor() function. Added warning event if ancestor not found.

This was just something I noticed while doing 2.0.3 and figured I'd clean it up first before I moved onto other changes.

[Jonathan2]

On Mar 3, 4:27 pm, Maboa <mark.b...@gmail.com> wrote:

> new version and are actively working on version 2.1 as part of this push we

Now, I know how much devs hate it when asked "when's it gonna be
ready", but let's say I was just about to update my over-complicated
site to go from jplayer 1 to 2, and could put it off for a couple of
weeks, might that be something I might want to do, or are we talking a
month or two. Roughly? And if I move to 2.03 now and clean up my
crappy code, am I to understand that I'd need to redo my css again for
2.1?

[Mark Panaghiston]

Hello Jonathan,

I plan to focus on implementing the patches that change any of the functionality first, before implementing new features. This was why the sizing changed happened first after the initial bug fixes. The remaining changes are far less likely to have an impact on peoples designs though. The main one I can think of right now is that we plan to consolidate a few of the vars such as volume and muted. Currently they are both options and status values, where they should only be options. At them moment, the option defines the initial status and then the option value is maintained. This is wrong.

Silvia is currently working on a couple of skins that use the new system implemented in 2.0.3. They will allow a full screen mode for the video. The audio player will not be affected by this change, unless you use the poster feature which uses the same sizing system as for the video.

As for timescales, we hope to get 2.1.0 out within a month. The patch releases will contain the majority of the next minor release before that time though, so you can always start working with them... It is just that the documentation may not be accurate for the new changes until we publish the 2.1 release.

Best regards,
Mark P.

[Mark Panaghiston]

jPlayer 2.0.5 released on GitHub:
Changes to the volume and muted options and their associated methods.

Details:

Feature Change: The volume and muted options are now maintained on the options object. The duplicate status object properties have been removed. These options can now be changed through the options method. The options object has been added to the jPlayer event object.

New Feature: The mute() and unmute() methods now have an optional parameter. The default is true, and sending a false value performs the opposite effect. Eg., mute(false) is the same as unmute(), which both set muted to false.

Minor Bug Fix: An initial muted value of true now correctly displays the volume bar at zero.


Discussion:

The muted option now has 3 ways to change it. mute(), unmute() and option("muted", value). While this may seem rather extreme for such a mundane option, consider that mute and unmute are used primarily by the interface controls, where click handlers are associated with specific functions (actions). The jPlayer("mute") and jPlayer("unmute") methods are considered as shortcuts to change the option using jPlayer("option", "muted", value). The ability to send a parameter to invert these shortcut actions was added since I noticed people having to use if statements to use the correct command. Now you can use jPlayer("mute") or jPlayer("mute", true) to mute and jPlayer("mute", false) to unmute. However, now you could just use the jPlayer("option", "muted", value) method to set it using a boolean.

Likewise, the volume option may be changed by 2 methods. volume(v) or option("volume", value). Again, the volume() method is considered a shortcut to changing the option via the option() method. Technically the volume() method could be deprecated or removed, but I decided to leave it in as a simple way of changing the volume.

The code got slightly smaller after this change, so it is not as if this flexibility is costing us.

[Kirill]

I'd like to clear up some things.

First of all, I understand perfectly what you mean by "jPlayer is

designed to be very flexible, allowing complete control over how it

looks. As a result, you do require a little more to get started". It's
not always good to please everyone and the options you guys provide
are fantastic. It's just that I'm not that home at JS (I read better
than write), I understand what's going on but when it comes to
writing, I'm just not that good.

With that regard, jPlayer 1 was much better. When I moved to version
2, I got a major headache. Besides the much more difficult code, what
bugged me the most was that you had the playlists somewhere within
your code. This was a major problem, since I wanted the playlist to be
generated by PHP backend on the page and not create a separate
javascript controller in my codeigniter framework. With v1 you could
drop JSON on the page as a variable.

I asked my friend for help and he came up with this solution. I needed
playlists with mp3s so I created a controller which returns a playlist
in JSON.
The outcome was:

var playerArtistId = $("input[name='artistid']").val();
var audioPlaylist;
$.getJSON('http://localhost/site/artists/
playlist_json/'+playerArtistId+'/', function(data) {
audioPlaylist = new Playlist("2", data, {
ready: function() {
audioPlaylist.displayPlaylist();
audioPlaylist.playlistInit(false); // Parameter is a boolean for
autoplay.
},
ended: function() {
audioPlaylist.playlistNext();
},
play: function() {
$(this).jPlayer("pauseOthers");
},
swfPath: "http://localhost/site/player",
supplied: "mp3"
});
});

Now. This all is and was fine and dandy with one exception. With
Jquery 1.5.1 this solution is a no-go, it doesn't work when I add that
getJSON function (the same with ajax function). I did a quick google
query, and vaguely understood that there's a bug with ajax in Jquery
1.5.1. So I reverted back to 1.4.4. I spent two days debugging this,
was ready to abandon jplayer 2 altogether before stumbled on the
jquery 1.5.1 bug.

I really like jPlayer and what it stands for but I do thing some of
the aspects could be easier. Mark, you said that you wrote a quick
start guide that "gives a blow by blow account of setting up a simple
audio or video player". And that's great. But you don't touch upon
playlists. I would say that having a playlist in a player is pretty
basic. But with current code it's not as easy as E=mc2.

I stand by my recommendation. You should have some common options
included in the function jplayer(). If you take a look at the gallery
of sites discussion you would see that most of those have hardcoded
playlists. So I think it's clear that most of the users might find it
too complicated to do stuff the way I want to and take the easy
street.

I'm not saying you should do everything like I say (though it might
sound like that). In any case, I love this project and I will be
keeping my vigilant eye on you guys. Good luck!

On Mar 3, 4:16 pm, Mark Panaghiston <mark.panaghis...@gmail.com>
wrote:

> Hello Kirill,
>
> jPlayer is designed to be very flexible, allowing  complete control over how
> it looks. As a result, you do require a little more to get started.
>
> I wrote a Quick Start Guide that gives a blow by blow account of setting up

> a simple audio or video player.http://www.jplayer.org/latest/quick-start-guide/

>
> You will notice that jPlayer already works as you suggested. It takes in
> some options and goes from there. The main difference is that you need to
> add the HTML as well. We are considering ways of auto-inserting a standard
> set of HTML.
>
> Really only steps 6 and 7 of the quick start guide pertain to jPlayer. The
> other steps are spoon feeding novices so that they do the bleeding obvious,
> such as include the JavaScript for jQuery and jPlayer, along with the CSS.
>
> The dev guide is more of an API guide. It focusses on giving the details of

> the methods available in jPlayer.http://www.jplayer.org/latest/developer-guide/

[Mark Panaghiston]

@Kirill: I can understand your frustration. We choose to keep playlists out of any jPlayer code to avoid a number of complicated problems. The primary one being that if jPlayer did it all, then it would be set in stone and you would have to use the way we provide, or bypass it. Bypassing it would just put you right back to where we are now. So we figgured it would just bloat the code and make it even more complicated.

With the jPlayer 2.0.0 demos, I rewrote the external Playlist code to be an object. The idea was that it would be more flexible and easier for people to use. The problem with that is as you describe. Not everyone understands JavaScript that well.

We have had notions to create a playlist plugin for jplayer. The idea being that then those users that want to use it, can add it easily. It does open a can of worms though. Everyone wants to be able to do something different with their page. Some want a pretty scroll bar, others want the media info to be taken from the page and yet others want ajax requests.

Best regards,
Mark P.

[Mark Panaghiston]

jPlayer 2.0.6 released on GitHub:
New Feature: Added Flash wmode option to constructor options. Reviewed Flash insertion code.

Details:

• New Feature: Added Flash wmode option to constructor options. Default wmode is: window. Valid wmode values: window, transparent, opaque, direct, gpu
• Feature Change: The Flash is now 1px by 1px during initialization, if it is used. The ready event internally minimizes it to zero size. IE6-IE8 are not effected and the size is zero during init.
• Code Review: The Flash insertion code is now influenced by SWFObject 2.2, instead of an older version.

Best regards,
Mark P

[Mark Panaghiston]

jPlayer 2.0.7 released on GitHub:
Minor Bug Fix: The duration is now correct in iOS Safari when the media changes.

Details:
Minor Bug Fix: The duration is now correct in iOS Safari when the media changes. The actual bug is in iOS 4.2.1, where the durationchange event occurs while the media.duration is obsolete.


Next I will be looking into whether IE9 now support Flash ExternalInterface calls so that we can enable the flash again. Hopefully it works now that IE9 is officially released. I will also look into a few other IE9 specific code that was required for the IE9 beta to work. Such as media.load() throwing exceptions if src="".

While doing that, I'll also try and see why jPlayer is not working on IE9 is not working for some people. My Win 7 SP1 machine running the official release of IE9 works fine with all the demos under the current jPlayer 2.0.7 code. It just always uses the HTML5 solution.

Best regards,
Mark P.

[Mark Panaghiston]

jPlayer 2.0.8 released on GitHub:
IE9 Review: Enabled the Flash solution in IE9. Removed IE9 beta specific code and clauses.

Details:
IE9 Review: Enabled the Flash solution in IE9. (Previously the IE9 beta had failed to work with ExternalInterface, so it was disabled completely.) Removed the try/catch around media.load(), which was required for IE9 beta. Removed IE9 specific clause in clearMedia.

Best regards,
Mark P.

[Kirill]

I think I may have been too hasty by saying jPlayer needs to be
simplifying. I've been taking advantage of the flexibility and now I
regret saying the things I did. Keep up the good work, guys!

On Apr 5, 5:22 am, Mark Panaghiston <mark.panaghis...@gmail.com>
wrote:

[BryanOB2]

Hello Mark,

For what it's worth, version 2.0.8 broke my pause-button. I had been
using version 2.0.5 prior to trying the latest.

For specifics, I created a multi-instanced player, with one instance
using a GUI player with a playlist.
I created my own skin design and used the following controls;
Previous, Play, Next, Pause, Stop and Mute, along with the Progress
and Volume bars
I was very pleased with the outcome. Thanks again for creating the
player.

Anyway, upon trying v2.0.8, my pause-button disappeared. Also the
control panels seemed to flicker, as I got a brief view of the pause-
button before it vanished again. The code snippet below is the only
thing I imagine that is of significance to the player instance.
The setMedia option is setup in the playListConfig() function. I can't
show you the website, because it's still under construction.
------------------------------------------------------------------
$("#jquery_jplayer_1").jPlayer({
ready: function() {
displayPlayList();
playListInit(false);
},
cssSelectorAncestor: "#jp_interface_1",
cssSelector: {
play: "jp-play",
pause: "jp-pause",
swfPath: "js",
supplied: "mp3, oga"
}
});
------------------------------------------------------------------------
Notice that I had to specify the jp-play and jp-pause options in order
to the buttons to display correctly (v2.0.5).
Thanks for the reply.

Regards,
Bryan


---------------------------------------------------------------------------------------------------------------------------
On Mar 4, 4:41 am, Mark Panaghiston <mark.panaghis...@gmail.com>
wrote:

[Mark Panaghiston]

That is odd. "jp-play" is not a selector... It is like "div" to select all the div elements.

The default is ".jp-play" - Notice the dot at the start of the string. This selects the elements with class "jp-play".

That string is combined with the cssSelectorAncestor. You set it to "#jp_interface_1" so it matched jPlayer 2.0.0 by the look of it.

Your code looks like it is adapted from the jPlayer 1.2 code... Going by the bits for the playlist.

Not sure what else i can say at this time without a link.

Best regards,
Mark P.

[BryanOB2]

Mark,

Thank you for pointing out that error for me. However, I do have one
question.

Is there something I need to do in order to have the play and pause
work independently?
Currently, it appears to work as a toggle only (play or pause)

Regards,
Bryan

--------------------------------------------------------------------------------------------------------------------------


On Apr 5, 8:04 pm, Mark Panaghiston <mark.panaghis...@gmail.com>
wrote:

[Mark Panaghiston]

Yeah, bypass the jPlayer built in stuff.

Disable the auto association:
cssSelector: {
  play: "",
  pause ""
}

Then create your own...

$("myPlay").click(function() {
  $("#myJp").jPlayer("play");
  return false;
});

$("myPause").click(function() {
  $("#myJp").jPlayer("pause");
  return false;
});

I think the internal stuff also does a $(this).blur(); to remove focus from the button you clicked. Otherwise some browsers show a honking great box round the button.

Best regards,
Mark P.

[BryanOB2]

Hello Mark,

Your last reply cleared up some misconceptions I had about configuring
a GUI player. I totally understand why, prior to your comments, my
version of 2.0.5 player worked. The play and pause options I used were
invalid, because I missed the leading dots for the class selectors. I
surmized that the plug-in just ignored them as if I had supplied
double-quotes ("") instead. That was why the play and pause buttons
worked independently.

The v2.0.5 player works very well now. However, in trying version
2.0.8, I was wondering...

Does the plug-in directly impact the CSS for the playlist?
Mine was a custom playlist, and was not part of the <div.jp-audio>
container. I also used different class and Id names.
It seemed to work well with v2.0.5, but with v2.0.8 the styling got
screwed-up.

I thought that all the plug-in needed to play from a playlist, beside
the code to orchestrate it, was the setMedia option.
Example, $("#jquery_jplayer_1").jPlayer("setMedia",
myPlayList1[playItem1]);

Again, thanks for your replies.

Regards,
Bryan




---------------------------------------------------------------------------------------------------------------

On Apr 6, 8:01 pm, Mark Panaghiston <mark.panaghis...@gmail.com>
wrote:

[Mark Panaghiston]

Hello Bryan,

From jPlayer 2.0.5 to 2.0.8 there should not be any affect on the CSS.

2.0.6: Changed the way the Flash was inserted slightly. Non IE8 and less are not affected at all. Leaving Firefox, Opera, Safari, Chrome and IE9 with a 1px by 1px piece of Flash for about 200ms while the Flash loads and generates its ready event. Then the Flash is hidden as it was since jPlayer 2.0.0.

2.0.7: Corrected duration in iOS when changing media.

2.0.8: Enabled The Flash in IE9. During its beta, IE9 did not work with Flash external interface.

No changes to the CSS. Not sure why you have the problem.

Side note: In our CSS we make everything work through classes. Not a single ID is used. This allows the skin to be easily used once or 100 times on a page. I raise this since you might have used IDs and wondered why only 1 works.

A link would help, but I do not like trawling through CSS problems. I can review the JavaScript code for anything incorrect.

Best regards,
Mark P.

[George Xu]

Hi,Mark:

I think I maybe know why  jPlayer is not working on IE9 for some people. In html5 solution,if the mime-type of response mp3 file is "application/octet-stream", IE9 seem to don't recognize it and cann't create the audio element,but it play well in chrome and firefox(I did not test in Safari). When I specify the response mp3 file's mime-type to "audio/mpeg", it will play well in IE9.I think it's a IE9's bug.

Thanks you for your updates,this problem bother me a lot recently.Because of the bug I mentioned ,I have to set flash to be the first a play solutin as  a temporary Approach. Hope the information I provided will be helpful.

2011/4/5 Mark Panaghiston <mark.pan...@gmail.com>

Best regards,
Mark P.

--
You received this message because you are subscribed to the Google Groups "jPlayer: HTML5 Audio & Video for jQuery" group.
To post to this group, send email to jpl...@googlegroups.com.
To unsubscribe from this group, send email to jplayer+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/jplayer?hl=en.

--
---珍惜---

[BryanOB2]

Hello Mark,

After I posted the question regarding CSS, I realized that I had the
wrong suspect and was too eager to assign liability. It definitely was
not a CSS issue, even though it appeared so, at first. But this time,
I hesitate a little with the prognosis, because I don't understand why
v2.0.8 appears to work on Chrome and Safari, and not on IE8, Firefox
and Opera. The symptoms seem to suggest a jPlayer problem,but I really
don't know.

For some unknown reason, v 2.0.0 and v2.0.8 generates my playlist
twice, in the same <ul>.

jplayer v2.0.5
--------------------
playlist generated once, as it should: Chrome, IE8, Firefox, Opera &
Safari (all updated versions)

jplayer v2.0.0 and v2.0.8
--------------------------
playlist generated twice: IE8, Firefox & Opera
playlist generated once: Chrome, Safari

No errorAlerts or warningEvents were issued during testing.
As for my testing methodology, I stripped-out most of the code to
simplify troubleshooting.
1) For test#1, I elimilated the jPlayer code, which is shown below.
2) For test#2, I added the jPlayer code, which is shown below after
test#1.
As you can see, the code was derived from the demos. I didn't include
the html and css below.

------------------------------Test#1
---------------------------------------

$(document).ready(function(){

var playItem = 0;
var myPlayList = [
{ name:"Tempered Song",
mp3:"http://www.jplayer.org/audio/mp3/Miaow-01-Tempered-song.mp3",
oga:"http://www.jplayer.org/audio/ogg/Miaow-01-Tempered-
song.ogg" },
........ the 8 intermediate songs go here .........

{ name:"Thin Ice",
mp3:"http://www.jplayer.org/audio/mp3/Miaow-10-Thin-ice.mp3",
oga:"http://www.jplayer.org/audio/ogg/Miaow-10-Thin-ice.ogg" }
];

displayPlayList();

function displayPlayList() {

for (i=0; i < myPlayList.length; i++) {
$("div.jp-playlist ul").append("<li id='jp_playlist_item_"+i+"'>"+
myPlayList[i].name +"</li>");
}
};

});
------------------------------------------------------------------------------
Test#1 result - POSITIVE - The playlist generated properly, thereby
eliminating the html, css and jquery.

------------------------------Test#2
---------------------------------------

$(document).ready(function(){

var playItem = 0;
var myPlayList = [
{ name:"Tempered Song",
mp3:"http://www.jplayer.org/audio/mp3/Miaow-01-Tempered-song.mp3",
oga:"http://www.jplayer.org/audio/ogg/Miaow-01-Tempered-
song.ogg" },
........ the 8 intermediate songs go here .........

{ name:"Thin Ice",
mp3:"http://www.jplayer.org/audio/mp3/Miaow-10-Thin-ice.mp3",
oga:"http://www.jplayer.org/audio/ogg/Miaow-10-Thin-ice.ogg" }
];

$("#jquery_jplayer_1").jPlayer({

ready: function() {

displayPlayList();
playListInit(false);
},

cssSelectorAncestor: "",
cssSelector: {
play: "",
pause: ""
}
});


function displayPlayList() {
for (i=0; i < myPlayList.length; i++) {

$("div.jp-playlist ul").append("<li id='jp_playlist_item_"+i+"'>"+
myPlayList[i].name +"</li>");
}
};

function playListInit(autoplay) {
if (autoplay) { playListChange(playItem); }
else { playListConfig(playItem); }
}

function playListConfig(index) {
$("#jp_playlist_item_"+playItem).removeClass("jp-playlist-current");
$("#jp_playlist_item_"+index).addClass("jp-playlist-current");
playItem = index;
$("#jquery_jplayer_1").jPlayer("setMedia", myPlayList[playItem]);
}

function playListChange(index) {
playListConfig(index);
("#jquery_jplayer_1").jPlayer("play");
}

---------------------------------------------------------------------------
Test#2 result - NEGATIVE - The playlist generated twice, thereby
making jplayer the suspect.

-------------------------------------------------------------------------------
This circumstance is very puzzling to me, since I know nothing about
the jplayer internal code.

Sorry, but I don't have an online site for you to examine at this
time.
Hopefully, I have provided enough clues to find the issue.

Regards,
Bryan





---------------------------------------------------------------------------------------------------------------------------------
On Apr 8, 7:46 am, Mark Panaghiston <mark.panaghis...@gmail.com>
wrote:

[Mark Panaghiston]

Hello Bryan,

There was a problem with the Flash fallback generating 2 ready events in the jPlayer 2.0.0 code. This bug was corrected in jPlayer 2.0.2 patch. I reviewed the code for the latest patch, 2.0.8, and the correction is still in it. So there should not be a second ready event.

The original problem was due to the Flash events being handled by a switch statement. However, the ready event was dealt with outside the switch. This meant that the switch was defaulting to "just generate the event". To fix, I added an empty clause for the ready event in the switch.

The code that you are using is a combination of the playlist code we provided for jPlayer 1.x and the jPlayer 2.x plugin.

I will look into and check whether the ready event is being generated twice, as your tests appear to show.

In the meantime, I notice that in the jPlayer 2.x playlist demo code, the first thing I do in the displayPlaylist method is to .empty() the old playlist. The intention at the time was to allow the command to be called multiple times, so as to refresh the playlist if it was changed. What it did though was hide that jPlayer 2.0.0 was generating 2 ready events for the flash fallback.

My dev tester with an alert in the ready event, shows that jPlayer 2.0.8 only generates 1 ready event in Firefox 4, Opera 10.01 and IE9. I'm sure I tested that on Safari and Chrome too before releasing 2.0.6 on both Win 7 and OSX. Basically a full browser and OS test, since we changed the way the flash was inserted.

You miss out the bit of code where jPlayer is instanced, so I am missing the constructor options. From your list of what works and what did not, it sounds like you are only using MP3 files for the supplied setting. ("mp3" is the default.) This would then cause Firefox and Opera to use the Flash fallback, along with IE8. If {supplied:"mp3,oga"} then only IE8 would be using the Flash fallback.

Since we all make mistakes sometimes, please check that you are not leaving in some parts of test 1 when performing test 2. Maybe you have 2 completely different files, which makes that unlikely. I'm just guessing. Check that displayPlayList() is only called from the ready event.

The other thing you can do is put a temp alert into the ready event to check that it only occurs once in your setup:

ready: function() {
   alert("Ready!");
}

The alert should only occur once.

Best regards,
Mark P

[Mark Panaghiston]

Thank you for the feedback ge xu.

One fly in the ointment is that people are reporting problems on our demo pages, and they do have the correct MIME type for the media.

The MIME type should be correct for the media to play, so maybe IE9 is not being awkward. Other browsers insist on the correct media mime type.
The OGG files would not work in Firefox or Opera if their MIME type was not audio/ogg or video/ogg. With tests, only the subtype mattered and application/ogg and fruit/ogg worked just as well.

Using mime of application/octet-stream is usually a fudge to get the media to prompt a download box rather than to play it directly in the browser using a plugin, such as QuickTime.

Best regards,
Mark P.

[BryanOB2]

Hello Mark,

With regard to the comment...

"You miss out the bit of code where jPlayer is instanced, so I am
missing the
constructor options. "

Sorry about that -- I was trying out various things and forgot to put
those options back in the player instance.
--------------------------------------------------------------
$("#jquery_jplayer_1").jPlayer({

ready: function() {
alert("Ready!");

displayPlayList();
playListInit(false);
},
cssSelectorAncestor: "#jp_interface_1",
cssSelector: {

swfPath: "js",
supplied: "mp3, oga",

play: "jp-play",
pause: "jp-pause",

errorAlerts: "true",
warningAlerts: "true"
}
});
------------------------------------------------------------
I added the swfPath and the supplied options, and tested it again.
But, I still got two ready events as before. Something is causing the
firing of two ready events, when I use IE8, Firefox & Opera.
No warnings or errors were generated. I agree on the point about
mistakes, so I double-checked everything again.

jplayer v2.0.8

--------------------------
playlist generated twice: IE8, Firefox & Opera
playlist generated once: Chrome, Safari

I can't test IE9 because Microsoft wants to force me to upgrade from
XP to Windows 7.
I will borrow my wife's laptop (Vista) and test it there too.

Regards,
Bryan





--------------------------------------------------------------------------------------------------------------

On Apr 12, 6:12 am, Mark Panaghiston <mark.panaghis...@gmail.com>
wrote:

[Mark Panaghiston]

Hello Bryan,

Some of your options are specified completely wrong. This here is mostly nonsense:

cssSelector: {
swfPath: "js",
supplied: "mp3, oga",

play: "jp-play",
pause: "jp-pause",

errorAlerts: "true",
warningAlerts: "true"
}

To start with I'll correct the way it should be written:
cssSelector: {

play: "jp-play",

pause: "jp-pause"

},
swfPath: "js",
supplied: "mp3, oga",

errorAlerts: true,
warningAlerts: true

Now I will explain errors.

1) Using "true" as a boolean only works because any non-empty string is considered as a boolean true. For example, "false" is a boolean true.
2) The swfPath is the default value, which was the only reason why it worked at all before, since the option you gave was not actually setting this value.
3) The supplied option would have been defaulting to "mp3", since it was set incorrectly.
4) errorAlerts and warningAlerts were also set incorrectly. Apart from the "true" nonsense. They would default to false.
5) The cssSelectors for play and pause are nonsense. For example, there are no elements called <jp-play>

The cssSelectors should be of the form "#someId" or ".someClass". The defaults are ".jp-play" and ".jp-pause".

I still do not understand why the ready event is being called twice. Fix those problems and then we may be able to determine the reason.

I would really appreciate it if you could put this online somewhere for me to review.

Best regards,
Mark P.

[Mark Panaghiston]

jPlayer 2.0.9 released on GitHub:
New Feature: Enabled noConflict option for use with jQuery.noConflict(true)

Details:

A new SWF file Jplayer.swf is published with this patch. The new SWF and JavaScript are required.

After uploading this patch, you may have to restart your browser to get the new version. Some browsers may even require a clear cache depending on your browser's settings. The reason is because most browsers cache the Flash SWF while the browser is active and only re-check the file when the browser is restarted.

The jPlayer constructor option noConflict defaults to "jQuery". This option can be changed to whatever you require after using the jQuery.noConflict(true) command.

Simple brief example with the code that counts:

var lib = {};
lib.jQuery = jQuery.noConflict(true);

lib.jQuery(document).ready(function($){
  $("#jquery_jplayer_1").jPlayer({
    noConflict: "lib.jQuery"
  });
});

Best regards,
Mark P.

[Mark Panaghiston]

Gah! I forgot to update the Jplayer.swf version number variable.

At the moment an error event would be generated with the type:
$.jPlayer.error.VERSION

...Because the Flash still has the 2.0.0 value instead of the correct 2.0.9 value. The JavaScript is correct, which is why the error is reported.

I will release a correct version soon.

Best regards,
Mark P.

[Mark Panaghiston]

jPlayer 2.0.9 on GitHub is now updated to use the correct SWF version number.

Best regards,
Mark P.

[BryanOB2]

Hello Mark,

In our last communique, I made a serious blunder when I copied and
pasted the code into the "Reply" pane. Embarrassed as I was, just
trying to help, I realized that the code I posted last came from an
earlier version of script, and not the one I tested. I guess it was a
matter of not being able to see the forest because of the trees.

In any event, after taking a break from staring at code, I again
double-checked everything, cleared all browser caches, and then re-ran
the tests using jplayer v2.0.8.

This time around, however, the results were more informative, as I
learned something new.

1) Testing the code snippet shown below...

-------------------------------------------

$("#jquery_jplayer_1").jPlayer({
ready: function() {
alert("Ready!");
displayPlayList();
playListInit(false);
},
cssSelectorAncestor: "#jp_interface_1",
cssSelector: {

play: "",
pause: ""
}
});
---------------------------------------------

jplayer v2.0.8
--------------------------
playlist generated twice: IE8, Firefox & Opera
playlist generated once: Chrome, Safari

=================================================

2) Testing the code snippet shown below...

-------------------------------------------

$("#jquery_jplayer_1").jPlayer({
ready: function() {
alert("Ready!");
displayPlayList();
playListInit(false);
},
cssSelectorAncestor: "#jp_interface_1",
cssSelector: {

play: "",
pause: ""

},
swfPath: "js",
supplied: "mp3, oga",

});
------------------------------------------------

jplayer v2.0.8
--------------------------
playlist generated twice: IE8

playlist generated once: Chrome, Firefox, Opera Safari

======================================================
Lesson learned: I must include the supplied option oga, which then
allowed Firefox and Opera to use its native support for oga, and not
flash fallback for mp3.

So, it would seem that the issue was with the flash fallback solution,
because only IE8 still generated two ready events.

I always assumed that the browser would use the files in my local
website folder <js>.
However, at this point in time, I am uncertain as to whether or not
the browser cache was corrupting my test results.

So, until someone refutes the latter, I will clear the browsers caches
before switching to different versions of the jplayer since they all
use the same filenames.

Whatever the case, the alleged issue with v2.0.8 might very well be
put to rest now. I just tested version 2.0.9 and the playlist was
generated only once in all browsers.

Thanks again for your help.

Regards,
Bryan
--------------------------------------------------------------------------------------------------------------

On Apr 13, 3:15 am, Mark Panaghiston <mark.panaghis...@gmail.com>
wrote:

[Mark Panaghiston]

Hello Bryan,

The browser cache can sometimes be an issue. Especially during development when you are changing things often.

I believe the MIME type can affect the browser cache. text/javascript is more likely to cache over application/javascipt, but I have not really played about with that recently.

Usually I just restart the browser if I change the Flash. On my localhost, the JavaScript always seems to update with a reload. Its MIME type is application/javascipt for .js files.

I develop using Firefox and have the Firebug addon that allows you disable all browser chacing through its NET tab. You select the net tab and then click on the little triangle next to 'net'  to change that option from a list.

The other thing that might have happened, but you'd probably have admitted to it... Would have been that you were including the jquery.jplayer.min.js file instead of the patch release with the different filename of jquery.jplayer.js.

The double ready event with the Flash solution was fixed in 2.0.2. I have not touched that part of the code since then, so you must have been using an old version somehow.
https://groups.google.com/d/msg/jplayer/rdWPvU4GpB8/ZIEIRwSmoO4J

Glad you have it working now.

Best regards,
Mark P.

[Darius Kazemi]

Hi Mark,

How's development going on 2.1? It looks like things were rolling along until the 2.0.9 release a month ago. Mostly I'm wondering since I'm converting a client's site over to jPlayer and they require fullscreen. If 2.1 isn't coming out in the next week or two, that's fine, but it'd be good to know so I can implement my own CSS from the 2.0.9 build!

Thanks,

Darius

[Mark Panaghiston]

I was working on some contracts and was in Italy for a week... I am psyching myself up for a final push. I think I am going to have to drop all support group suport during that time. I find that it drains my time and blurs my focus on the update goals. I end up wondering about something else instead of focussing on the current task in hand.

The plan though, is to get a new release out by the end of May.

There is a lot to do and the CSS that you mention is not the least of them. Then there is all the documentation that needs revising... Sometimes the actual JavaScript code seems the easy bit LOL.

The jPlayer 2.1 release will use the same system as 2.0.9, implemented in 2.0.3, for the sizing and CSS. I suggest that you start trying your own CSS, as I cannot guarantee that everything will be ready for the end of May.

[Darius Kazemi]

Thanks for the reply. Best of luck with 2.1!

[Jonathan2]

On Monday, May 23, 2011 7:54:01 PM UTC+1, Mark Panaghiston wrote:

 

I think I am going to have to drop all support group suport during that time. 

 I'll try and intercept and answer as much as I can (at least, all the easy stuff!). Good luck and thanks for keeping us all up to date.

[Maboa]

Thanks Jonathan - I'll also find some time to help. Between us we should be able to cover most issues, just leaving the juicy ones for Mark P for when he comes out the other side :)

[Mark Panaghiston]

jPlayer 2.0.10 released on GitHub:
http://github.com/happyworm/jPlayer

Added the emulateHtml option and bridge

Details:

Setting the emulateHtml option to true causes the HTML5 properties and methods to be emulated on the jPlayer DOM element. This enables jPlayer to work with other libraries such as Popcorn using this bridge. However, it is still recommended that you bypass this completely when an actual HTML media element is present.

For example (an audio player), in the ready event handler you could use:
if(event.jPlayer.html.used && event.jPlayer.html.audio.available) {
  p = Popcorn('#' + $(this).data("jPlayer").internal.audio.id);
} else {
  $(this).jPlayer("option","emulateHtml",true);
  p = Popcorn('#' + $(this).attr("id"));
}

A tester was setup based on a RadioLab project that used jPlayer and Popcorn. The test page uses the Flash with HTML fallback and Mp3 and OGA formmats supplied.
http://happyworm.com/jPlayerLab/emulateHtml/v35-jPlayer.2.0.10-dev/

Or in other words, that radiolab demo link does not use the code recommended above, since it was for testing the bridge itself, rather than bypassing it when appropriate.

Note that the link will only work in modern browsers. Popcorn does not have any support for older browsers... Their requirement of only needing a media element masks a whole bunch of other conditions that "just so happen" to be around on browsers that do support media elements.

IE9 does not work with the bridge. The bypass code above would solve that problem though. Reason is due to Popcorn polling the readyState property and IE9 screws that up by all element inheriting the document.readyState property except for media element. So the value cannot be added to the emulated DOM, since it already exists and IE9 will not let you change it.

[Mark Panaghiston]

jPlayer 2.0.11 on GitHub:

Bug Fix: Destroy() now works with empty selectors

Details:
Previously, if you used empty css selector strings for the controls to disable them, the destroy method would throw errors when is tried to remove all the associations. Now it checks there is one first before trying to remove it.

[Mark Panaghiston]

jPlayer 2.0.12 patch released on GitHub:

Bug Fix:  Play and pause commands with non-zero time param no longer polls a broken media URL when the HTML solution is used.

Details:

Minor Bug Fix: Using jPlayer("play",time) or jPlayer("pause",time) on broken media URLs when using the HTML solution caused the broken URL to be polled.
The internal HTML error event handler now cancels any delayed commands.

[Mark Panaghiston]

jPlayer 2.0.13 patch released on GitHub:

New Feature: Added flv and fla support to the supplied formats.

Details:

New Feature: Added flv and fla support to the supplied formats. This makes using these formats more flexible and robust, rather than fooling jPlayer into playing the Flash FLV format through the m4v and m4a formats and setting {solution:"flash"}.

[Kirill]

Hey Mark, just wanted to drop by and say that you're doing excellent work. Also, I was wondering why aren't the latest versions of jPlayer available from the front page and only through Github?

[Mark Panaghiston]

I am not sure how to answer this question without pointing the finger at someone and saying "Ask them why!"

I have always wanted to follow the small and often approach and evolve jPlayer along the way... But for some reason, jPlayer 2.1 was deemed as some all singing all dancing version. Oh that, along with changes to the support website, which some we have already done.

Then we have support on the group... I often spend between 2 and 4 hours per day doing support. This eats into the development time.

Finally, our designer is leaving us. This means that now I have to do all the CSS for the skins too. The current 2 skins that are planned for 2.1 release are still quite a mess.

Patch releases tend not to be tested as rigorously as the Minor releases.

We have had talks about all this though and as I've said before, we are working on a new minor version. My next focus is the CSS for the 2 skins. I see that as the main item holding us back at the moment. Once these are ready, I will be able to do the last few tweaks... write the docs and then publish the new version.

[Kirill]

roger that!

[Maboa]

My ears are burning - so I'll chip in. :)

Like Mark P says jP 2.1 will be a significant release. jP 2.0 was a big change from jP 1.x taking in video and actually ended up being a complete re-write. Mark P did an amazing job on this but as it was such a big change there were a few issues we needed to solve to get to where we wanted to be, fullscreen video being one but not the only issue.

At the same time I felt it was time to update the site and mistakenly thought we could do both things at once, but it became apparent that there was a lot more to do to get to jP2.1 and the new jP site as we wanted it (which would include more than just the default skin, improved docs, demos and examples and the new look and feel that we have already pretty much implemented). We were in danger of losing site of our release early and often mentality so we decided to push things out as they became ready and do the minimum to ship what we have. Which we are all much happier about.

Mark P as _the_ developer (just now) has his work cut out here, I in many ways have the best end of the stick coordinating the project, creating demos, blogging and liasing with clients etc. Creating libraries isn't easy.

The good news is that once this version is out we hope to have a much better lib and documentation, examples and skins to support it. The downloads of jPlayer and visits to the site and of course the increasing size of community all continue to rise at a steady rate and we are getting very positive feedback, which keeps us going.

I hope after this release that we can put together a small team to work on the next version and at the same time we are looking at getting some funding/sponsorship (these two items are what I'm looking at just now).

Addressing your question more specifically, the releases on github are really just snapshots of work in progress, nightly builds almost :) and that is why we don't link to them from the front page of jPlayer.org.

So that's where we are at, and all credit to Mark P for pretty much singlehandedly dealing with the technical aspects.

Cheers

Mark B

[houdini4877]

Are there any known issues with the Jplayer.swf v 2.0.9?  I ask because when using v 2.0.9, nothing works... my playlist isn't generated but no errors are thrown at all.  When I revert back to Jplayer.swf 2.0.0, I get a warning that I should upgrade the swf but then everything works as expected.

I'm hoping to implement fullscreen functionality and that's why we're trying to upgrade.

[houdini4877]

Note: We're using jPlayer 2.1.3.

[Mark Panaghiston]

jPlayer 2.0.14 patch released on GitHub:

New Feature: Added $.jPlayer.platform object for detecting mobile and tablet devices.

Details:

New Feature: Added a device sniffer that is useful for detecting smart mobile phones and tablet devices.

$.jPlayer.platform.mobile = Boolean: True when a smart phone is detected
$.jPlayer.platform.tablet = Boolean: True when a tablet device is detected

Platforms detected, property is Boolean true if detected:
$.jPlayer.platform.ipad (tablet)
$.jPlayer.platform.iphone
$.jPlayer.platform.ipod
$.jPlayer.platform.android (Either mobile or tablet)
$.jPlayer.platform.blackberry
$.jPlayer.platform.playbook (tablet)

$.jPlayer.platform.webos *
$.jPlayer.platform["windows ce"] *

* Untested.

Actually... Looking at that code there, the "windows ce" property does not look like valid JavaScript... That will need to be reviewed before being able to detect the windows phone.

This platform sniffer will be developed and improved with navigator.userAgent feedback from the community.

[gasch]

This might be a really silly question - but is it possible to integrate the full Blue Monday Skin into Wordpress. I have got the JPlayer plugin by Simon Ward but I can't get it too look like the full theme as seen here http://www.jplayer.org/latest/demo-01/

Cheers,
Gareth

[Mark Panaghiston]

jPlayer 2.0.15 patch released on GitHub

Code Review: Verified JavaScript using JSHint. Minor code syntax changes. Added JSHint options to source.
http://www.jshint.com/

Note that: All future releases/patches will be verified using JSHint before uploading to GitHub.

[Zillion]

Hi Mark,

 

i updated to 2.0.15, grabbed the latest swf along with it, just to be sure. Now the play/pause button ist working anymore.

can you take a look or post a demo somewhere that actually uses the latest code?

 

mine is at: http://internetreklame.nl/radiowielerland/

 

[Mark Panaghiston]

You can read the notes further up in this thread relating to 2.0.3 patch.

In your case, you can add the option:
cssSelectorAncestor:"jp_interface_1"

This change was made since the ancestor has really moved to the outer div container now. I did not want to rename it, but felt it would end up being a more sensible name... ie., jp_container_1

[Zillion]

hi Mark,

 

i did like you said, but still seems the buttons are not responding. i'm totally lost :(

[Mark Panaghiston]

Well, that is because you trusted me not to make an error. My bad.

If you had read the 2.0.3 notes it would have been clear that I missed out the # in the selector.

cssSelectorAncestor:"#jp_interface_1"

[Zillion]

will you marry me?

[Mark Panaghiston]

jPlayer 2.0.16 patch released on GitHub.

Details: The restoreScreen and fullScreen control selectors now show their correct state.

The restoreScreen and fullScreen control selectors were not maintaining their state on the interface. They were never being show/hide at all. Bug due to jPlayer 2.0.3 changes not being tested with a suitable interface at the time.

The state is now correct setting from options during instancing and when the buttons are clicked on.

[Mark Panaghiston]

As you may have guessed from yesterday's patch, I've been looking at the new CSS for the skin's full screen mode. I had been making good progress until Firefox through a 10 year old spanner in the works.

You should be aware of the display:none issue with the jPlayer div, where the Flash is disabled by the browser. Showing it will reload the flash SWF in and then hiding it and showing it again causes it to load again. Each time it is reset and looses any data already sent to it from the JavaScript. If memory serves me right, this effected all browsers when the flash was used.

Well I just found a new one... position:fixed has a similar problem. If you change the CSS for the HTML entity to position:fixed from a different position style then the Flash is reloaded in Firefox. Yes, in Firefox 5.

Check out this epic bug report that is 10 years of failing to fix this problem.
https://bugzilla.mozilla.org/show_bug.cgi?id=90268

It does sound like they intend to fix this problem soon and the display:none issue. But that is not much help as a solution should not be limited to Firefox 7+ (Or whenever they actually release the fix).

I did a brief check on Chrome and it does not have a problem with changing the position to position:fixed and back again (to undefined... so defaults to static I think.) I did notice that Chrome had an issue with the Flattr widget. It is actually an iframe and I bet that the allow transparency option on the iframe is what cases a small black box to appear over the flash in chrome.

I'll probably check to see how some other browsers behave, but it is all rather moot if Firefox takes a dump on the whole idea.

[Mark Panaghiston]

I'm waving my arms around wildly while writing this...

[This only affects video players using the Flash fallback as audio players can easily tuck the jPlayer div away somewhere safe.]

Lets take a look at the existing problem, with display:none effectively removing the Flash from the page.

I have already been thinking of a solution for this, but I never came up with anything that was nice and robust. It relied on using the bogus ready events generated by the flash when it appeared on the page again. This would then get the media SRC from the status and give it to the Flash again. I then figured that a flashReset event would be raised so that devs could know that the flash is available again.

This actually would work ok... But the real problem comes in if you consider that there is a huge delay in software code execution terms between you doing something like $().show() and then being able to execute a play on the Flash fallback. The HTML solution does not care much, but it is a bit more finicky on mobile browsers if it is hidden... But I will only be looking at the Flash problems here.

So for example... You have the player hidden and then show it. You want it to try and autoplay, so you give the play command. However, the Flash is still faffing about being inserted into the page and it does not even register its functions for the first 100ms and generate its ready event. So the play command it lost. In this case, you'd need a event handler for the mythical flashReset event that issues the play command, as internally the SRC would have been setup again and all you would need to do was play it. The HTML would be ok and it did not care about being hidden and either way, you showed it first before issuing any commands to it.

So that was the solution I was thinking of for the display:none issue for the Flash... It did not seem very pretty to me, but that was what I was considering adding when I got round to it.

Then the position:fixed issue on Firefox came along...

It is similar to the display:none bug but there are a few factors we can know about... The first is that is is unlikely that the user can give any commands during the operation as it will happen fast and be automatic when the full/restore screen button is clicked. Then there is the state of the player when the operation executed, it could be playing or be paused at a certain time.

So if the original thoughts were modified, the internal workings before the flashReset event is raised would be:

WHEN ( Flash ready event received ) {
  IF ( Already received a ready event {
    IF ( Media is set already ) {
      SET the media from the status
      IF ( status current time is greater than zero ) {
        IF ( status isPlaying ) {
          PLAY at current time
        } ELSE {
          PAUSE at current time
        }
      }
    }
  RAISE EVENT flashReset
  }
}

The handy thing is here, if Firefox fix the bug, then this will stop happening automatically too as the Flash will not be being reset by the browser in the first place.

The behaviour would also happen for the display:none though... But that may not be a bad thing. If you have a close button to hide the player, you should stop it first then hide it. That would give a set behaviour for when it displayed again, resetting to the media but not playing it. But if you hide it while it was playing (without stopping), then the following show would cause the media to continue from the last point.

The other fluff...

Since we now have a new kind of error that is likely to occur sometimes I'll add one for the Flash error. If the ready even has been received in the past, the error type and message will be different. Basically saying that the Flash is hidden rather than it is not configured correctly via the swfPath. This would occur if you tried to change the media with setMedia while the Flash was hidden.

I cannot spend ages on this point making it work in a multitude of cases. Basically you will need to know whether jPlayer is visible or not and never issue commands to it while hidden. And then add any special conditions for the flash to the flashReset event handler.

And finally avoid the grey area when showing the jPlayer div. As in, do not give jPlayer any commands immediately after showing it through code.

Something for me to worry about...

Issuing commands while the Flash is hidden will not have the desired affect. The code will partially execute. For example, a setMedia would fail when trying to talk to the flash and never set the media SRC in the status. Doing a play or pause would also not change the isPlaying status as that is changed through events fed back from the Flash. Doubt there is much we can do about this other than make it clear in the docs.

[Mark Panaghiston]

More open discussion on the development...

The video full/restore screen system.

The CSS and JavaScript required for the Full Screen mode of the Video jPlayer skin is starting to take shape. The JavaScript is all external for now and the jPlayer 2.0.16 code has not even been touched yet to add these features and those in the position:fix issue described in the previous post. (Disclaimers before you think it is all ready.)

So we have the video area and it is popular and commonplace for the controls to be over the video area and show and hide depending on if you move the mouse over it in the last few seconds. The Full Screen solution appears to require this to happen, or you get all sorts of sizing issue when you change the browser window shape towards the extremes.

To do this in jPlayer, so that you do not need tons of external code in the page to deal with it, I expect to add 2 new options to configure the auto-hide feature for each state. Full or restored screen. (Restored is when it is in the page.) So then you can have the restored screen with the controls below it always and the full screen state will auto-hide the controls. Or neither if you come up with CSS that works.

Expected option names and defaults:
autohide: {
  restored: false,
  full: true
}

Based on what i have found so far, the following defaults will be changing:

wmode: "opaque" (Previously "window")

sizeFull: {
  height: "100%" (Previously "90%")
}

To enable the show/hide code we will need another selector:

cssSelector: {
  interface: ".jp-interface"
}

Then we need to detect mouse move. The HTML solution can do this easily using jQuery through the jPlayer div itself and we need to mirror the effect to the interface itself as sometimes it is above the jPlayer div. The Flash will need some changes to generate an equivalent mouse move event. The idea is to bubble the mouse move event from either the HTML or Flash solution up to the $.jPlayer.event.mousemove event.

The is also the possible $.jPlayer.event.resize event that I might add. This would let you know when the size had been changed and then you could read the event object properties to see which state it was in. For some reason I think it might be useful...

The CSS for full screen does not appear to work in IE6. The position:fixed does not appear to behave in the correct manner and it remains inside its parent's confines. IE7+ works fine though. As only the full screen mode is affected in IE6, I do not plan to loose any sleep over this and IE6 will just not support this feature.

And then we come to playlists... I have not even looked at that yet... I will need to investigate that too before i dive in and make all these changes, otherwise I'll find myself having to change my changes, so I want a decent picture first.

Waffling on... On a tangent...

I had been thinking about playlists in other ways though...It is very common for people to ask for the title to be displayed somewhere. I think this is needed similar to the single player, where you will have the playlist, but the currently playing is always shown at the top. Then when the playlist version goes full screen, we hide the playlist area and bobs your uncle. (That means it's done.)

While doing all this, something else has become apparent. Part of the reason for moving and renaming the cssSelectorAncestor default to "#jp_container_1" was that it is now the container for everything in the video player... Even the jPlayer div. So really they could all be classes now... But I think I'll leave the jPlayer div alone and keep that with an ID recommended in the HTML. It is the playlist ID that is now open to debate. That should always relate to the container ID.

I have moved the playlist code to an external file now. While it was more blatant in the demos html code, it did make it rather annoying to maintain. Even though it was only used on a few demos.... Anyway, I was going to add some functionality to it that is commonly requested. New Playlist, Add track, delete track, delete playlist. I am even considering doing some simple get XML and JSON ajax request type methods. Big plans, but not enough time!

[flybynight]

Hi Mark

 

I've been following the issues you've been having with full screen mode, browser CSS support and flash and just wondered whether there could be an argument to use a different approach based on whether the player is using HTML5 or flash.

 

I'm by no means an expert on flash or players, but certainly have had no problems using YouTube or other players in full screen mode in any browser. I'm assuming that these players will all be based on flash given the lack of HTML5 support in even recent versions of some browsers, so assume flash much already provide a solution for using it in full screen mode.

 

You seem to have a solution in the main for the HTML5 solution when supported so would it not be possible to simply use the flash solution for flash and the HTML5 solution otherwise.

 

I do appreciate that having a single solution for both would be preferrable but if there are a number of issues affecting a CSS solution due to browser support, maybe the overhead of 2 different approaches may not be so bad when compared to code with lots of conditions to address the various issues resulting from ideosynchratic browsers.

 

Apologies if you've already considered this or if my assumption that flash has a solution is just wrong. But didn't think it would hurt to suggest it anyway.

 

Cheers

Ian

---

From: jpl...@googlegroups.com [mailto:jpl...@googlegroups.com] On Behalf Of Mark Panaghiston
Sent: 05 July 2011 22:48
To: jpl...@googlegroups.com
Subject: [jPlayer] Re: jPlayer 2.0.0

--
You received this message because you are subscribed to the Google Groups "jPlayer: HTML5 Audio & Video for jQuery" group.

To view this discussion on the web visit https://groups.google.com/d/msg/jplayer/-/2gsgSypuCYcJ.

[Mark Panaghiston]

Thank you for the feedback Presto.

I understand what you mean about the Flash. We have considered simply using the full screen function inside flash, but we have a problem if we do that. The system is no longer styled through HTML and CSS. The Flash would either have to have artwork in it, or have nothing and just use a double click to full/restore screen in it.

The solution I am proposing will give a seamless experience for users of the HTML5 and the Flash. OK, there is this bug on Firefox, where the flash will reset when changing mode, but I think that is acceptable and it will automatically disappear if they fix the bug.

From my point of view, the Flash is a polyfill. All it should do is play the actual media. All control interfaces should be external of it, configured using the HTML/CSS standards.

Either way, there will be special cases in the code. If the Flash had a different system to the HTML that would complicate matters too. So it's complicated either way. I still prefer the way I propose it rather than having the Flash do its own thing.

Best regards,
Mark P.

ps. Now I gave the support group a once over, I can get on and actually begin making these changes. I expect that the change will happen over 2 or 3 patch releases. Dealing with the flash reset first and then looking at the new Flash and code for the interface auto-hide.

[Mark Panaghiston]

jPlayer 2.0.17 patch released on GitHub.

Details: Addressed display:none issue with Flash. jPlayer reacts to additional Flash ready events by setting up the Flash to the current status. New event flashreset. New error FLASH_DISABLED.

Release notes:

New Feature: When the Flash solution is display:none and then shown again, jPlayer will now setup the Flash from the current status state. This is primarily for solving a problem with the Full Screen system on Firefox, where position:fixed causes the Flash to reset. This issue does not affect IE6+ at all. Chrome, Safari and Opera are affected by the display:none issue. Firefox affected by both.

New Feature: To aid with the display:none issue, new events and error codes have been added. When the Flash generates any additional ready events. the $.jPlayer.event.flashreset event occurs after attempting to setup the Flash with the current status. The error type $.jPlayer.error.FLASH_DISABLED occurs if any command is given to jPlayer while the Flash is hidden or disabled by the browser.

[Mark Panaghiston]

jPlayer 2.0.18 patch released on GitHub.

Details: Changed the way the volume controls work. Added volumeMax selector and method. Clicks on volume bar now unmute. Removed obsolete Chrome volume bug fix.

Release notes:

Feature Change: Changed the way the volume controls work. Clicks on the volume bar now unmute if the volume was muted along with changing the volume. Added a new interface cssSelector volumeMax (".jp-volume-max") and its method, which unmutes and sets the volume to max. The volumechange event is now generated from the HTML media element's event or emulated through JavaScript for the Flash. The volume fix for Chrome 4 was retested and found to be unneccessary. It has been removed to enable the volumechange event to be used on the HTML element.


Patch dedicated to Maboa who demands symmetry in his volume controls. Now we have a button on the left that mutes/unmutes and a button on the right that maxes volume and unmutes. As a bit of artistic license I add that clicks on the volume bar will always unmute, if necessary, and change to the new volume.

[Mark Panaghiston]

After doing some tests, I found that the jQuery mousemove() works over the Flash when it is in wmode="opaque".

Unless anyone can think of a good reason why not, I'll not be adding the mousemove detection to the Flash itself. This would affect you if you needed the Flash in wmode="window" and the autohide features to work. Since stuff cannot be displayed over a window wmode piece of Flash, it should not be an issue.

But speak up if you see differently.

[Mark Panaghiston]

Thinking about the autohide options... I just know that as soon as this is implemented people will want to change the speeds and delays.

Looking at the existing options we have size {} and sizeFull {}, which are objects that contain properties for the restored and full screen modes.

I originally picked those names, size and sizeFull, since I thought they were more obvious as to what they do. However, since I am now starting to normalize the naming using restored and full, we might want to review their names and pick something more suitable.

I raise this since the setting of size {autohide:true} seems a little odd if we were to merge the options for the restored/full screen modes into a common place.

Each mode will want options for:

mode: {
  width: String
  height: String
  cssClass: String
  autohide: Boolean
  show: Number
  hide: Number
  hold: Number
}

The ones in bold are new, and the others were added in jPlayer 2.0.3.

Possible new names for the main option are restoredMode and fullMode... But I am still not happy with those names.

The show/hide/hold numbers are times in milliseconds. In theory the slow and hide times could be the jQuery animation strings like "slow", but the hold value will need to be a number, so I will normalize them in the docs to all use numbers.

[Mark Panaghiston]

After going round in circles for a bit, I think I'll do the following...

Leave the size and sizeFull options alone.

Then tone down the flexibility a bit by having both modes share the timings.

autohide: {
  restored: false,
  full: true

[Mark Panaghiston]

jPlayer 2.0.19 patch released on GitHub.

Summary: Implemented autohide for the control interface.

Release notes:

New Feature: Implemented autohide for the control interface.
Added option autohide, an object with properties: restored, full, fadeIn, fadeOut and hold.
Added cssSelector interface (".jp-interface").
Changed default of wmode to "opaque". Changed default of sizeFull:{height:"100%}
Added $.jPlayer.event.resize event for when screen state changes or when size options change.

[Jonathan2]

This is what I love about jplayer - constant development. Excellent! 

Thanks Mark.

[Mike C]

Hi
When I visit your home page using IE8 on a Vista machine the audio won't play. The IE script debugger points to line 120 of FlattrLoader:
this.domReady(function() {
that.setup();
});
with the error: Object doesn't support this property or method.

I also get the same error on my local installation of jPlayer although it works fine in Chrome, Firefox and Safari.

Regards
Mike

[Mark Panaghiston]

I reported this to Flattr a week or so ago.

The original nice posting I had made got eaten by their stupid forum system... Well, I was the one that screwed up I guess... So I posted a shorter report. I will update that post with more details as at the time I was surprised it was happening at all and figured that they could not have made such a huge boo-boo.

[Mark Panaghiston]

Oh... And why IE8 does not work... Update your Flash plugin.
http://www.adobe.com/software/flash/about/

[Mark Panaghiston]

Today's waffle will be able a repeat control on the interface...

Since a repeat type function is commonplace on media players, we have been considering how to get this working with jPlayer. This would enable a button on the interface so that you could control whether jPlayer repeats the current media or not.

If you do it externally, then it is pretty easy to do. I was adding it to a local demo and it works just fine, but it does make the jPlayer ready event handler rather ominous to our less JavaScript/jQuery/jPlayer literate users.

I could add it to the jPlayer core pretty easily too to avoid this... But we have a problem. The repeat function is different for single players and for playlist players. Single players just need to create an ended event handler that plays. Playlist players need to create an ended event handler that sends a command to the Playlist object for that instance.

My current thinking is along the lines of...

Add the cssSelectors for repeat and repeatOff and their methods.

These methods will default to those for the single player, as all jPlayer ever really does is play a single piece of media at any given time.

Then we add the new options for the custom functions required to enable the internal handlers to execute a given piece of code.

repeat: {
  on: function() {
  },
  off: function() {
  }
}

Something just occurred that a repeat option might be useful too. One that causes jPlayer to repeat by default... Hmm... you could just give the new jPlayer("repeat") command to the jPlayer node. Tag it on after the instancing on the jQuery chain. Something to consider though while I do this...

So we'd have these functions defined in the options... They would look similar to the event handlers, but these are different. These functions are executed when the repeat control interface button is used. So in other words, they are not an event handler. They are a function that executes when you press a button. Hopefully the code will work the same though, but I have a doubt that the $(this) in those functions will be broken if you want to refer back to the jPlayer entity itself.

jPlayer will then deal with all the interface stuff to show and hide the buttons... If no repeat functions are given, then the defaults will be used, otherwise those given will be executed.

I'm going to see how well this looks in the code... Over the months I have been wavering on whether to add this to the core, or to have a demo showing how to do it externally.

[Mark Panaghiston]

While on the throne, the thought occurred... Why not make a repeat event.

The internal code would do all the interface stuff and then just raise a repeat event, which would let you hook whatever you want on in and it would behave like any other jPlayer event.

So this repeat event would be generated when the repeat button is pressed. Make that the repeat AND the repeat-off button is clicked... The repeat event handler would then need to check the state of 'repeat', probably being stored on the status and then either add the ended event handler or destroy it.

Thinking about it again for the Playlists... For them we already create the ended event handler in the Playlist() object. Well, in its parameters... The repeat function here would really do nothing in the jPlayer core, so we are really disabling the default operation of repeat... Instead the repeat event would be used to loop the playlist as a whole and not individual tracks.

Hmmm... Then we would really want the default operation to be nothing... We would then only need a little repeat event handler in the single player code... Something like:

repeat: function(event) {
  if(event.jPlayer.status.repeat) {
    $(this).bind($.jPlayer.event.ended + ".jPlayer.jPlayerRepeat", function() {
      $(this).jPlayer("play");
    });
  } else {
    $(this).unbind(".jPlayerRepeat");
  }
}

Hmm.... Well I suppose the Playlist() version could just override the default, which could use the above, by doing this:

repeat: function(){}

Going to go have a think some more on this, but it does sound like the repeat event would be quite a nice way of doing this. The area I'd like to improve is the whole default situation, but I think you are damned either way.... You either need to give the handler all the time or disable the default handler when you don't want to use it.

[Mark Panaghiston]

Made great progress with the repeat feature.

One thing that cropped up though was with the initialization of the repeat handler... I found it when testing the playlist with it... If you use the reference back to the Playlist() object in the jPlayer constructor options parameter, then the event executes before the Playlist object has finished instantiating. This means that the pointer is not valid at the time the code executes.

Since I have been changing the Playlist() object a lot already, and have been planning many more changes when I got time... I just moved that option inside the Playlist object and then used a copy of this.

Moving code from the jPlayer constructor options has long been a plan for the Playlist()... along with renaming it to jPlayerPlaylist to eliminate any possible naming conflicts with the global object. So this is no big deal to me... But it does make me wonder...

There are quite a few events, error or warnings, that can fire off during the initialization process of jPlayer. And these could cause the same problem that I just found with the repeat event.

The ready event does not have this problem at all of course. It is delays using a timeout by 100ms. I believe 0ms would be enough to cause the normal execution of the code to complete before the ready event executed for the HTML solution. But that was not the point. The point is, all of these events that can occur during initialization should probably be delayed by 100ms if they occur.

Doing it for the new repeat event would be easy... But doing it for all the others would be difficult, unless they are always delayed by 100ms since they occur at generic parts of the code used by many systems... Or you have yet more code to only delay then during init.

In short... It all gets nasty and I do not recall a case where anyone raised these issues before.

In practice, if you are using good OOP code it is not a problem at all... It is just my rather sloppy code in the current 2.0.0 playlists that cause the problem. I originally did them that way as I thought it made them more configurable, but in practice it just means that people forget to make the names match up and the whole Playlist() object is harder to use.  I plan to move all of that to the Playlist object itself too.

Decisions... As the repeat event will always fire during jPlayer init, I will delay the event by 100ms. The errors and warnings that may occur during init will not be delayed.

The repeat event itself will fire off immediately after the ready event.

If anyone is still reading and feeling confused... The default repeat handler looks like this:

repeat: function(event) { // The default jPlayer repeat event handler
  if(event.jPlayer.options.loop) {

    $(this).bind($.jPlayer.event.ended + ".jPlayer.jPlayerRepeat", function() {
    $(this).jPlayer("play");
  });
  } else {
    $(this).unbind(".jPlayerRepeat");
  }

},

The one I use for the Playlist looks like:

repeat: function(event) {
  self.loop = event.jPlayer.options.loop;
}

Where self is a copy of the Playlist() object's this.

[Mark Panaghiston]

While writing the changes to the demos with the multiple instances, I decided to use them as a chance to demonstrate the repeat handler and how you can use it... While doing so, I found a bug in jQuery:
http://bugs.jquery.com/ticket/9786

They have already changed the docs for the unbind page:
http://api.jquery.com/unbind/

Apparently this never worked even though the docs said it did before they changed it just now.

[Mark Panaghiston]

Gah! There is a problem in jPlayer 2.0.19, where it uses a reserved word: interface.

Obviously I forgot to run the code through jshint before I published it as it flagged the problem clear as day today. Interestingly though, no browser actually complained about it when I did my cross-browser testing.

Suppose I will rename it to gui. We can rename jp-interface to jp-gui easily enough in the HTML/CSS if you have already started playing with 2.0.19 features.

I'll add this correction to the next dev patch.

[Mark Panaghiston]

jPlayer 2.0.20 patch released on GitHub.

Summary:

Implemented repeat control interface. Added loop option and repeat event with default handler. Changed interface naming to gui.

Release notes:

New Feature: [2.0.20] Implemented the repeat control interface.
Added the loop option (default: false) to determine initial state off loop.
Added the repeat option, which defaults to the repeat event handler for repeating a single piece of media.
Added cssSelectors: repeat (".jp-repeat") and repeatOff (".jp-repeat-off").
Added $.jPlayer.event.repeat event that occurs when the repeat state is changed and immediately before the ready event.
[Fixed 2.0.19] Renamed cssSelector interface (".jp-interface") to gui (".jp-gui").

[Mark Panaghiston]

jPlayer 2.0.21 patch released on GitHub.

Summary:

Corrected the auto ID creation code to work with jQuery 1.6+

Release notes:

Major Bug Fix: [2.0.21] Corrected the auto ID creation of the jPlayer div ID to work with jQuery 1.6+.
The original strict condition check on the jQuery.attr("id") has been changed to a falsy check.

[Mark Panaghiston]

A preview of jPlayer 2.0.20 can be found in this discussion:
https://groups.google.com/d/topic/jplayer/BLJURpOXwzU/discussion

It will help put those release notes into perspective.

[Mark Panaghiston]

There is a bug in 2.0.19 where if the GUI fade out effect is running when the restore-screen button is pressed, then the GUI is hidden when returning to the page.

I expect that the problem would also affect the autohide for both cases... Probably it is exaggerated when one is autohide and the other is permanently visible. i.e., The GUI would recover when the autohide is used on both, the next time you moved the mouse.

I hope to address this bug later today after I have got the Blue Monday skin up to scratch.

[Mark Panaghiston]

jPlayer 2.0.22 patch released on GitHub.

Summary:

Corrected the GUI display when changing screen mode during a GUI fade out.

[Mark Panaghiston]

WRT: $.jPlayer.platform["windows ce"]

I reviewed the odd looking code today and the member operator syntax is allowed. ie., The space is legal:
https://developer.mozilla.org/en/JavaScript/Reference/Operators/Member_Operators

Bracket notation

get = object[property_name];
object[property_name] = set;

property_name is a string. The string does not have to be a valid identifier; it can have any value, e.g. "1foo", "!bar!", or even " " (a space).

[Mark Panaghiston]

jPlayer 2.0.23 development patch released on GitHub.

Summary:

The instance is now correctly removed from the instances static object in the destroy method.

Details:

The instance object is a static object on the jPlayer prototype used to enable instances to control one another. This is primarily used in the pauseOthers method and in the $.jPlayer.pause() function. The instance is now removed correctly from the instances object in the destroy function.