a main problem with the wuala project as whole is, that there is far too little information on technical details, far too little documentation and real information given by the developers.
people often wonder why the wuala software behaves this or the other way, search for solutions that are sometimes no real problems if the behaviour would be properly documented.
i started up some older build (winxp) wuala client after a while of downtime and it upgraded itself.
after logging in to the wuala network (username) the wuala client now works heavily on the wuala database files in probably reoganisation tasks (fragmentsxx.db and COMP-fragmentsxx.db files being messed with the whole time)
anyways so it literally took ages for this client to finish, and the connection status icon was yellow all the time. only after a long while, and when finally the insane diskactivity has finished, the connection status icon went green again.
ctrl+alt+d _shownetworkstats displayed that it wasnt connected to any supernodes during this period, hence the yellow icon i presume.
what makes me wonder if this is a neccessary behviour, that the client cant properly connect to the network until its finished with its database overhaul. maybe some multithreading designs could help, or maybe its just really the need to bring the database into a consistant and up-to-date state again before being able to add and fetch chunks of data again to and from it.
it would really be great if the wuala team could document its piece of software much more in detail.
lately i get a lot of these errors in the about dialobox (win32, latest builds) on networks with upnp routers when wuala client wants to check if theres a newer build out there...
if i close logout/restart wuala it downloads the latest build anyways even if the check in the about box failed.
would be great if the checking for a new build would be more reliable (maybe other protocol, triggering it directly with a button or a url and so on....)
maybe it has also to do with congested networks (even the local lan or the gateway to the inet), or nat-overloads at the gateway or such thing.
somehow i suspect that the versioncheck is also performed by means of udp rather than a tcp check of a browsing of some url/xml/file because the failed message turns up so very quickly/instantly on the client... there seems to be no timeout or something.
Loading Profile...
