If no stream, immediate error message, unlike V5...
I just purchased Premium package.
In JW 5, when you brought up the player and there is no stream, the player would keep waiting for stream, with the spinning swirl.
Now, with JW 6, if there is no stream, the player immediately comes up with error message: "Error loading Stream: ID Not Found on Server." I don't want that - I want it to be like JW5, where it will wait (forever) until it gets a stream.
How do I achieve this? If not, is there a way to suppress or change the error message?
Sometimes people will tune in a couple minutes before you activate a stream, so this is a problem.
I appreciate your response. Thanks. Vic vic@vicware.com
I'm not streaming anything to it at the moment, which is the point.
I created this so it will look for a stream every few seconds, though that's kind of irrelevant. You must very well know that V5 waited for a stream when you first started the player, and V6 does not!
Either I need it to work like V5, or I need a way to suppress or modify the "ID Not Found..." error message.
I'm sorry. I've gone through that page several times in the last 48 hours, and I just went through it again. I don't see *anything* about suppressing that onError message. I see you can retrieve the error message with the onError event attribute "message", and that's it. Maybe I'm missing something. Can you please tell me what you're talking about?
I think you are nearly there... You just need to re-assign the "onError" event function after you've re-setup the player.
A couple of points to note:
> "onError" only fires once - so you need to re-instantiate the player on an error condition after a time period (which you are doing) > But, when you call jwplayer().setup() again, a new instance is created - the old events are no longer attached - you need to re-attach these event listeners.
I was debugging your example but your stream was activated so couldn't provide a more complete suggestion.
My line of thought would be to have a placeholder image which is shown when the stream is down (or goes down) and have the player hidden (but regularly re-initializing) with the "onReady" and "onError" events driving what should be shown - toggling between the player or the placeholder image.
It means - when you first start a web page with a player, the player swirl spins continuously until the player gets the stream. It will keep on waiting for a stream. Like I keep on saying - just like JW5 player worked.
Good idea - This is the way V5 looks - http://www.ruralfreetv.com/rftv/channels/channel04/rftvpage04.html when there is no stream - it will wait forever for a stream to come in.
This is the way V6 looks - http://www.ruralfreetv.com/rftv/channels/test/chantestwow02.html It's after 3 days of work - the best way to loop to wait until a stream comes in. But I need to get rid of the error message. I cannot use this - my clients don't want to see the error message! But I have to have it work as V5 in the first example.
I might have not made it clear in my earlier correspondence - For me - forget about MP4's or any VOD. I am doing RTMP LIVE STREAMING! (from Influxis as server) ONLY! So I appreciate the code snippet you supplied me on Friday, but it doesn't work for RTMP LIVE Streaming! i.e. the buffer functions do not work - always shows 0. And, it has to work on desktop just as well as mobile.
If you guys can't give me a solution quickly to fix this, I'll have to switch back down to V5, and I want to know if you will give me a sn to use V5 until such time that you fix V6 to work the same way, or a way to suppress the error message for LIVE RTMP streaming. $300 is a lot of money for a year's subscription for software that doesn't work right for me.
Please make sure you read the post just above this one first.
I wanted to add to the post just above this one, that in the second example for V6, that not only will the player pick up a stream which is not there when you first start the player, if there is a stream, and the stream is lost, this algorithm WILL go back to looping to wait for the stream to return. So, not only will it wait for a stream, it will also RECONNECT upon loosing a stream, and will then get it back! It's just that freakin' error message that's ruining everything. If you can suppress that error message, or change it to something like "No Stream - please standy-by." I know this is not the way many mobile devices work, but I must have this for desktop users.
Thank you for all your obvious time you spent on this.
Unfortunately, it doesn't work - it doesn't play the live stream. I know you didn't have the real, live stream to work with when you wrote this, so it's understandable.
I went through the code locally, did some tests, but can't find anything obvious.
I am now running that stream! You can confirm it's live and streaming video with: http://www.ruralfreetv.com/rftv/channels/test/
So, if you run your url - http://dev.powered-by-haiku.co.uk/jw-html-config/debug/vic.htm you should see nothing changes and no live rtmp is playing, which is what I get.
*I will leave this live stream running all day, so maybe you can locate what the problem is.*
There may be some tweaks required as you implement it for your specific needs - probably need to handle the "message" differently for iPhone / Mobile as autoplay doesn't work on these devices, so you always need to click in order to find out the current stream state - no way around that i'm afraid.
500: Internal server errorThis error is generated when a script running on the server could not be implemented or permissions are incorrectly assigned for files or directoriesTroubleshooting suggestions:Temporarily disable any rewrite rules by renaming your .htaccess file if it exists.Ensure that any CGI or Perl scripts have at least .755. permissions.If trying to run PHP and you get this error, you may have an invalid php.ini in your /cgi-bin, or may be missing your php.dat file in this folder.
First - that internal server error is a freakin' Network Solutions problem that happens occasionally - I want to kill them! Or find another hosting service.
I just had my partners test on their iPhones. When they bring the url up on iPhone, the screen comes up with the "stream is currently unavailable... Auto-retry is ON." But if you tap on the screen (and there is a live stream feed) it will play the stream ok. As you describe in your post above.
I haven't had a chance to re-code your code, but my one question is - will I be able to differentiate that the user is an iPhone, and so put a play button or "click to play" text (play button would be much better, of course). It seems for an iPhone, in any case, all that should be there is a play button. *If you have a good suggestion on how to handle this, It will be greatly appreciated, and you'll retain your A :) *
Thank you much for your help - I hope this will help other people. Vic
I've tweaked my example to account for Mobile users - whilst what you suggested works for when there is a stream available, you need to cater for the situation when the stream isn't currently running - otherwise on a mobile when they press play - and the player is reloaded due to the error state - they would be presented with a reloaded player and it would look as though nothing had happened.
You are absolutely right, sir. A bit of a clockwork orange, this whole business.
I don't know why you guys didn't use the same "wait-to-play" you had for desktop in V5. All this work would be unnecessary. I would love to hear the thinking on why that was changed.
I will go through your newest version tonight and let you know. One thing is for sure - I'm much closer to where I need to be than I was yesterday.
Your support is greatly appreciated. If it means anything, I have a sales team working on a project to stream from thousands of schools around the country. If it works out, your player will be well used (though I know zillions already use your player).
Thanks, again - I will get back to you on results. Vic
On desktop, your script works fine. It will show a message when there is no script.. It will then play itself when it gets an incoming stream. If the stream is interrupted, it will come back when the stream returns. All good.
On iPhone - works similar, with the difference it won't start itself. As you noted iPhone won't autostart.
*On Android - trouble!* If a stream is currently running, it plays the stream fine. If you stop the stream, the player just freezes, and just sits there. Even if you restart the stream, it does not return to playing the stream. If there is not a stream, and you bring up the player, and then start the stream, it does not play it.
So, it's not working right for Android. These tests were done with a Galaxy 4, which is a fairly recent Android device.
Look, James, I'm just looking for a stable core script for engaging any of the major devices, and desktop in most browsers. once I have that I will customize it. I'm also very busy writing scientific web apps, and can't spend the next weeks and months trying to get a core, working player script.
Since you mentioned you're not with JW, I would tell you I can put together some pay if necessary, to work with me on getting this code right. Hopefully I would get blessings from JW doing that. I have to do what I have to do to get this job done. So I want to make clear I wouldn't be presumptuous on your time, being a kindred code writer. You're obviously much more experienced with JW than I am, and I just need to get this done in the next day or two, if possible. I didn't know V6 would be so different from J5.
So whatever I have to do to convince you to make this all work I will do. It's just Android now that's fouled up. Please let me know what you can do.
As it stands the page is still loading your "sNav.js" which detects Android / Blackberry and then directly loads the "rtsp://" stream - allowing the device to determine how best to deal with the stream, not JW player.
This is the JW recommended approach.
However it therefore means there will be no detectable event states fired - as the stream may be played in the native Android video player outside of the scope of JW player - this is why an existing available stream will be picked up (at the time of page load), but none of the other conditions are met/detected.
I'll look into this further, but I think the best we would be able to do is to launch the stream if it is already online, or when it comes online (similar to the iPhone technique). I'm not sure we'll be able to do anything about the stream going offline once already playing, but I'll see what I can do.
Thanks so much - I started playing that same stream and I will let it run all day - just for you.
Actually, that sNav.js is incomplete - I was waiting for the Influxis guy to give me the completed algorithm - you'll notice he has Android 3 times - I'm waiting for him to do it because they have their own set of recommendations for JW Player and I was waiting. Maybe that's a mistake on my part.
I appreciate your help, James! As I said my last post I will work with you any way you like. I'm up against a wall as I explained. I'll be standing by.
I changed my test page to use your new code: http://www.ruralfreetv.com/rftv/channels/test/
Let me tell you how important it is how you set up this player driver the way you did. It's a huge difference that a user sees simply "Waiting for stream.." instead of some error message. In my opinion, this seemingly small thing is stupendously important!
But even bigger, is that this string can be replaced with anything, including - you could query a schedule database and tell the user i.e. when the next scheduled live feed is. Along with graphics, etc. This is very important. I thank you, again, for this. I hope that JW appreciates you for where this is going.
I agree with you about Android might be limited to wait-for-stream, and reconnect may not be possible. I look forward to seeing if you figure it out.
I'd be interested in your thoughts now, particularly on iPad, iPhone and Android - try leaving it a minute after the page has loaded to see the message change.
ok, in process, everything seems to go to prompts for user action, depending on the circumstance 1. player starts before a stream - then stream starts (wait-for-stream). 2. Player is running with stream, and then stream stops (reconnect)
Generally, the biggest thing - I'll see if I can trim the wait times on some of these timeouts. i.e...
Android - 1. If you start up the player in Android with no stream running - it gives you the message, and then you start the stream and it will come up with the play button.
2. When you stop the stream when Android is playing it, the video just freezes, and there's nothing on the screen except that last frame. It waits a whole minute to go to a different prompt. If you start the stream, it will switch to a ready message, and then you can hit play. It's not good that a user would be sitting there with frozen image for a minute with no explanation. I think 60 seconds is way too long to wait, in this case.
iPad - After a minute, it breaks to a black screen with the static circle w/arrow - if you press on the circle w/arrow, nothing happens, but if you press anywhere outside of this arrow it will play the video again (if stream has returned).
iPhone - works similiarly.
Because I have my partner doing this testing from his end, it's a little difficult getting clear analysis of what's happening - I have to do more testing.
But this is close - to review - the 2 things to note was 1. The useless circle w/arrow on the iPad and 2. having to look at frozen video without message for a minute on Android.
But this is pretty good considering I had nothing just a few days ago.
Yeah, it's tricky - I'm currently developing based on the "what should happen" methodology - given I don't have control over the stream! Ideally I'd be able to test scenarios better by switching the stream on and off as I needed.
Anyway, this is what is supposed to happen:
*Desktop* ====== *No stream available:* Presents the poster image with a configurable message stating that it is a live stream and it will auto-connect when the stream becomes available. The user has the ability to toggle this "auto-retry" feature on/off. *Stream availability checked every X seconds* Because the "autoplay" setting of JW player is set to "true", JW Player will try and connect to the stream, and based on the result will either confirm the availability or go into an error state. The error handling function will wait for X seconds before rebuilding JW Player and trying again. *Stream becomes available:* Stream will auto play and the poster/message disappears. *User interacts with the video:* Normal JW Player functionality is available. *Stream is lost during playback:* Player disappears and the poster/message with auto-retry toggle feature is displayed. Again, this is due to the JW error state being fired, and a new JW instance being created.
I believe this all works as described.
*iPad/iPhone* ========= *No stream available:* Initially, presents the poster image with a configurable message stating that it is a live stream and the user has the ability to manually check it's current availability. *Stream availability checked every Y seconds* Because "autoplay" doesn't work on mobile devices, I've written a separate "stream check"[1] process which determines the current state of the stream and updates the message accordingly. *Stream becomes available:* Message changes to indicate that the stream is now available, and the user is presented with a "play" button. We can't auto start on mobile devices. *User presses play:* The message disappears and the player is presented [2]. The "stream check" process is stopped. *User interacts with the video:* Normal JW Player functionality is available [3]. *Stream is lost during playback:* Player disappears and the initial poster/message with manual check capability is represented. The "stream check" process is re-enabled - meaning the message will update after Y seconds. [4]
[1] - This requires certain conditions to be met (further discussion required!). The timer is currently set to 1 minute (but is configurable). Setting this to anything less than 5 seconds will turn the "stream check" process off, and the user will need to check manually. Whilst the sensitivity around a mobile device polling for a stream every Y seconds might raise questions, depending on the users intentions when visiting the page you can potentially assume the device has the network capability to cope with a live stream and so a poll every 10 seconds would be acceptable - but that assumes they intend viewing the stream...! [2] - On iPad this is played inline. On iPhone this opens into the native player window. [3] - On iOS, the native video player controls take over once the video has been started - hence the big "play" circle. This is normal iOS/JW behaviour. [4] - The fact you are still seeing the native player controls when the stream is interrupted on iPad/iPhone suggests the error state is not actually being fired - this needs confirming, but might be a JW bug. We could potentially work round this by adapting the "stream check" process.
*Android* ========= *No stream available:* Initially, presents the poster image with a message stating that it is a live stream and the user has the ability to manually check it's current availability (as per iPhone). *Stream availability checked every Y seconds* Using the "stream check" process described above which determines the current state of the stream and updates the message accordingly. *Stream becomes available:* Message changes to indicate that the stream is now available, and the user is presented with a "play" button. We can't auto start on mobile devices. *User presses play:* This links directly to the "RTSP" stream, which prompts the user to decide which player software they wish use to view the stream (outside of JW Player). The "check stream" process continues to run. *User interacts with the video:* This will be outside of JW Player and so there are no detectable events or errors triggered. *Stream is lost during playback:* The chosen player will react according to how it has been developed to deal with a "lost stream state" this is outside of our control. However, when the user closes the player window down and they return to the web page, the current stream status will be indicated on the page as the "check stream" process has continued to run.
I believe this all works as described.
*In conclusion* ========== I need to determine whether the JW "onError" event is fired when the stream is lost in iOS - and potentially adapt the code accordingly - otherwise I think we are as close as we are going to get to an elegant stream management solution.
I think you're close to having this together. Before I take up any more of your time, I want you to know that I have on order 2 new mobile devices (Android and iPhone) which I should have by the end of the week. This is the only way to give you more precise feedback, and can track down i.e. onError events and behavior more exactingly. I did have a couple of times yesterday when the player on desktop froze while playing video normally - don't know what that was about, but I'll be in a better position to know what's going on after gearing up with some new, modern mobile devices.
So, standby - I will get back to you by the beginning of next week. You've done a fantastic job helping to get this player support code together this week.
Of course, I am unable to see the check-stream.php file that's on your server.
When I do use: "www.dev.powered-by-haiku.co.uk/cors-proxy/check-stream.php?acct=ownv05&file=playlist.m3u8" I do see what the output is with some stream data info: #EXTM3U #EXT-X-VERSION:3 #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=976151,CODECS="avc1.100.30, mp4a.40.2",RESOLUTION=640x360 chunklist_w1530671764.m3u8
Can you explain to me what this is about, what the return data is used for in the script, and whether it is necessary on my end?
I get that your using that check-stream.php file on your server to use for checking the veracity of a stream, via the checkStreamForMsg object, but I feel funny about using code on your server without talking about long-term usage of it. If I get i.e. a thousand viewers using this player, that's a bunch of accessing of your server, and I'm not sure that's what you want. Or maybe you do. I need an idea of what agreements we need to make about this. Or, can I put a local copy of this php script on my server.
In order to check the availability of your stream (for Android / iPhone) I need to access the HLS manifest, find the name of one of your stream resolution files, and then check the availability of this file. I assume that the availability of the HLS file means the RTSP stream will also be available. This is one of the dependencies of the "stream checker" I eluded to in my previous post.
In order to overcome the CORS restrictions applied to your stream file (I presume restrictions are set on your "cloud.influxis.com" stream file to only allow Cross Origin Requests from your "*.ruralfreetv.com" domain), I need to go via a proxy that I've written specifically for this task.
If running this from a CORS allowed domain (such as yours), you can comment out the *oConfig["checkStreamURL"] = "...";* and *oConfig["checkStreamFilename"] = "...";* lines and the stream checker should work directly!
