(2013-07-20, 20:20)caspbk Wrote: I think you will be right to skip the m3u and serve directly the media file.
The files that didn't stream, I think were some old avis that probably weren't optimized for streaming anyway.
AVI files should stream successfully, but seeking will produce some major artifacts until the video hits the next I-frame (a frame that contains the full picture). I think that's just the way the AVI container works.
I'll have to do some additional coding before introducing backend-agnostic settings but I'll definitely add an option for streaming the file directly (will most likely default to true).
caspkb Wrote:One idea to hide the real path from the clients would be to create a hash of that path at the time you prepare the html page, cache it with the corresponding path, then send the hash to the client. When the client requests the image, you lookup the hash and fetch the image for resizing and caching before you send it to the client. If you use urls without query strings and you also send the right caching headers to the client, this would also avoid the extra redirection step you are using now to fetch the cached image. I'm not sure, but it looks like what Yatse is doing. Another thing you could do is to start resizing and cacheing the images in the background, before the client requests them.
The image caching right now works quite like you described (ie. the image is hashed and if there's a cached copy that one is served, instead of resizing the original every time). Right now the resizing and caching is done in the same method that returns the URL to the image, that's why I've been using a separate URL which does a permanent redirect to the cached/on-the-fly-generated image. I see now that the 301 redirect doesn't help, I'll need to refactor the thumbnail URL/caching logic a bit.
I also looked into speeding up the resizing process (that's what's taking a long time the first time a thumbnail is rendered), although most methods I've come across are pretty hacky.
caspkb Wrote:Your project being pure html, has a more general scope and is very interesting. For a true comparison, your php code should have been running on a different machine than the xbmc, but I don't have any Linux rigs other than the pi to play with. If I find some time I'll try to use IIS to run your php app. In any case, the problem didn't seem to be this, and I believe there is a lot of room for optimization.
I've done all development on a machine other than the one that runs XBMC, albeit on the same local network so the difference is negliable. I haven't tried running the thing on IIS myself (it doesn't work out of the box due to a dependency on mod_rewrite, which is an Apache thing). Zag tried it brieflyt earlier in the thread but haven't posted back since so I don't know how it went.
I could get rid of the mod_rewrite dependency all-together at the expense of uglier looking URLs, but the image caching is still done using .htaccess files, so to me full IIS compatibility is not that high of a priority.
You can easily install it in a virtual machine if you want to try it out on something more powerful than the Pi.
caspkb Wrote:Keep up the good work.
Thanks!
bdk0 Wrote:bMovies aTV Shows eBackends fUsers cLog out
NEXT LINE
Movies
NEXT LINE
Name Gender Year Quality .......... and so on.
Sorry I do not see a large "Watch" button.
There should be a grid of all movies in your library. If you have no movies there will be a red box saying "No results found". You have to click a movie in order to bring up a "movie details" page, the Watch button is on that page.
