After updating to the latest JW Player (7.12.0), the issues I had in a previous topic (https://support.jwplayer.com/customer/portal/questions/17073741-chrome-states-no-suitable-players-found-) fixed themselves for a few weeks in Chrome, but now I am seeing it again. Plays in FireFox and Edge with no problem. Please help!
Testing URL : https://citynet.net/snowshoe/cam2.cfm?feed=2
I am able to get that working in Chrome, were you also running JW 6 and just updated to JW 7?
The player on that page didn't work for 24 hours, then all the sudden it started working again a bit ago. I updated to JW7 about 2 weeks ago, and it ran fine until yesterday. Doesn't make any sense. Any thoughts? Thanks...
Were you able to check if the feed was up still? Also, if your page is HTTPS then your streams should also be served over HTTPS as well. I am seeing mixed content warnings in the browser console.
I did, via VLC Media Player and it was fine. I see your point about HTTPS, but that page has had mixed content on it for weeks and Chrome has no issues with it until yesterday. Very odd...
I think you should list the HLS stream first so the player renders in HTML5 and won’t use flash at all.
New test page:
https://citynet.net/snowshoe/test.cfm?feed=2
I removed the non-secure images from the page, and I also moved the HLS stream to the top. Still a no-go in Chrome, but plays in FireFox and Edge with no problem. Any ideas?
The cloud-hosted JW Player has a built-in license key that rotates, so it is not necessary to add a license key like on your page. Remove the incorrect JW 6 key on the page and upgrade your account to a Premium Subscription so you can use the Premium edition of JW 7 that enables HLS playback.
I removed the license key from the page.
As for the account: we DID purchase the Premium Subscription years ago, but something happened when you guys redid your site/database that displays our account on the web as "Free". My company has been in contact with yours several times to get the issue rectified to no avail. It's very annoying, and we've basically given up. Maybe you can help with that, too?
The Premium Subscription you purchased was for JW 6. When JW 7 was released we moved to a yearly subscription model. I’m not seeing any other tickets you submitted relating to account issues but if you want to e-mail support at jw player dot com directly and reference #111534 we can take this conversation off the forum.
Warm Regards,
Donni
Thanks for looking into it for me. We can take this off the forum, for I just put in a PO to our Finance department and should be purchasing the yearly plan soon.
So, we've upgraded our account to the Premium subscription. Finally, Chrome is displaying the videos BUT now iOS won't play them! Need some more help!
Testing URL : https://citynet.net/snowshoe/cam2.cfm?feed=2
Works for me. What are you seeing?
Player states "Error loading media: File could not be played". Tested on two iPads and one iPhone 6 (all running same version of iOS).
I’m not seeing that on two of my test devices running the latest OS. Open a private window and see if it works – maybe its pulling up the cached version of the page that was using RTMP =>http://imgur.com/a/Pj8B0
I opened a Private Window (with Safari) AND open an Incognito tab (with Chrome) and still not seeing the videos playing, getting same error: "Error loading media: File could not be played"
Also, I put a "View Source" bookmark/script on my test iPad and viewed the page and it IS seeing the updated code (i.e. code not using RTMP)
Sorry, I’m on my personal devices now and https://citynet.net/snowshoe/cam2.cfm?feed=2 is working on both of them. Can you try a different network?
I just tried it using my AT&T LTE data connection, still the same results for me...
Think I figured it out: in my code, I moved the non-SMIL source from first position to the last position (from a total of 3 sources) and it now works on all my iOS devices. Can you please provide an explanation for that? Thanks much...
It worked on my devices with your original configuration so I can only assume there was an issue at the device-level.
