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

×
Community
General discussionLGOGDownloader - GOGDownloader for Linux(1458 posts)(1458 posts)
(1458 posts)
Pages:
1
10
17
18
19
20
21
30
40
50
60
70
80
90
98
This is my favourite topic
Posted February 25, 2014
avatar
shmerl: @ashwinm: It's probably good to file this as a bug / feature request on github (while commenting here about the issue) just to keep track of this.
Thanks shmerl, I've submitted this issue: https://github.com/Sude-/lgogdownloader/issues/9
Post edited February 26, 2014 by ashwinm
Posted February 26, 2014
avatar
ashwinm: ...
This should now be fixed in current Git

edit: There was a wrong condition for deletion earlier in Git. Sorry about that. 8115e59 should fix this issue.
Post edited February 26, 2014 by Sude
Posted February 26, 2014
avatar
ashwinm: ...
avatar
Sude: This should now be fixed in current Git

edit: There was a wrong condition for deletion earlier in Git. Sorry about that. 8115e59 should fix this issue.
Thanks! I've cloned the repo and am trying the GOG download now. Sadly, my net speed seems to be good today, so I haven't seen the partial download problem yet :-) I'll let you know if it's fixed.
Post edited February 26, 2014 by ashwinm
Posted February 27, 2014
avatar
Sude: That's intended behavior. Because there's no way of repairing covers the downloader ignores them.

Here's a patch to allow --repair download covers
https://sites.google.com/site/gogdownloader/repair_downloads_covers.diff
Hm, this patch doesn't work.
I've tried repairing twice. First time:
Getting game info 1 / 1
Downloading cover syndicate_wars/cover_0.png
100% ▕██████████████████████████▏ 2.21/2.21MB @ 826.78kB/s ETA: 0s
Downloading cover syndicate_wars/cover_1.png
100% ▕██████████████████████████▏ 1.75/1.75MB @ 423.98kB/s ETA: 0s
...
Second time:
Getting game info 1 / 1
Downloading cover syndicate_wars/cover_0.png
50% ▕█████████████ ▏ 2.21/4.42MB @ 0.00kB/s ETA: 0s
Downloading cover syndicate_wars/cover_1.png
50% ▕█████████████ ▏ 1.75/3.49MB @ 0.00kB/s ETA: 0s

While it did accept the covers it had fetched the first time, it printed a download dialog with the wrong size for the files.
For a different game, second time:
Downloading cover battle_worlds_kronos/cover_0.png
99% ▕█████████████████████████▋▏ 2.29/2.32MB @ 0.00kB/s ETA: 0s

Does it depend on the file hoster?
If it's too much effort, I can live without the covers, no problem.

Btw, there's an integer overflow problem. Some games, like the_witcher_2, have files bigger than 4GB. The size is saved as a signed value and overflows:

<file name="the_witcher_2_redkit.zip" md5="acee3d250f283a30c87e15639448dde2" chunks="618" total_size="-2115021671">

which causes the lgdownloader to download the complete file again:

the_witcher_2_redkit.zip
MD5: acee3d250f283a30c87e15639448dde2
Chunks: 618
Size: 0 bytes

Filesizes don't match
Incomplete download or different version
Redownloading file
...
Post edited February 27, 2014 by Loenas
Posted February 27, 2014
avatar
Loenas: Hm, this patch doesn't work.
I've tried repairing twice. First time:
Getting game info 1 / 1
Downloading cover syndicate_wars/cover_0.png
100% ▕██████████████████████████▏ 2.21/2.21MB @ 826.78kB/s ETA: 0s
Downloading cover syndicate_wars/cover_1.png
100% ▕██████████████████████████▏ 1.75/1.75MB @ 423.98kB/s ETA: 0s
...
Second time:
Getting game info 1 / 1
Downloading cover syndicate_wars/cover_0.png
50% ▕█████████████ ▏ 2.21/4.42MB @ 0.00kB/s ETA: 0s
Downloading cover syndicate_wars/cover_1.png
50% ▕█████████████ ▏ 1.75/3.49MB @ 0.00kB/s ETA: 0s

While it did accept the covers it had fetched the first time, it printed a download dialog with the wrong size for the files.
For a different game, second time:
Downloading cover battle_worlds_kronos/cover_0.png
99% ▕█████████████████████████▋▏ 2.29/2.32MB @ 0.00kB/s ETA: 0s

Does it depend on the file hoster?
If it's too much effort, I can live without the covers, no problem.
It seems to depend on the file hoster. Though sometimes it works on file hosters that it previously didn't work.
Sometimes it shows the real filesize but other times it doubles the filesize, tries to download it and then fails with CURLE_RANGE_ERROR as it's trying to download invalid range. However CURLE_RANGE_ERROR is normal status/error code on resume attempt (resuming complete file will result in CURLE_RANGE_ERROR because CURLOPT_RESUME_FROM is set to the end of file) which makes detecting this problematic.

avatar
Loenas: Btw, there's an integer overflow problem. Some games, like the_witcher_2, have files bigger than 4GB. The size is saved as a signed value and overflows:

<file name="the_witcher_2_redkit.zip" md5="acee3d250f283a30c87e15639448dde2" chunks="618" total_size="-2115021671">

which causes the lgdownloader to download the complete file again:

the_witcher_2_redkit.zip
MD5: acee3d250f283a30c87e15639448dde2
Chunks: 618
Size: 0 bytes

Filesizes don't match
Incomplete download or different version
Redownloading file
...
Apparently tinyxml didn't handle size_t in TiXmlElement::SetAttribute and thus size_t was cast to int which caused it to overflow.
This is now fixed in d31613d
Posted February 27, 2014
avatar
Loenas: Btw, there's an integer overflow problem. Some games, like the_witcher_2, have files bigger than 4GB. The size is saved as a signed value and overflows:

<file name="the_witcher_2_redkit.zip" md5="acee3d250f283a30c87e15639448dde2" chunks="618" total_size="-2115021671">

which causes the lgdownloader to download the complete file again:

the_witcher_2_redkit.zip
MD5: acee3d250f283a30c87e15639448dde2
Chunks: 618
Size: 0 bytes

Filesizes don't match
Incomplete download or different version
Redownloading file
...
avatar
Sude: Apparently tinyxml didn't handle size_t in TiXmlElement::SetAttribute and thus size_t was cast to int which caused it to overflow.
This is now fixed in d31613d
Thanks, this improves the situation, but I looked at the xml and expect further trouble, since the last lines look like this:
<chunk id="613" from="2132803584" to="2143289343" method="md5">a0e4032a324b1f53a7d6de5dab8b6464</chunk>
<chunk id="614" from="2143289344" to="-2141192193" method="md5">2b2ca55eceaa547ffa7dc641e8dc0803</chunk>
<chunk id="615" from="-2141192192" to="-2130706433" method="md5">388f340bab0fe9ed16b3d1b0ba10a1f8</chunk>
<chunk id="616" from="-2130706432" to="-2120220673" method="md5">070d1e7d5bb35a24b09f84a66aaf9618</chunk>
<chunk id="617" from="-2120220672" to="-2115021672" method="md5">fe0a53142303fc6b691f4ee0035cc62d</chunk>

Another cast needed somewhere?

Another thing: --check-orphans doesn't seem to work for me. "Shadowrun
Returns" was updated today, but --check-orphans does not complain
about patch_shadowrun_returns_2.0.2.5.exe and
setup_shadowrun_returns_2.0.0.3.exe, both of which are obsoleted by
setup_shadowrun_returns_2.1.0.6.exe.

I ran it as "lgogdownloader --download --repair --create-xml automatic
--no-subdirectories --game shadowrun --check-orphans". Is it because
I'm using --no-subdirectories?

Thank you for your help!
Posted February 27, 2014
avatar
Loenas: Thanks, this improves the situation, but I looked at the xml and expect further trouble, since the last lines look like this:
<chunk id="613" from="2132803584" to="2143289343" method="md5">a0e4032a324b1f53a7d6de5dab8b6464</chunk>
<chunk id="614" from="2143289344" to="-2141192193" method="md5">2b2ca55eceaa547ffa7dc641e8dc0803</chunk>
<chunk id="615" from="-2141192192" to="-2130706433" method="md5">388f340bab0fe9ed16b3d1b0ba10a1f8</chunk>
<chunk id="616" from="-2130706432" to="-2120220673" method="md5">070d1e7d5bb35a24b09f84a66aaf9618</chunk>
<chunk id="617" from="-2120220672" to="-2115021672" method="md5">fe0a53142303fc6b691f4ee0035cc62d</chunk>

Another cast needed somewhere?
Should be fixed in fd5d9a4

avatar
Loenas: Another thing: --check-orphans doesn't seem to work for me. "Shadowrun
Returns" was updated today, but --check-orphans does not complain
about patch_shadowrun_returns_2.0.2.5.exe and
setup_shadowrun_returns_2.0.0.3.exe, both of which are obsoleted by
setup_shadowrun_returns_2.1.0.6.exe.

I ran it as "lgogdownloader --download --repair --create-xml automatic
--no-subdirectories --game shadowrun --check-orphans". Is it because
I'm using --no-subdirectories?

Thank you for your help!
--no-subdirectories shouldn't affect orphan check because it uses recursive directory iterator and should pick up files whether they are in subdirectories or not.

Does the API still return details for those files?
lgogdownloader --list-details --game shadowrun
Posted February 28, 2014
Thank you, the long-file problem is now fixed.

As for the orphans: No, the old files are not listed in the API output, only the four files that should exist.
Posted February 28, 2014
avatar
Loenas: Thank you, the long-file problem is now fixed.

As for the orphans: No, the old files are not listed in the API output, only the four files that should exist.
I found out what the problem was.
Repair and download have priority over orphan check and therefore orphan check was never performed.
4dba1c2 allows orphan check to run after download has finished
Posted February 28, 2014
Now orphan checking works for me too. Thank you very much!

One other question: is there or could you add a mode where it prints the sizes and md5 hashes reported by GOG for all files of a game? I'd find that very helpful :)
something like
filename size 12345 md5 6789abc...
Posted February 28, 2014
avatar
Loenas: One other question: is there or could you add a mode where it prints the sizes and md5 hashes reported by GOG for all files of a game? I'd find that very helpful :)
something like
filename size 12345 md5 6789abc...
--status does something similar
The problem with this is that the API doesn't give exact filesizes and only gives hashes for installers.

--status could be modified to print little more details in some cases but it would be much better if the API returned more details. Sadly API changes probably won't be coming anytime soon because the API isn't public.
Posted March 06, 2014
Who maintains the covers that your app downloads?
Posted March 06, 2014
avatar
DonCorleon: Who maintains the covers that your app downloads?
See this thread for more info. Most covers are now made by Stuff, and I do have a mirror of (most) of them in my OneDrive.
Posted March 06, 2014
Thanks JMich :)
Posted March 09, 2014
LGOGDownloader 2.12
- Fixed segfault during cover download
- Added support for saving default options to config file
* --save-config
* --reset-config
- Added --version option
- Added man page
* Man page is generated if the system has help2man installed
- Added support for Dutch, Swedish, Norwegian, Danish and Finnish language installers and language packs
- Added --report option which saves details to "lgogdownloader-report.log"
* Output format for downloads: Downloaded [status] filepath
* Output format for repairs: Repaired [chunks_repaired/total_chunks] filepath
- Subdirectories are now used for patches and language packs
- Added --no-subdirectories option to disable subdirectories for extras, patches and language packs
- Fixed some extras having wrong path names
- Added XDG Base Directory Specification support to Util::createXML
- Fixed compiling in some environments that didn't automatically include <sys/time.h>
- Added --retries option to set maximum number of retries on failed downloads. Default is 3 retries.
- XML data is now saved to subdirectories based on gamename.
* Fixes problem with some games using same filenames for extras
* XML data is saved to $XDG_CACHE_HOME/lgogdownloader/xml/gamename/filename.xml
- Fixed integer overflows in Util::createXML
- Made --check-orphans work with --download

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

sha256: 23a4e83d848bcf4094937309594dc865d9c7022f5b0a7e38335d4dc1cc93e37d
md5: 79bf104ab45fed54345bc852239c12e3
Pages:
1
10
17
18
19
20
21
30
40
50
60
70
80
90
98
This is my favourite topic
Community
General discussionLGOGDownloader - GOGDownloader for Linux(1458 posts)(1458 posts)
(1458 posts)