It seems that you're using an outdated browser. Some things may not work as they should (or don't work at all). We suggest you upgrade newer and better browser like: Chrome, Firefox, Internet Explorer or Opera

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

Sude: 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

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:

Thanks for fixing the progress indicator and packaging it to Debian, while I'm on testing, I'll build it from source for now :) (reverting to rhash/ rhash.h was needed as you mentioned, since I have 1.2.9). Keep up the good work!

diziet_sma: 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:

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

shmerl: Thanks for fixing the progress indicator and packaging it to Debian, while I'm on testing, I'll build it from source for now :) (reverting to rhash/ rhash.h was needed as you mentioned, since I have 1.2.9). Keep up the good work!

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.

diziet_sma: 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:

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,

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).

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.

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.

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.

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?

* 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).

diziet_sma: 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% :)

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