MeGUI auto-update issues: Excedeed bandwidth

[Sharktooth]

If you have problems updating megui that's why the webserver replies with:
Bandwidth Limit Exceeded
The server is temporarily unable to service your request due to the site owner reaching his/her bandwidth limit. Please try again later.

[Xorcist]

I was eager to try this today, and unlucky that auto-update didn't work today. Does someone have a pack with the needed applications so I can easily install them manually?

[Xorcist]

I was eager to try this today, and unlucky that auto-update didn't work today. Does someone have a pack with the needed applications so I can easily install them manually?

Nevermind, I was able to find everything I needed and I'm encoding now.

[bob0r]

time for http://files.x264.nl/megui/ :)

[Richard Berg]

It should be up now.

What is the usage pattern like? Does the autoupdate know to only download binaries when new one are posted? I ask because megui.org did 100GB of transfer last month with fewer than 20K unique visitors.

[Sharktooth]

yes, megui donwloads only updated files.
we have tons of users though...

[ChronoCross]

Megui Core == 1MB approx

1MB x20k users = 20,000MB == 20GB

20GB x 4 updates a month == 100GB

That also doesn't include external files that it updates.

[Doom9]

I think we ought to limit the tools it downloads though. E.g. most people don't care about lmp4/snow, so that's a 9mb download right there that they don't need. Then ac3 audio encoding.. also a rather rare case imho.. so another 2 megs.. and the list could go on.

[berrinam]

Wow! 20k users....
Well, I suppose we need to support more servers and a versioning system to detect the versions of files.

Also, the refactor which I've committed, when combined with dynamic loading of packages (which is a trivial increment from the current system, I've discovered) should mean that each package is individually much smaller, and it should therefore (hopefully) reduce the size of the core.

[check]

My webserver is always available for traffic if required - I'd be happy to supply 100gb/month. If needed, perhaps a random mirror selection system could be created? This is done with the CCCP to split up around 2-2.5tb/month between 10 or so mirrors.

[Richard Berg]

Ok -- let me know whatever you decide. I can redirect megui.org to other server(s) or transfer the domain if necessary. I've got things configured so 100GB won't trip the limit anymore, but if things get too much bigger I'd rather save bandwidth for my main websites (Avisynth.org & Richardberg.net).

[Sharktooth]

random mirrors and synchronization could be a problem...

[ChronoCross]

my domain has unlimited transfer per month. I could pump a TB if needed. Soon I'll have my very own server which I could setup entire domains on including megui.org if you guys are interested. (same unlimited transfer as well as email mySQL all that good stuff)

[berrinam]

Thanks for the offers of hosting. I think the solution we should do for the short term is this: use random mirrors which are set to automatically mirror a central mirror (say, ChronoCross's which has the most bandwidth). This way, the random mirrors should be in sync. For extra certainty, the upgrade.xml file should also include a last-modified flag on it, so using an old server doesn't force the user to downgrade.

[Doom9]

well.. if you push out updates rather than to have servers synch from their own end, you get pretty good control over the updates. I've been doing that for years with the server.. the only part missing from the script is sending an email to let you know if a synch has failed.

[check]

update pushing would be reasonably easy - just require all mirrors to give you an ftp account and you can setup a script to push the content to the mirrors.

[berrinam]

Sure, ok.