I have not been able to work on my localcast app for quite some time because I have been busy with school, work, and greek life stuff. The app has had a problem for quite a while that I couldn’t figure out. The issue has been two-fold; on a server with low RAM, the server process would be killed by the system while trying to serve some large files, and secondly, if the ChromeCast being streamed to is in a crowded wireless space (i.e. my apartment complex) the stream would take a long time to start, if ever.
I thought at first the issue was simply the crowded wireless bands, so I shifted my AP around to different channels to alleviate that facet of it. This was not the only source of problems however. I decided I would run a monitoring session on my server with low RAM (it only has about 768MB) and watch what happens when I tried to stream a blu-ray quality sized file of ~1.5GB. I immediately saw the problem. I had been using Tornado’s built-in StaticFileHandler class to serve the media. However, this class does not stream at all! It actually reads the entire file into memory, then attempts to send it. The process kept getting killed because my RAM filled up, then most of the swap space, and finally the kernel killed the process because the resource usage was so high. It all made sense. I had previously written a chunked file download procedure in C++ for work and decided I could use the same methodology to solve this problem. Before I attempted to write anything, I Googled the issue, and found that at least one other developer had this same problem and already found a clever way to solve it using HTTP request range headers. The StaticFileHandler generates the chunks as requested by the HTTP request range header, but simply holds on to the whole thing. This developer cleverly inserted a yield from the iterator, allowing the chunks to be written and returned before the entire was read from the filesystem. I looked over the code and it works flawlessly! I implemented this in the localcast app and set the handler for the media to this modified StaticFileHandler. Now, a large file request doesn’t eat up the RAM and swap, begins to write chunks immediately, and will stream within a few seconds, even in crowded wireless space. I’d like to try it in a less crowded wireless space and see how it works now in comparison. Overall, I believe this is a good solution.
As for other localcast updates, I am working on a queuing mechanism so as to allow a user to queue up multiple media items and have them auto-play (as a good queuing system should!). I also want to implement a search mechanism for large libraries.
