In my opinion, these problems are home-made, anyway.
Lieven is a very zealous person, and thus, he puts this unnecessary pressure upon himself to provide a fresh build every day, almost accurate to the minute. He even posts a note of absence in case he has to go abroad due to business! Few projects have such a dedicated packager.
If it was me, I would offer one or two builds per week, and maybe an extra build if something revolutionary has been added, and that would be it.
This would not cause anybody to miss out on anything, really. It would mean a lot less work, and a lot less trouble if the server doesn't work for a while. If you are not committed to release every evening, then what's the matter if you upload the build the next day...
It would also mean less revision fuzz and forum noise for each and every subtle bug or tiny feature that may be occurring in one particular build.
Most projects publish snapshots a lot less often than that, and people are fine, it is no problem at all.
Contrarily, it greatly reduces the amount of bandwidth people spend on downloading things they don't really need. Most commits are useful to only a small subset of users, so fewer releases (with more commits in each) have features for a broader user base.
Regarding Sourceforge, while there are no plans to ever turn back to them, we might use it as an inofficial backup site both for downloads and anonymous Subversion access in the future. The web updating system will thus be able to balance the load between the two sites and offer redundancy.
However, while the Subversion repository can be trivially mirrored as an automated process (cron.hourly), this will be virtually impossible for the upcoming daily diffs, as files have to be "activated" by hand after uploading. It might work out well for the weekly/bi-weekly snapshots, though.