adam1010 19 Posted August 14, 2017 Share Posted August 14, 2017 (edited) When I go to play some movies in web app (Chrome Win10), the loading spinner just stays forever. If you open Network/Inspector you'll see it's trying to load stream.mp4 but keeps cancelling the request. I let this go on for 5minutes and it made over 60,000 failed requests!!! Over 750Megs worth of data was transferred before I finally stopped it (no video ever displayed). I'm running a relatively recent Linux server 3.2.25. The log file is over 650megs so I trimmed it down :-) Log: emby-web2017-08-14.log Edited August 14, 2017 by adam1010 Link to comment Share on other sites More sharing options...
Luke 37249 Posted August 14, 2017 Share Posted August 14, 2017 I tested direct play of some mp4's and it worked fine. I notice you're using SSL over a local 192.X network address. You might consider simplifying and using http over your local network. Link to comment Share on other sites More sharing options...
adam1010 19 Posted August 14, 2017 Author Share Posted August 14, 2017 I tested the movie again without SSL and the problem did not go away. The movie plays fine in VLC so it's not corrupt. It seems like at some point the browser should give up and display an error message -- since the log file was growing by 1gig every 5 minutes if someone accidentally left the tab open overnight it could be an issue. Link to comment Share on other sites More sharing options...
Luke 37249 Posted August 14, 2017 Share Posted August 14, 2017 The movie plays fine in VLC so it's not corrupt. Actually this is not true because VLC is a player that is designed to be highly resilient to all kinds of input along with their anomalies. Browser video players are not built for that. Link to comment Share on other sites More sharing options...
adam1010 19 Posted August 14, 2017 Author Share Posted August 14, 2017 Understood -- my point was that ffmpeg should be able to handle it if VLC player can. So if the server notices there is a problem using direct play (based on the tens of thousands of failed requests), it should attempt to transcode the video to fix the compatibility issue. Because the playback controls don't load, the user is currently not given the opportunity to switch from direct play => transcoding to attempt to fix the issue. EDIT: I verified that ffmpeg is able to fix the video by enabling transcoding. I switched to another (working) movie, lowered the quality settings, then switched back to the problematic movie to force transcoding (the video played immediately). I think having the server automatically enable transcoding is acceptable when in response to problematic direct play playback. Link to comment Share on other sites More sharing options...
Luke 37249 Posted August 14, 2017 Share Posted August 14, 2017 That assumes the player triggers an error because in some situations they don't. Can you provide the contents of the chrome console? In addition I would suggest updating to the latest version of Emby Server. Thanks. Link to comment Share on other sites More sharing options...
adam1010 19 Posted August 14, 2017 Author Share Posted August 14, 2017 You're saying the Javascript code has no way of knowing there were 60,000 failed attempts so it can intervene? Attached is the Javascript console output. I ran it for a few minutes so there were over 10,000 failed requests (but nothing was logged in the console after the initial loading). Log: emby-chrome-log.txt Link to comment Share on other sites More sharing options...
Luke 37249 Posted August 14, 2017 Share Posted August 14, 2017 You're saying the Javascript code has no way of knowing there were 60,000 failed attempts so it can intervene? If that is really the full contents of your chrome console then yes maybe. When the player reports an error it gets logged to the console, which as you can see is not happening here. Link to comment Share on other sites More sharing options...
Luke 37249 Posted August 14, 2017 Share Posted August 14, 2017 What happens if you lower your in-app bitrate setting so that it transcodes? Link to comment Share on other sites More sharing options...
adam1010 19 Posted August 14, 2017 Author Share Posted August 14, 2017 If I lower the in-app bitrate (by going into another working movie first and lowering it -- since I can't access the controls for the problematic movie), it plays great. Attached is the console output for that: Log: emby-web-transcode.log Link to comment Share on other sites More sharing options...
Luke 37249 Posted August 14, 2017 Share Posted August 14, 2017 What about another browser for comparison? Link to comment Share on other sites More sharing options...
adam1010 19 Posted August 14, 2017 Author Share Posted August 14, 2017 Firefox has no problem playing it in Direct Play or with Transcoding. So it would appear the movie file is corrupt just a tiny amount in a way that Chrome isn't equipped to handle. Does it make sense to add any safeguards on the server-side to keep a rouge/malfunctioning app from DoSing the server with 10,000 requests per minute? I'm assuming if you responded with an HTTP 429 Too Many Requests the <video> player would stop pummeling the server. Link to comment Share on other sites More sharing options...
Luke 37249 Posted August 14, 2017 Share Posted August 14, 2017 That might make sense although I'd want to see more occurrences before investing the time for that. Also is only one example. If you try hard enough you can probably find another failure that makes the video player react in some other way, quite possibly in a fashion that can't be detected by either client or server. So at some point you just have to go to the source and report it to chromium. Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now