Kodi Community Forum

Full Version: XBMC Video Server: stream/download your library contents
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
(2013-07-18, 11:13)bernus Wrote: [ -> ]When I put this in my hosts file : 192.168.***.*** mydns, I can now see the Movies and TVShows !
Everything works great !

That's great!

bernus Wrote:For some movies, the button "download" is not available. Instead, I have "The file(s) for this item is not available". Why?

It means the file is not available on your hard drive, but the movie itself is still left in your library. Run "Clean library" from System -> Video to remove the movie. I believe it can also happen if the movie is on a harddrive that is not currently connected (or on a Samba share on a computer that is not reachable at the moment). I only have local media so I haven't been able to experiment with that.

bernus Wrote:Another question : Do someone know if it's possible to start the XBMC WebServer without starting XBMC ? Like a standalone service ?

Not really.

bernus Wrote:Or would it be possible to use XBMC Video Server connected to a XBMC Mysql database (I heard it was possible to use a Mysql database for XBMC)?

Yes, you can configure XBMC to use a MySQL database and this application will continue to work. This application will not work without XBMC's web server though so it's pointless to move your library to MySQL unless you need it for other reasons.
Thx for the answers.

The movie's file is on my drive. The "watch" button works, but dhe "download" button il not available.
I can start the movie from XBMC without any issue.

Too bad XBMC has to be launched for Video Server to work properly.

Bernus

edit : it might be a cache problem. If I press ctrl+F5 in my firefox, the "download" button appears
bernus Wrote:Another question : Do someone know if it's possible to start the XBMC WebServer without starting XBMC ? Like a standalone service ?



The closed you'll get right now is the headless approach..
(2013-07-19, 11:58)bernus Wrote: [ -> ]Thx for the answers.

The movie's file is on my drive. The "watch" button works, but dhe "download" button il not available.
I can start the movie from XBMC without any issue.

Too bad XBMC has to be launched for Video Server to work properly.

Bernus

edit : it might be a cache problem. If I press ctrl+F5 in my firefox, the "download" button appears

That's odd, I'll have to look into that.
As soon as I stumbled upon this project I had to try it on my raspberry pi media center (raspbmc), and share the experience.

I installed apache on the same 512MB v2 pi that hosts the master XBMC instance. Most videos are in usb drives local to the pi and some in samba network shares. Mysql proved to be too memory hungry for my pi, so I use the standard library for my fairly large collection of 4000+ videos. The paths, for both local and network files, are in samba form, because this library is shared with an XBMC instance on a Windows machine. This proved to be a security hole which I'll explain later.

Following the excellent instructions, the installation was smooth, and apache did not seem to burden my raspbmc too much. After changing the apache port and increasing the raspberry swapiness to 60, I was ready to try it. The web interface looks really good, but the pi is not strong enough to handle the internal streaming from XBMC to apache then to the client and it appears very sluggish, with images loading very slowly. The security hole I mentioned before is that the initial source of the images contains the samba path of the image in this form:

/xbmc-video-server/src/thumbnail/get?path=image%3A%2F%2Fsmb%253a%252f%252fuser%253apass%2540host%252fc%252fpath%252fvideo-thumb.jpg%2F&size=116&type=movie

which reveals the user name and password used to connect to the share. The images are then cached, and the above redirects to the cached image, which improves the speed a bit, but is probably not the best mechanism, imho. Also, some video details pages returned a division by zero error, probably due to some missing metadata.

I used my Windows laptop and Windows Media Player + KPLC as a client. I tried various types, avi, mp4, mkv, they all played, but some videos which stream fine, say in Android's Yatse, do not stream in this setup, i.e. they have to download entirely before they start playing. Others do stream ok although initial buffering is a lot slower (> 10x) than the one experienced with Yatse + MX Player using the same XBMC server/video. After this initial buffering, the videos played smoothly as long as their bitrate fitted the speed of the network.

Overall, the experience is that although usable for special cases, it's too slow for general use and you have to wait a lot before you can start the video. Although it is an interesting experiment, I think that a web interface for XBMC that exposes (safe) links to stream and/or download the videos/music would be a much better solution for most users.
caspbk Wrote:As soon as I stumbled upon this project I had to try it on my raspberry pi media center (raspbmc), and share the experience.

I installed apache on the same 512MB v2 pi that hosts the master XBMC instance. Most videos are in usb drives local to the pi and some in samba network shares. Mysql proved to be too memory hungry for my pi, so I use the standard library for my fairly large collection of 4000+ videos. The paths, for both local and network files, are in samba form, because this library is shared with an XBMC instance on a Windows machine. This proved to be a security hole which I'll explain later.

Following the excellent instructions, the installation was smooth, and apache did not seem to burden my raspbmc too much. After changing the apache port and increasing the raspberry swapiness to 60, I was ready to try it. The web interface looks really good, but the pi is not strong enough to handle the internal streaming from XBMC to apache then to the client and it appears very sluggish, with images loading very slowly.

The images that XBMC returns from its API are in original form, meaning some are quite large. The application resizes each image the first time it is displayed and caches one copy per resolution. The resizing step is a bit demanding, especially on a computer like the Raspberry Pi. The alternative is to load the images directly which is very slow over the internet (individual images can be hundred of kilobytes in size).

Edit: I forgot to mention that once an image has been displayed and resized it will be cached in your browser, so the next time you visit the page the images will just show up instantly without the server having to do anything.

caspbk Wrote:The security hole I mentioned before is that the initial source of the images contains the samba path of the image in this form:

/xbmc-video-server/src/thumbnail/get?path=image%3A%2F%2Fsmb%253a%252f%252fuser%253apass%2540host%252fc%252fpath%252fvideo-thumb.jpg%2F&size=116&type=movie

which reveals the user name and password used to connect to the share.

Edit: there's nothing can be done at the moment to prevent this. There is the "proxy location" setting that can hide the XBMC API credentials, but it won't do anything about smb:// paths. This is a problem with XBMC and not this application in particular. The "proxy location" setting only applies on vfs:// URLs at the moment, which is certainly something that could be improved.

caspbk Wrote:The images are then cached, and the above redirects to the cached image, which improves the speed a bit, but is probably not the best mechanism, imho.

Like I said, the alternative to resizing then caching the images isn't much better.

caspbk Wrote:Also, some video details pages returned a division by zero error, probably due to some missing metadata.

I'll look into that, thanks for mentioning!

caspbk Wrote:I used my Windows laptop and Windows Media Player + KPLC as a client. I tried various types, avi, mp4, mkv, they all played, but some videos which stream fine, say in Android's Yatse, do not stream in this setup, i.e. they have to download entirely before they start playing. Others do stream ok although initial buffering is a lot slower (> 10x) than the one experienced with Yatse + MX Player using the same XBMC server/video. After this initial buffering, the videos played smoothly as long as their bitrate fitted the speed of the network.

Did you try VLC? I have not had much luck with any other player, including MPC-HC (especially not WMP, although I think it was a codec issue). I think I'll change the URL for the "Watch" button so it points directly to the video in question (not a playlist) if there's only one file, that could hopefully increase compatibility a bit.

Could you try to pin-point what kind of media require you to download the whole file before watching? I haven't experienced that issue at all myself.

caspbk Wrote:Overall, the experience is that although usable for special cases, it's too slow for general use and you have to wait a lot before you can start the video. Although it is an interesting experiment, I think that a web interface for XBMC that exposes (safe) links to stream and/or download the videos/music would be a much better solution for most users.

I'm sorry to hear that the Raspberry Pi is too slow generally. I haven't done that much in the way of optimization on the whole application yet ("premature optimization is evil" etc.) but there are certainly a few areas I know could be improved.
Hello,

Running Xubuntu,followed the install at https://github.com/Jalle19/xbmc-video-server.

In Xbmc go to System>Services>Webserver setup. In Web client adress bar http://localhost/xbmc-video-server.

Loged in and verything seems to be connected no error messages.

How do I use this to download a movie or a stream, a simple tutorial on how to use.

Thank you.
You click a movie and there is a large "Watch" button and download link(s) under the poster. I really thought it couldn't be any simpler.
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.

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 reason I mention Yatse (or XBMC remote) is because they are Android clients very similar to what you are trying to do in html. They connect to the web interface of an xbmc instance, fetch the info and images and are able to stream media to the client (both using some kind of plugin). They both cache resized images locally and they are much faster, with yatse being the fastest on the few machines I tried. Initial buffering takes only a few seconds, instead of the 3-4 minutes I got with the pi setup.

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.

Keep up the good work.
Negge thank you for a prompt reply.

"You click a movie and there is a large "Watch" button and download link(s) under the poster"

Where exactly is this large "Watch" button? Is it in Xbmc?

In web address page localhost/xbmc-video-server/src/ I have the following choices;

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.

Thank you.
I still haven't been able to seek in videos without buffering the whole thing. Anyone else experiencing this?
(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.
@caspkb: I've changed the way thumbnails are loaded slightly. It now links directly to the cached image if one exists instead of always requiring a redirect. The internal thumbnail path is still passed around in the URLs, I'm still contemplating different ways to deal with that. I also hopefully fixed the division by zero errors you'd been seeing, would you mind upgrading and trying again? You can find upgrade instructions in the readme.
@caspkb: there's an option for linking directly to single-file movies now, although I left the old behavior as default since at least Firefox wants to download the whole file if I choose to open with VLC (I have to right-click the link and open it manually from VLC).
@bzellinger and everyone else who have been having seeking issues. I just realized that seeking support is a brand new feature available in the nightly builds only. Guess I should have noticed sooner but I switched to Gotham myself a few weeks before starting developing this. I've updated the first post to reflect this.

There's also a new screenshot of the settings page.