Name is required.
Email address is required.
Invalid email address
Answer is required.
Exceeding max length of 5KB

Clarification on self-hosted.


On this support page:
http://www.longtailvideo.com/support/jw-player/31770/cloud-hosted-vs-self-hosted-jw-player
The documentation clearly states that an advantage of jwplayer self hosted is: "Full control over where the JW Player is hosted & loaded from. This is useful for scenarios where JW Player is used offline or behind the firewall"

I have downloaded and installed jwPlayer 6.8, but when I don't have an internet connection, the javascript tries to load "http://p.jwpcdn.com/6/8/jwpsrv.js". Worst of all, it fails completely if it can't find it!

Today I was showing a client an intranet site I built using jwplayer, but when I loaded it up on my localhost webserver without an internet connection, the video player part failed! I had hoped to ensure that the player would load even if the external internet connection was to be cut.

I run another site where the main internet connection is via satellite and I don't want to wait for a signal to bounce back and forth to space a few times before I can load the player, or fail to load in heavy weather.

If this is not in fact a feature, please remove it from your documentation.

If there is a way to disable external connections, please let me know.

Many thanks,

- Rob

13 Community Answers

JW Player

User  
0 rated :

If you're self-hosting, the script shouldn't be loading http://p.jwpcdn.com/6/8/jwpsrv.js - that should happen only if you're loading the script from JW Player.

However, even when you're self-hosting, there are a few files that the script still loads from JW Player, so yes, you must have an Internet connection. It doesn't matter whether you're running a local server or just loading a page on your own C: drive - it still needs that Internet connection.

In short, JW Player's statement about "full control" is manifestly _not_ true. It _can't_ be used offline, and it can't be used behind a firewall that blocks the access it needs. It's not clear why JW Player has made this poor design decision, or why it continues to make misstatements about it.

JW Player

User  
0 rated :

But it does load that file. Not sure the reason, but that's the error I get in JavaScript console, and confirmed via wireshark that it does request the file. (Though I totally agree that it "shouldn't")

Well, that's kinda bunk. The firewall and offline thing was a big reason for choosing JW. It's not a hard fix, but I don't want to get hacky with the code on a system I don't plan on maintaining.

So let this be a vote to get this fixed.

JW Player

User  
0 rated :

This is the infamous analytics plugin issue... which is "definitely" going to be fixed in 6.9!

Although it's worrying that there is no active ticket for it currently, I got the following in an email exchange with Jeroen following my blog post: http://powered-by-haiku.co.uk/?p=655

bc.. Your main point is very valid, as we indeed still have not tackled this analytics plugin error issue. I just did a quick test to confirm this on 6.8. We will definitely fix it for 6.9, so that the plugin silently errors out instead of blocking the player.



We'll see...

JW Player

User  
0 rated :

And by "fixed," do they mean that when you pay top dollar, you'll be able to run JW Player offline? Or are they actually going to stand the logic upright again, disable analytics in the free version, make it possible to use the free version offline, and enable analytics only for paying customers, you know, the ones who might actually _want_ analytics?

JW Player

User  
0 rated :

I'm not sure about where they will align the disabling of analytics in terms of edition, but to be honest, if they fix this issue it becomes less relevant *for the bulk of use-cases that have highlighted the problem*.

Whilst their reasoning for having analytics enforced across the range of editions is understandable:

bc.. We definitely have selfish reasons for this (measure network size, identify license offenders), but we also use the data to guide our roadmap and build out the right (=popular) functionality.



I think they will always face challenges by organisations who don't want to pay a premium in order to provide a "perceived" level of anonymity to their customers - but that's a different issue, fundamentally you shouldn't have to pay to get the player to work in the first place - and hopefully they have committed to finally fixing this.

JW Player

User  
0 rated :

Given the almost complete lack of license key security, their comment about identifying license offenders is a real thigh-slapper. ;)

JW Player

User  
0 rated :

Sure, but be careful what you wish for...

The only true way to validate a license key would be to call home to check against a "white-list" of domain names...

Oops! Now the player won't function because it's being used on an invalid domain!

JW Player

User  
0 rated :

Or worse still, it can't call home!

JW Player

User  
0 rated :

That wouldn't be awful, but only if it were implemented properly. Nothing wrong with checking the license against a list of valid domains. That's only fair - no one is expecting JW Player to give away all of the functionality they've built into their product (though the "subscription" licensing model is utterly nonsensical).

But if the player can't phone home, either because the JW server is inaccessible or because the player is being used offline, it should just work, not error out. How many "cheaters" are going to use the player in a perpetually offline mode? Yeah, I suppose some corporation might use it behind their own firewall, block access to JW, and thereby "steal" the player. But if they're providing videos to the _hoi polloi_, who manifestly aren't blocking access to the JW server, that's not going to do them any good, is it?

JW Player

User  
0 rated :

Exactly. The balance is between enforcing a license checking model that isn't considered a farce, but also doesn't hamstring functionality in other scenarios.

bc.. Yeah, I suppose some corporation might use it behind their own firewall, block access to JW, and thereby "steal" the player.



You don't need to be a corporate to want to be able to package a video player with your brand, potentially including Ads and HLS on desktop within a managed network, and not want to spend $300+/year for the privilege... I can think of a few scenarios where this could happen.

If you want to safeguard against that "exception" you are back in the realms of not allowing offline implementations at all. If you choose to allow offline use, the concept of a licensing key is a farce.

Either way you are damned!

Ethan Feldman

JW Player Support Agent  
0 rated :

Thanks for the feedback guys. Jeroen indeed replied to James and gave him feedback based on the blog post.

JW Player

User  
0 rated :

Thanks Ethan for the official response. I do like JW Player, and I'll keep using it, looking forward to this fix.

I do understand why it might want to call home, but it really needs to be an asynchronous request that doesn't cause a failure.

Ethan Feldman

JW Player Support Agent  
0 rated :

Np.

This question has received the maximum number of answers.