If the server returns partial content it is because the server made a range request. Something is wrong. Probably in the client. But you find out more, please let us know.
On Monday, 31 December 2012 21:53:49 UTC-6, Magnitus wrote: > > Attempt #4: > > You are right, the client is no good. > > Firebug didn't catch the plugin traffic, so I took a peak at it with > Charles and noticed that it made a request with Range as 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. > > 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? >>> >> --
