-
You can no longer customize the Logo (with paid version) with 7.1.14.727.beta.
This is pretty bad… For some of us, it makes the plugin unusable.
-
-
Hi Anonymous!
Are you using new player 7.1.14.727 in beta or release version – just to confirm. And can you describe the issue more closely: You have your logo shown but it is not responsive or some other visual issue or not showing the logo at all?
Thanks,
Lucia
Hello,
we are sorry about the issue here, but unfortunately Flowplayer forces us to use a new key with each release, so we have to build a fairly complex mechanism for updating the license key on each website. In some cases it fails.
I checked the logs and I can see that your website has received the correct key. Are you still having the issue?
Please compare the license key which you have on Settings -> FV Player to the one on https://foliovision.com/my-licenses – is it the same?
However I think I realized what is the issue now and put in a fix. The issues only occurs when upgrading from the latest FV Player 7 Beta release to FV Player 7. Users upgrading from FV Player 6 or older FV Player 7 beta versions don’t face the issue.
Thanks,
Martin
Hey guys, Thanks for the quick response. But I have some bad news:
The issue is still not fixed. We still get the “FV Flowplayer” Logo during playback…
In addition, now the videos take over a minute to load and start streaming!!!
They eventually do, but it takes ages. (We are using HLS Cloudfront distro btw…)
This might help: I’ve checked them using multiple VPN connections from different regions. Some of them are a little faster, but overall the experience is slowed down. Without using a VPN is noticably faster, but still slow. Besides, many users do use VPNs so, telling them not to use it is unacceptable.
You need to speed up the playback start time with this last release. It was working fine in the previous one…
Here are some additional observations:
I’ve looked through your codebase (lots of great code btw :)
But, here’s the thing: You’re already checking for license during install, and also scheduling a daily for a cron job to check it. Why also check it during playback on your side?
From what I understand, the player is “checking in” with your server for EVERY playback to see if it’s got a valid license. That burdens every video playback – and since your change of that code coincides with the slowing down of the videos – I think that’s where the problem is.
I’m concerned because that design makes our sites dependent on your licensing servers for every video playback!
More importantly, I don’t think you should burden the user experience of our customers by delaying them for a license check that you’ve already performed several times for our domain. There must be an easier way.
You could at least cache it on the database daily during your cron job and check during every video playback. Or, cache it per user session. Or do an async check – still check for the license with every playback but don’t block the player’s operation until the license check actually fails.
That way, our users don’t have to wait for your servers.
Also – do you have Service Level Agreement for your license servers. What if they go down? Will playback eventually start, or will the whole thing stop working?
Please fix this fast, it is hurting our business. A minute to start a video equals player not working.
PS – By the way: if you guys need some automated testing infrastructure to capture errors like this, you should contact me off board… I’d help you out. Or you could setup something like this: http://topnotch.tech/web-guard-your-page/
I know you’re working hard, but it’s also disappointing to be the customer who discovers that a feature we paid for has stopped working.
Hello,
please use Settings -> FV Player -> Help -> Rollback if you think it’s caused by FV Player 7. We can continue troubleshooting the issue next week.
I’m not noticing any increase in delay on our Cloudfront HLS streams.
We are not performing license key checks in the frontend like you are suspecting. I double checked and I’m not seeing a large number of license checks coming from your website.
But perhaps you are onto something – the Ajax calls required to load some of the videos (not the case with simple HLS streams, it’s only used for video files which have the time sensitive signature in the URL) might be considered as wp-admin calls by WP API and the license check might be triggering on that one (I will check that). But it should be cached for full 24 hours (I already checked that and it appears to be fine).
Our testing is partly automated (PHP unit tests, WP integration tests, browser tests with Selenium and Appium) and partly manual (visual changes (for now), more advanced functions like transcript, license activation process etc.).
Thanks,
Martin
Thanks for the quick and detailed response and excellent service! And thanks for letting me know about the rollback option – that is and comforting. (And it’s good to hear about the license checks…)
Anyway… I did some network analysis and I think you are right. It looks like the culprit with the delay is a HLS related query; at least that’s the one with the longest consistent delays. Occasionally CloudFront chokes too, which can throw off the numbers through proxy or VPN connects.
Keep up the great work!
@Lucia, we’re on 7.1.14.727.beta. We use our own logo, which used to show in the previous version. Post update, it shows your logo (FV Flowplayer). The rest of the player works fine.
Hi!
* I know Martin already mentioned this – did you compare that the license key in your account matches the one on your site?
* Can you also try to delete the license key (save it somewhere). Save settings. And then again insert the same key and click apply pro upgrade.
If this fails too then we have to have a look why your particular domain failed the check.
Thanks,
Lucia
Hello,
that HLS query argument which you mentioned is the license URL for the encrypted stream. It should only take 1-2 seconds. How big delay are you seeing?
Thanks,
Martin
Hello,
I can confirm that the FV Player license checks are not running on the front-end Ajax calls. So if something is acting slow on your end, there must be some other reason for it.
Thanks,
Martin
