Bug 72355 - download age is not displayed correctly with kde32 cvs
Summary: download age is not displayed correctly with kde32 cvs
Status: RESOLVED FIXED
Alias: None
Product: kmldonkey
Classification: Applications
Component: general (show other bugs)
Version: 0.9.1
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Petter Stokke
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-01-11 05:02 UTC by marco puszina
Modified: 2004-01-27 22:17 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments
screenshot (50.58 KB, image/jpeg)
2004-01-11 05:05 UTC, marco puszina
Details

Note You need to log in before you can comment on or make changes to this bug.
Description marco puszina 2004-01-11 05:02:26 UTC
Version:           cvs 20040110 (using KDE Devel)
Installed from:    Compiled sources
Compiler:          gcc332 
OS:          Linux

with kde32 cvs snapshot 20040109 and current 20040110 kmldonkey cvs NEW ADDED downloads are shown with a negative age (-2147468000s) - old entries are shown with correct age - the age is shown correct via telnet or webaccess.

i cannot speak for a stable release of kde31something as i only got a kde32cvs running here at the moment.

rgds
marc'O
Comment 1 marco puszina 2004-01-11 05:05:31 UTC
Created attachment 4087 [details]
screenshot
Comment 2 Petter Stokke 2004-01-11 18:31:56 UTC
I'm getting the same thing here; seems like a recent kdelibs development, as it wasn't happening with CVS HEAD from a week or so ago and there's not been any changes in the relevant KMLDonkey code since then (or in mldonkey, for that matter).

Will investigate as soon as time permits.
Comment 3 Petter Stokke 2004-01-12 17:20:50 UTC
Subject: kdeextragear-2/kmldonkey/libkmldonkey

CVS commit by pstokke: 

Worked around an mldonkey core bug. It seems that for time values over
0x40000000 (ie. last Saturday afternoon) the core starts sending out
negative time values, which can be corrected by adding 0x80000000. This
patch uses 0x7FFFFFFF just to avoid any signedness problems that might crop
up (I'm paranoid about bad compilers), so the time will actually be one
second off. You're welcome to sue.

CCMAIL: 72355-done@bugs.kde.org


  M +9 -5      fileinfo.cpp   1.5
  M +7 -4      fileinfo.h   1.4


--- kdeextragear-2/kmldonkey/libkmldonkey/fileinfo.cpp  #1.4:1.5
@@ -101,7 +101,11 @@ void FileInfo::updateFileInfo(DonkeyMess
     j = msg->readInt16();
     chunks_age.clear();
-    for (i=0; i<j; i++)
-        chunks_age.append(msg->readFloat());
-    age = msg->readFloat();
+    for (i=0; i<j; i++) {
+        time_t a = (int)msg->readFloat();
+        if (a < 0) a = 0x7fffffff + a;
+        chunks_age.append(a);
+    }
+    age = (time_t)msg->readFloat();
+        if (age < 0) age = 0x7fffffff + age;
     format = msg->readInt8();
     switch (format) {
@@ -228,10 +232,10 @@ const double FileInfo::fileSpeed() const
 }
 
-const QValueList<double>& FileInfo::fileChunksAge() const
+const QValueList<time_t>& FileInfo::fileChunksAge() const
 {
     return chunks_age;
 }
 
-const double FileInfo::fileAge() const
+const time_t FileInfo::fileAge() const
 {
     return age;

--- kdeextragear-2/kmldonkey/libkmldonkey/fileinfo.h  #1.3:1.4
@@ -30,4 +30,7 @@
 #include <qcstring.h>
 
+#include <sys/types.h>
+#include <time.h>
+
 #include "donkeytypes.h"
 
@@ -88,7 +91,7 @@ class FileInfo
     const double fileSpeed() const;
     //! The age of individual chunks.
-    const QValueList<double>& fileChunksAge() const;
+    const QValueList<time_t>& fileChunksAge() const;
     //! The time the download was started (seconds since Epoch).
-    const double fileAge() const;
+    const time_t fileAge() const;
     //! The file format.
     const int fileFormat() const;
@@ -127,6 +130,6 @@ private:
     QMap<int,QByteArray> availability;
     double speed;
-    QValueList<double> chunks_age;
-    double age;
+    QValueList<time_t> chunks_age;
+    time_t age;
     int format;
     QString formatinfo;


Comment 4 Henk de Leeuw 2004-01-27 22:17:14 UTC
Instead of testing for negative, then conditionally adding 0x7FFFFFFF, you can also just 'and' unconditionally with 0x7FFFFFFF. This will also prevent the one-second-off error... ;-)