LGOGDownloader 1.13
- Use asLargestUInt() instead of asUInt64() to avoid problems if jsoncpp isn't compiled with Int64 suppport
- Progressbar now takes into account previously downloaded parts
- Don't add trailing slash when creating subdirectories: for some reason boost::filesystem::create_directories() returns false even though directories were successfully created
- Include path for rhash changed from <rhash/rhash.h> to <rhash.h>. Fixes compiling with rhash 1.2.10
* If you have older version of rhash you need revert this change in include/util.h or update to 1.2.10

http://sites.google.com/site/gogdownloader/lgogdownloader-1.13.tar.gz

Ubuntu users can get rhash 1.2.10 from this ppa [url=https://launchpad.net/~sbasalaev/+archive/pub]https://launchpad.net/~sbasalaev/+archive/pub[/url]
Debian users can get it from experimental

i still had to alter asLargestUInt() to asUInt() to get compilation, must be an idiosyncracy of my mageia2 distro:) and as you pointed out i had to revert the rhash change.

sadly i still have the problem with the i586 compile, it lists games but when downloading it will stop at the first file, where it used to just have nan% and an empty progress bar it now lists the full size of the first file and the progress bar is full but never progresses beyond that:

[diziet@localhost lgogdownloader-1.13]$ ./bin/Release/lgogdownloader --download --directory /data/common_stuff/file_store/games/goodoldgames/ --create-xml automatic --xml-directory /data/common_stuff/lgogdownloader/xml/
Getting game info 66 / 66
Cover image (cover_0.jpg) already exists
Cover image (cover_1.png) already exists
/data/common_stuff/file_store/games/goodoldgames/the_7th_guest/setup_t7g.exe
100% [==========================] 598.06/598.06MB @ 0.00kB/s

and that's where it sits till i ctrl-c

diziet

Try changing CFLAGS in Makefile to
CFLAGS = -std=c++0x -Wall
and CFLAGS_RELEASE to
CFLAGS_RELEASE = $(CFLAGS) -O0

I think I'll install Mageia 2 in virtual machine later and try to figure out why this happens

Actually I meant rhash 1.2.10 can be gotten from experimental
I haven't done packaging for the downloader on Debian because I have no idea how to do that. Also I just recently switched to Arch so I don't use Debian currently.

LGOGDownloader 1.14
- Make downloader backwards compatible with JsonCpp 0.5.0

http://sites.google.com/site/gogdownloader/lgogdownloader-1.14.tar.gz

hi sude, i tried this and it made no difference, is there any other info i can give you to help?

diziet

First run, using 1.14 in Arch Linux, it tries to create ~/.lgogdownloader/xml/ when ~/.lgogdownloader doesn't exist yet:

goodt60:[~/builds/lgogdownloader]% lgogdownloader
Failed to create directory: "/home/stephen/.gogdownloader/xml/"
goodt60:[~/builds/lgogdownloader]% mkdir .gogdownloader
goodt60:[~/builds/lgogdownloader]% lgogdownloader

after that it seems to work.

---
Edit: I'm also getting the nan% progress bar on any download attempt.

Trailing slash issue with boost filesystem. I forgot to change that for the xml directory when I fixed the other trailing slash issues in 1.13. I'll fix this in the next version.

Is this 32-bit system? I was able to reproduce this on 32-bit Arch.
Currently I have no idea what causes this. For some reason curl seems to stop before the write callback function.

Somehow missed this til now. Thanks a lot, Sude.

Yes it is 32-bit.

LGOGDownloader 1.15
- Fix error on creating ~/.gogdownloader/xml directory
- Possible fix for download issue on 32-bit systems

http://sites.google.com/site/gogdownloader/lgogdownloader-1.15.tar.gz

It seems that CURLOPT_MAX_RECV_SPEED_LARGE causes problems on 32-bit
Removing download speed limiting feature on 32-bit system seems to fix the download issue, at least on Arch Linux

well this is now working for me on 32bit mageia2 :)

just fyi a couple of unimportant cosmetic things regarding the progress bar, while testing just now and getting the download of my most recent purchase i see that every now and then the progress bar looks like this:
99% [==========================] 0.04/0.04MB @ -nankB/s
instead of saying 100% at the beginning, however this is for files already downloaded so it ought really be 100% :)
also note the: @ -nankB/s , every now and then it does say:
@ 0.00kB/s
but mostly @ -nankB/s,
however these don't affect the downloading function so like i said, cosmetic,

thankyou for working on this for us 32bit folk!

diziet

Good feature to add would be an ETA indicator.

I think I found a bug in your code. When you output progress in src/curlhandle.cpp you do this: http://pastie.org/6002885

Rate is calculated as:

double rate = dlnow/(time_now - time_start)/1024; // average download speed in kB/

This is wrong in case when you are resuming, since dlnow is the amount of downloaded data from all attempts together, and not the amount that you downloaded from the moment of the last resume, while time delta is taken from the starting of the last resume till now).

UPDATE: I made a patch for it, as well as added an ETA indicator: http://pastie.org/6005556

It added a dependency on libboost_date_time, but I figured that you already use a bunch of boost libs, so that shouldn't be too heavy (otherwise you can just calculate stuff manually). Clearing the current line is a bit hackish using the vt100 ANSI escape sequence: \033[0K but otherwise some garbage can remain on the line, since \r doesn't clean the line - it only moves the cursor. I know it's not ideal, but if you want a purely portable solution, you'll have to use ncurses or something.

Another note: I see you pass lot's of strings by value in src/api.cpp (like std::string getResponse(std::string) and etc.). I didn't go through that part - may be they are rarely called, but passing strings by value is generally not a good idea, unless it was indented.

Thanks.
I had some code for the ETA where I calculated it manually and it was a mess. Using libboost_date_time looks like much better option.
I tried clearing the line by few other means but they were even more hacky than the escape sequence and just made the code a huge mess. So using the escape sequence is the better option for the moment. If someone encounters a problem because of it then I guess I'll have to look for better solution.


LGOGDownloader 1.16
- New dependency: libboost-date-time
- Merged the patch by shmerl
- shmerl: Added ETA indicator to progressbar
- shmerl: Fixed download rate calculation
- Pass strings to functions by reference instead of value
- Added HTTP::getFreeGames() function to get list of free games (not used currently)
- Some cosmetic changes to code

http://sites.google.com/site/gogdownloader/lgogdownloader-1.16.tar.gz

Sude: I'm working on a nicer progress bar for it, but I observe a weird behavior with libcurl. When file is fully downloaded and it's resuming and int progress_callback(void *clientp, double dltotal, double dlnow, double ultotal, double ulnow) is called, I always get dltotal as 389.0 and dlnow as 0.0. What is this 389.0 about? I expect them both to be 0.0 at that point. You can add some basic debug output to observe that (when it downloads straight - it's OK, but when resuming a fully downloaded file - things go weird). What do you think it is?

UPDATE: Created a patch: http://pastie.org/6077909

* Switched the rate from calculating it manually to simply getting it from curl_easy_getinfo. Curl happens already to calculate rate by itself.
* Introduced Unicode progress bar. Most terminals used these days support Unicode so it makes sense to make it a default. --no-unicode option allows switching ASCII style simple progress bar back.
* Moved the config to shared_ptr in order to pass it around (callback needs it).
* Had to use a workaround to detect the case of (dlnow == 0.0) && (dltotal == 389.0) otherwise the progress bar will be missing the very last small part. I'm not sure - may be it's specific to my version of curl, you can switch on the debug line mentioned there and see if this bug surfaces for you or not.

Note: found a bug in case of downloading covers - files aren't resumed even if they were downloaded only partially (didn't fix that).

This can be the same bug that I encountered with dltotal being 389.0. See above.