Attempt #3: You are right, the client is certifiably *bad*.
Firebug didn't catch the plugin traffic, so I took a peak at it with Charles and this is the request it made: *Video URL* Host 127.0.0.1:8000 Accept-Encoding identity;q=1, *;q=0 User-Agent Mozilla/5.0 (Windows NT 6.0; WOW64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11 Accept */* Referer http://127.0.0.1:8000/Localflix/default/Watch_content?Content_description=Feature+Film&Content_id=16&Content_player=Browser&Content_type=video%2Fmp4&Movie=12 Accept-Language en-US,en;q=0.8 Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.3 Cookie session_id_localflix=127.0.0.1-13bc123d-819b-45f3-a718-f523df3cd8a1 Range bytes=0- So, basically, it requested the entire movie. But then, the server was not that great either, because it proceeded to announce partial content, but streamed the entire movie anyways: HTTP/1.1 206 PARTIAL CONTENT Content-Length 1014959100 X-Powered-By web2py Set-Cookie session_id_localflix=127.0.0.1-13bc123d-819b-45f3-a718-f523df3cd8a1; Path=/ Last-Modified Sat, 29 Dec 2012 02:42:54 GMT Content-Range bytes 0-1014959099/1014959100 Pragma cache Cache-Control private Content-Type video/mp4 Date Mon, 31 Dec 2012 21:50:53 GMT Server Rocket 1.2.5 Python/2.6.2 Connection keep-alive Maybe I'll try to modify it so that it replies with an actual range and see how the client handles that. On an unrelated note, there was also a problem with the non-html5 video plugins, because my stream urls don't include a video type, so they didn't know what content to ask for (and asked for html/xml). Guess I'll just stick a dummy video extension at the end of the url so that they can figure out what file type to expect. HTML5 doesn't have that problem, because you can specific the type as an attribute for the video tag, which is definitely a major step forward. On Sunday, 30 December 2012 16:09:30 UTC-5, Massimo Di Pierro wrote: > > There are different issues with streaming. > > web2py supportes https streaming, if modified since, and range requests. > This means that if the client is smart enough it will cache previously > downloaded data and will request data in chunks (range requests) which will > then be streamed by the server. > > Server side this is robust but there are things that can go wrong. If the > client makes a request, does not stream in data, but does not close the > connection, the web2py thread is wasted/idle until killed by the web > server. You have some parameters you can play with (min/max number of > threads, time before they get killed, response.stream(chunk_size=...)). > > With an async server (like node.js) you do not have to worry about loss of > resources when a connection is open and the client is idle. > > Massimo > > > > On Sunday, 30 December 2012 14:32:44 UTC-6, Magnitus wrote: >> >> I am currently in the process of writing a netflix/youtube-like app that >> allows you stream movies on your local LAN (eventually, perhaps over the >> internet even, but that is not an immediate priority, especially given my >> limited data transfer allowance by my ISP) using a web interface. >> >> I am writing this mostly for personal use as a spare time project, but >> intent to release the code over some Creative Commons when done. >> >> However, I encountered a massive roadblock with Web2py. Streaming large >> video files (over 1GB) is painfully slow (sometimes, the movie doesn't load >> at all and either way, the framework doesn't recover from attempting to >> stream such a file in a graceful manner when the user aborts by clicking >> back in the browser window). >> >> At this point, I'm not sure if it's because of the Framework itself or >> the underlying server. >> >> I tried with both Rocket and Tornado to no avail. I was tempted to try >> with Apache, but then thought that if I wanted to make the app available >> for regular Joes to use, that might not be the most user-friendly way to >> distribute it. >> >> I tried with various client-side technologies (in-browser video with >> html5, VLC plugin, embeded DivX player, embedded WMP) to no avail. >> >> Then, just for kicks, I picked up a Node.js introductory book (Learning >> Node by O'Reilly) which I'm in the process of reading and tried their >> streaming example with a large video file and it worked a lot better. >> >> At this point, I'm tempted to use web2py for most of the app, but >> delegate video streaming to node (they can communicate via the database >> and/or sockets). >> >> Am I crazy or does my idea make sense? >> > --
