On shared hosting it is not possible to increase max_file_upload and max_execution_time to very large values.
Is there a way to upload files via FTP and then index them in the Media-Library? (each user should have a private directory on the Server)
(A good solution from other CMS is the possibility to “upload files form server” or via URL and a “Browser Server”-Button.)
You can upload via the API. If you’re of a technical nature there’s a working Python command line upload tool here:
http://bazaar.launchpad.net/~alexharrington/xibo/140-rc1-upload/files/head:/apps/MediaUpload/
The GUI version was never implemented so don’t expect that to work.
For details of how to get it setup/configured you can work from the guide on API access which uses the same Python libraries to connect to the CMS:
Other than that no it’s not possible to add files to the CMS by FTP or any other means. Xibo doesn’t run well on shared hosting, precisely because you often can’t make the changes required to support it, or because it consumes too many resources and the hosting provider disables your account as a result.
Ok, Thank you very much!
Some time ago i have tested the file upload with python. But that’s not the solution i am looking for.
There should be a way for “normal” people 
Sorry, that is not correct. I am running xibo on shared hosting, i have no other problems and my provider does a great job. Please don’t tell me something like that 
my provider would never disable the account (i don’t know what provider you are talking about) and i have big systems running there…
Nervermind, if xibo does not support that it is ok.
I’m sorry but your question supports my argument. You indeed can’t make the changes Xibo needs to support large file uploads, therefore the hosting you’re using isn’t suitable for it.
Yes I’m making a generalisation about shared hosting, but in our experience we hear from lots of people who have their shared hosting accounts disabled for using too much CPU time/too many MySQL queries etc when hosting Xibo on low end shared hosting accounts. If your provider is the exception then that’s great. Hopefully they’ll also allow you to make the changes Xibo needs to support large file uploads.
I’ve logged it as a Feature request here:
Hopefully someone will feel like taking that on as a project.
No, in my opinion, xibo is the problem! Other CMS have the “Browse Server” functionality.
There are solutions for uploading chunks. For example http://stackoverflow.com/questions/16102809/how-to-upload-large-files-above-500mb-in-php or maybe http://www.plupload.com/
Now I am interested: Why do you think xibo is more CPU intensive oder has more queries than a big drupal-system?
FYI: I have a server and I am hosting-reseller too, so that is really important for me if you say i will have other problems with xibo (cpu/db/etc)
Xibo is using jquery-file-upload.
I don’t know, maybe it is possible to implement chunked file uploads:
When you start to have large numbers of clients connected to the CMS, the resources required goes up significantly. I wouldn’t recommend reselling hosting on shared hosting.
You will have run some simulations I’m sure to identify how much load x number of Players will generate on your servers so if you think your current provision is suitable then I’m sure it will be.
The reason Xibo is heavier on a system than say Drupal is that CMSes like Drupal are easy to cache. Xibo is highly dynamic so it’s not possible (or at least we don’t yet) cache the responses to the requests the Players make, which means each and every connection from the Player requires access to PHP stack, disk, processor and in most cases MySQL. Something like Drupal or Wordpress will be caching those responses to flat html files and serving those direct from disk, and therefore bypassing the overhead of the whole PHP stack, connection to the database etc
Allowing users to browse the servers filesystem is a massive risk. It would have to be filtered to prevent users from uploading arbritrary files (eg /etc/passwd on a Linux server) and any time you do string filtering you open a new potential security hole.
It might be possible to support chunked uploads with the tool you suggest, however in my opinion if you’re uploading multi-gigabyte files then it’s better to do those chunked uploads with a client application which can support things like resuming failed uploads, throttling speed etc
Thank you very much for the information and taking the time.
Unfortunately i see it completely different.
Maybe I will implement myself an do some tests.
If you can make chunked uploads work in a reliable fashion (and with failback for browsers that don’t support it) then a pull request in GitHub with the changes would be much appreciated.
The handler in the CMS should support it already, you’d just need to enable the option in the client side JS. If you do implement and test a pull request would be appreciated!
We are only offering an opinion of course, in the interests of being helpful and hoping to guide our users away from costly mistakes. We have been doing this a long time and we did write all of the code 
We are also open to new things of course! We are already taking some steps in 1.8 to finish the API and release it officially, with a PHP wrapper so that people can more easily build things like the item you want. And also to add more caching (where possible) to make Xibo lighter 
Yes sure. Better to ask first before doing something wrong I have now posted the patch.
And Xibo is great software, thank you for that and the good support!
For me and my hoster xibo is light enough 
Nice to hear that. As soon as there is the api i will test it (html5 player cordova).
(And for information: Drupal does not cache out of the box)
Great to hear it 
we do try!!
dear, my hosting supplier say me that is not possible to configure post_max_size and upload_max_size over a value of 100M, is it enough to install Cms and a good work of Xibo?
thanks
You won’t be able to upload files larger than 100 MB - only you can answer whether or not that is OK 