"FileSizeLo" : -1495418638,
"FileSizeHi" : 15,
A two's complement problem? What if you add 4.2G to that, would that make sense? You would get 2^32 -1495418638 = 2799548658
FileSizeLo (int) - Initial size of all files in group in bytes, Low 32-bits of 64-bit value.
FileSizeHi (int) - Initial size of all files in group in bytes, High 32-bits of 64-bit value.
Let's check the value "FileSizeHi" : 15, which would mean 15 * 4.2GB = 63GB. Could that be right at all in your case? This is History, so 63GB (plus 2.8 GB, so about 66GB), could very well be, right?
If so:
- quick workaround: on the client side, if negative, add 2^32. So force into unsigned int.
- with wireshark, you can see what NZBget API says (probably some around 2799548658), so the interpretation problem is in curl. I don't know if the JSON-RPC spec can make a difference between a signed int and unsigned int.
EDIT
Interesting quote on
https://nzbget.net/api/
64 bit integers are returned in two separate fields ‘‘Hi’’ and ‘‘Lo’’ (for example ‘‘FileSizeHi’’ and ‘‘FileSizeLo’’). These fields are unsigned 32 bit integers. Although dynamic languages such as PHP or Python have no problems with these fields the XML-RPC specification does not allow unsigned integers. This may cause troubles in statically typed languages such as Java or C++ if XML-RPC-parser expects only signed integers in 32 bit range. As a solution use JSON-RPC instead (which does allow unsigned integers) instead of XML-RPC.
Quote: "As a solution use JSON-RPC instead (which does allow unsigned integers)"
Ah, now I understand why @hugbug asked "XML-Rpc or json-rpc?" ...