I have no idea how that is possible..
I built shaman and tried it for the first time (looks pretty cool btw, package browsing in a gui is nice), and I don't know, the download progress seemed to work.
So how could it work if file_total was not set correctly? I think it is fine here.
Or probably you need to explain how to reproduce the problem :)

Also, does pacman work for you?

The situation is a bit more complex...
Total progress works since I'm using the new totaldownload callback for it. What is wrong is the single file download.
If you try downloading a package, I always get 0KB as total size, that is exactly what file_total returns. I have attached a screenshot, where you can see what's the problem. Pacman seems to work correctly.

Does this have anything to do with  FS#11339 ?
Have a look at the git commit log of the patch I posted there.

The totaldownload callback is not always called, it is only called when it is useful (when several files are downloaded in a row). So you should just handle the case where list_total == 0 just like the case where totaldownload is disabled (having a look at my patch will help there too).

There is still one thing not clear. totaldownload should always be set for the packages downloading of a -S operation. So what is exactly happening in the screenshot, is it a -S operation too, or something else?

No, it is not related, I probably wasn't clear.
Totaldownload works like a charm, and I use it for drawing the progress bar, hence the total percentage. The problem is that every file I download has a total size of 0, as you can see in the screenshot when you see "6000KB of 0KB". In the screenshot is happening the equivalent of an -Su operation.
I had to perform a small hack to make the progressbar behave correctly (you can have a look at callbacks.cpp) since I couldn't get the total file size of a single package, this is why it works.
Thanks for the quick help anyway!

I can't see which small hack you had to make, is it in the last release?
Otherwise, the svn browser is not available here : http://shaman-arch.svn.sourceforge.net/viewvc/shaman-arch/

My suggestion would be to build your own copy of libalpm, where you can add debug statements, in the section where file_total is computed (ust.size which is set by libdownload), and just before the dlcb calls are made, in lib/libalpm/dload.c

We really need to figure out what is wrong here.

Yeah, it's in the last release, I had to do it to make list_xfered work properly, and it's:

if ( last_file_xfered > file_xfered )
last_file_xfered = 0;

list_xfered += file_xfered - last_file_xfered;
last_file_xfered = file_xfered;

You're right, I'll try to do what you say and if something's wrong I'll send you a patch, thanks!

Ok, the thing is getting pretty absurd here... I've checked, and libalpm actually sets correctly ust.size, though it always passes 0 as a parameter. I've also tried to change its type to int instead of off_t, nothing. It really looks like the value gets lost when calling the callback, and I really don't know where to crash my head. I've also tried to use it inside an extern "C" { }, but nothing

I've tried it in Tribe, and works... the funny thing is that callbacks are called the same way... not a bug in alpm, I'll spot it out myself. Thanks anyway!

Have you tried debugging this with gdb and a version of libalpm with debut symbols?