flashblock ruins everything

[devsnd]

flashblock block the completion handler of jplayer and ruins everything. The user wont ever know why it doesn't work either.

[tilboerner]

we should mention that in README under 'Issues'.

[litemotiv]

How does this relate to "By default it uses HTML5 for music playback and supports flash as fallback"? It seems flash is needed always at the moment?

[devsnd]

In a sense, yes. We could add a config option to turn off the flash-fallback all together. The problem is, that the swf is loaded even if it isn't needed right now to provide the fallback later. But since jPlayer waits for all resources to be loaded before it is fully functional and Flash-Block keeps the http-connection alive, so that flash content can be later loaded.

If we had some way to easily determine if flashblock is available we could solve this in no time. Or maybe there is sokme kind of javascript library to download additional content, so we can set a timeout ourselves instead of relying on the browser... Then if it fails to load after a certain amount of time, we could simply turn off flash for that client.

[litemotiv]

I think you may have several options here;

• You can poll if a flash object is loaded with "typeof ", it will return 'object' if it's loaded and 'undefined' if it's not
• Dynamically loading something at a later time should be relatively simple, by creating a new node in the DOM for the script or object. Basic instructions can be found here: http://www.javascriptkit.com/javatutors/loadjavascriptcss.shtml

[tilboerner]

Any chance of fixing this easily for 0.21? Otherwise, I'd like to mention this in an "Issue" section to be added to README, because it seems quite a few people have some form of flashbock running.

[tilboerner]

I had a look at the source, and it seems that, when Flash is determined to be available, the player waits for a 'ready' event from Flash. If Flash is not available, it emulates this event after 100ms.

In jplayer.js, line 616:

this.flash.available = this._checkForFlash(10);

_checkForFlash(version) just checks if the plugin is installed.

I guess we could simply set a general timeout to call a function which checks if internal.ready is set, and if not, emulates flash ready.

This is a bit sloppy, since it possibly leaves jplayer in a state where it believes there's a flash solution that can play stuff. Not sure if we can expect any bad effects from this. To be on the safe side, we could add our own bool function _canLoadFlash(timeout) to line 616, which tries to load a flash object and then uses litemotiv's suggested way to look if it's there.

[tilboerner]

Actually, belay that! Further investigation has revealed crutial details. I shoulda looked more closely right away, not just assume how things work...

Firstly, a recap of relevant jplayer options:

solution: "flash,html",     // available players; order matters 
supplied: "mp3",            // media formats to be supported

The first solution mentioned is taken to be the default, the second acts as fallback. The formats in supplied tell jplayer whether it needs to provide video and/or audio. Lets call these the required media types. The fallback solution gets used only if the default does not support a required media type. For instance, let's say we specify a couple of audio formats in supplied; if the default can play even only one of them, the fallback will NOT be used, even if it can play more formats than the default. (relevant section in code)

Furthermore, if both solutions should be active for some reason, jplayer will ignore flash: see code starting here.

The above options are taken from our current jplayer config, and they mean that flash takes precedence over HTML5, even if HTML5 can play mp3, giving any flash blocker much more impact than necessary.

Now, I never really got into the details of our frontend; so it came as a surprise to me, Firefox and Opera don't support mp3 in their AUDIO tag. Nobody seems to support flac, only flash can handle it, like it does m4a; conversely, ogg has okay HTML support while the flash player won't touch it. Looks like transcoding is a handy feature to have indeed.

In light of that, supporting mp3, even to the possible detriment of other formats, seems like a reasonable default choice for us. Furthermore, it looks to me like we don't actually have a problem with flashblock. It's rather that more people than I previously thought need flash to be able to play MP3 files; these will need to whitelist the server no matter what. If we change the order the solutions are requested in, all others will be fine: jplayer won't even try to load flash, and flashblock matters NIL.

That way, we can be reasonably sure mp3 will work for people; support for other formats then depends on whether flash gets loaded, and if not, on people's browser and version. So I guess we need to put that information in a highly visible spot: Have people check what formats work for them (http://hpr.dogphilosophy.net/test/), tell them what the flash player can do and how to make sure that their favorite format can be played -- keeping in mind that they might need to enable flash in their browser. That's what I see as the short-term solution.

Beyond that, we can decide if we want to take steps to provide a more uniform experience. For instance, if we could serve ogg and mp3 versions for all audio files in a common format, we'd be able to guarantee playback and also drop flash.

Remarks? Ideas?

[devsnd]

Great investigation! I thought that there would be some kind of problem like that, since it did matter which solution was used to be able to play music on my android tablet. In my opinion it would be best to drop flash as much as possible:

1. Check which audio formats are being supported by the browser
2. If the format isn't supported, we try to transcode to a supported format
3. If no encoder is available, we try if flash could play that file
4. If flash is unavailable, there is a message stating "Please install encoder or whitelist cherrymusic/install flash"

In this order, we can assure that flash may die silently along the developement of cherrymusic. We could also supply a automatic downloader in the setup for the transcoders: They could be statically linked, so that we can overcome all this hassle completely in the future. This would also mean, that we can rely on flash not being necessary anymore!

I will try to complete the transcoder now, so we can try out different solutions.

BTW: Is there a graph or something which can display the results gathered on "http://hpr.dogphilosophy.net/test/" somewhere?

[tilboerner]

Is there a graph or something which can display the results gathered on "http://hpr.dogphilosophy.net/test/" somewhere?

None that I was able to find. Just a couple more "live tests", like jplayer's own test page. I just found this table for general audio support, but it doesn't take file formats into account.

While its easy to find out what formats the browser or a jplayer instance can (probably) play, getting jplayer to work with html and flash in parallel would mean getting our hands dirty. It's probably doable, but we'd need to make a couple of changes to the codebase (as opposed to mere additions), which will likely make upstream improvements more painful to integrate.

Given how patchy support for the different formats is (and was) in the browser landscape, I wonder why the jplayer folks went with that "either/or" approach to their solutions in the first place. Is it that much easier? The way it works now, jplayer is really only good for one format, which you get to pick.

I think we should consider the idea that having a multi-format music collection will mean some work for the users: getting some transcoders to either pre-transcode what they have to a format they like, or transcode on the fly with cherrymusic. We can strive to help them along the way as much as possible; just an idea, but maybe cherrymusic could even offer to save the result or replace the original, so that much of their library can automatically adapt. The thought of writing and maintaining something that can install transcoder binaries along with a multi-platform application makes me... cringe.

[6arms1leg]

@tilboerner i dont like the idea of pre-transcoding a multi-format music collection. the users may have a music collection with different formats and want to keep it that way (like me, for example). i dont want my .flacs to be transcoded to .mp3 or anything else. same goes for some other formats. if some users want to transcode their entire music collection, then thats fine and they can do so by hand, script or another program. in my opinion, offering a feature in cherrymusic to automatically transcode the whole music collection is bad. i think, cherrymusic should focus on what its supposed to do: serving (streaming) music to clients and not managing the music collection. please dont let this become another "itunes" or windows media player some day. when the flash/jplayer problem is in need for on-the-fly transcoding, thats fine, but please leave it at that. there are enough programs out there for managing a music collection and for transcoding different formats. i think the users music collection should remain untouched.

i hope you can see my point.

[tilboerner]

Haha, it's like I poked you in the side and hit an exposed nerve or something. :-) Sorry, yeah, I understand completely. I was just thinking of all the processor cycles that go into transcoding a song again and again... but you're right, saving transcoded versions in the middle of my collection would feel like a lot like pollution to me, and not like something I'd easily agree to. If, at some theoretical point, we see servers choking on requests for live transcoding, we can still decide whether it makes sense to introduce a config option for a quiet little cache, somewhere completely different...

[6arms1leg]

im sorry, i didnt mean to be harsh. its just, i get sick when programs try to take over control (the management of my music collection) or do too much stuff i dont want them to do. i had that trouble once with itunes...

[tilboerner]

No harshness taken. ;)

[tilboerner]

1. Check which audio formats are being supported by the browser

When requesting a file, the browser could supply a list of all playable formats; the API will answer with one of those, or with something that signals an error. No?

[devsnd]

No. What the browser reports is unfortunately far from true: The reports seem to be accurate for ogg and mp3, but not necessarily for any other format.

Also, the current implementation works the other way around: The client gets all formats understood by the server and can then decide if it wants the server to transcode it. This works very well actually.

[tilboerner]

so, is there anything left to do here? seeing that flashblock really only blocks legitimate flash usage, i mean.

[tilboerner]

I added some blurb about flashblock to README, feel free to change it to your liking.

also, in there it says:

By default it uses HTML5 for music playback and supports flash as fallback.

but that's not what we're currently doing, is it? it's more like the other way 'round.

[devsnd]

Please check if it works for you as for me: the flashblock-thingy should appear big over the actual player, so that it's easy to permit. Tried with firefox, opera and chromium.

Little extra feature for firefox: There is an error message telling the user to switch on flash.

[tilboerner]

works for me on recent firefox (17.0) and chromium (23.0). nice fix!