[fox88]

Stulle, on 03 January 2021 - 10:45 PM, said:

I reckon you can spot the error.

Thanks, got it.
Do you think everything is great in this code?

uint64 llBuffer, llAvailableSpace;
if (mapNeededSpaceOnDrive.Lookup(nDriveNumber, llBuffer))
        llAvailableSpace -= llBuffer;
if (llAvailableSpace > (uint64)nFileSize)
        ...

Stulle, on 03 January 2021 - 10:45 PM, said:

Also, have you considered using Microsoft's Large Integer Functions in UInt128.cpp? I just stumbled upon them accidentally and was wondering if they might be performing better with the "uint64 m_u64Data[2]" memory layout.

Feel free to try and measure. If I recall correctly, difference in byte order made this non-trivial to use.

[Stulle]

fox88, on 03 January 2021 - 10:54 PM, said:

Do you think everything is great in this code?

uint64 llBuffer, llAvailableSpace;
if (mapNeededSpaceOnDrive.Lookup(nDriveNumber, llBuffer))
        llAvailableSpace -= llBuffer;
if (llAvailableSpace > (uint64)nFileSize)
        ...

Certainly not. llAvailableSpace hasn't been initialized. But I also don't get why you would make up that example. This is not something my proposed changes in CDownloadQueue::GetOptimalTempDir would cause.

[fox88]

Stulle, on 04 January 2021 - 08:31 PM, said:

Certainly not.

Then, so is the suggested change.
But the problem is not initialization or style, but unsigned subtraction.

nFileSize = 3;
...
uint64 llBuffer, llAvailableSpace = 1;
if (mapNeededSpaceOnDrive.Lookup(nDriveNumber, llBuffer)) //Lookup successful, llBuffer is 2
        llAvailableSpace -= llBuffer;
return (llAvailableSpace > (uint64)nFileSize);

Should be false, but true is returned.

[Stulle]

Alright, I finally see your point although you regretfully did a poor job of explaining it. At least for me... So yeah, an oversight of mine. To avoid that issue we would need to make another check like thus:

	for (INT_PTR i = 0; i < thePrefs.GetTempDirCount(); ++i) {
		const int nDriveNumber = GetPathDriveNumber(thePrefs.GetTempDir(i));
		uint64 llAvailableSpace;
		if (!mapFreeSpaceOnDrive.Lookup(nDriveNumber, llAvailableSpace))
			llAvailableSpace = 0;
		if (mapNeededSpaceOnDrive.Lookup(nDriveNumber, llBuffer))
			llAvailableSpace -= min(llBuffer, llAvailableSpace);

This last line fixes the potential negative subtraction result for llAvailableSpace. So at that point it is indeed questionable if the entire revision is worth it because now we'd have a new check (or rather a min call) just to avoid the casts.

[Stulle]

I reckon something got mixed up when revising emule.rc:

 STRINGTABLE
 BEGIN
-    IDS_SHAREEMULEWARNING   "Changing this option will let eMule use another configuration. Your current settings will be ignored and already started downloads might not be visible anymore. You can switch back to your current configuration by changing this option again anytime.\n\nYou need to restart eMule for this change to take effect."
+    IDS_SHAREEMULEWARNING   "Changing this option will let eMule to use another configuration. Your current settings will be ignored and already started downloads might not be visible any more. You can switch back to your current configuration by changing this option again anytime.\n\nYou need to restart eMule for this change to take effect."
     IDS_SPAM                "Spam"

I would say "will let eMule use another configuration" is at least gramatically correct. The additional "to" appears off.

[Stulle]

Just a thought on EnBitmap.cpp in function CEnBitmap::Attach: I believe the following change is actually increasing the resource usage instead of decreasing it.

-			if (hr == S_OK)
-				bResult = CBitmap::Attach(bmMem.Detach());
+			bResult = (hr == S_OK) && CBitmap::Attach(bmMem.Detach());

To improve things I believe it should be:

			if (hr == S_OK && CBitmap::Attach(bmMem.Detach()))
				bResult = TRUE;

This way we would only write to bResult if we truly change it's value. But then again, the actual impact will be negligible for eMule's overall resource consumption. So... yeah... just saying...

[fox88]

Thanks.
1. You were right, passive is not used with let.

2. I will revert the change; in terms of performance and code size the original code should be the best one.
By the way, in this module true and false should be in capitals.

[fox88]

A minor update to the release 0.60b (build 2) was published in Github.

This should fix
- crash on bad regular expression
- display of rating in Comments

The link is in the topmost post.

[hooligan3000]

thx works well for me

eMule v0.60b x64 Statistik [[Devils] .:SD-Master:.]

Transfer
Session UL:DL Ratio: 203.83 : 1
Session UL:DL Verhältnis (ohne Freundesupload): 203.83 : 1
Gesamte UL:DL Ratio: 484.10 : 1
Uploads
Session
Hochgeladen: 5.10 TB
Hochgeladene Daten durch Freundesuploads (Session): 0 Bytes
Aktive uploads/nötig um Bandbreite auszunutzen: 12
Gesamtanzahl der Uploads: 12
Wartende Uploads: 0
Upload Sessions: 21316
Totaler Overhead (Pakete): 15.76 GB (554.92 M)
Gesamt
Downloads
Session
Heruntergeladen: 25.62 GB
Beendete Downloads: 1
Aktive Downloads: 0
Gefundene Quellen: 0
Download Sessions: 1478
Durch Komprimierung gewonnen: 4.08 MB (0.0%)
Durch Datenfehler verloren: 0 Bytes (0.0%)
Teile gerettet durch I.C.H: 0
Totaler Overhead (Pakete): 2.03 GB (41.14 M)
Gesamt
Verbindung
Session
Allgemein
Erneute Serververbindungen: 28
Aktive Verbindungen (geschätzt): 14 (Halb:1 | Komplett:0 | Andere:13)
Durchschnittliche Verbindungen (geschätzt): 13
Verbindungsspitze (geschätzt): 40
Verbindungs-Limit erreicht: 0
Upload
Upload-Geschwindigkeit: 1.89 MB/s
Durchschnittliche Uploadrate: 1.94 MB/s
Max. Uploadrate: 4.18 MB/s
Max. durchschnittliche Uploadrate: 1.94 MB/s
Download
Download-Geschwindigkeit: 0 B/s
Durchschnittliche Downloadrate: 9.72 KB/s
Max. Downloadrate: 2.84 MB/s
Max. Downloadrate Durchschnitt: 10.03 KB/s
Gesamt
Zeit Statistiken
Letzter Reset der Statistiken: 14.08.2020 20:51:22
Zeit seit letztem Reset: 153 Tage 19:10 Stunden
Session
Programm-Laufzeit: 31 Tage 23:40 Stunden
Übertragungszeit: 31 Tage 23:40 Stunden (100.0%)
Dauer auf aktuellem Server: 17 Tage 20:25 Stunden (55.8%)
Dauer auf Servern: 31 Tage 23:38 Stunden (100.0%)
Gesamt
Abschätzungen
Clients
Bekannte Clients: 14
Software
Netzwerk
Port
Firewalled (Kad)
UDP: 59.9%
TCP: 64.5%
Niedrige ID: 10 (71.4%)
Identifikation (pos : neg): 12 (92.3%) : 1 (7.7%)
Problematisch: 0 (0.0%)
Gebannt: 3
Gefiltert: 0
Server
Funktionierende Server: 19
Server mit Login-Fehlversuchen: 0
Gelöschte Server: 87
Gesamt: 19
Gesamte Benutzeranzahl: 185.70 K
Gesamte Dateianzahl: 52.60 M
Rekorde
Max. funktionierende Server: 25
Max. Nutzer Online: 229.38 K
Max. Dateien verfügbar: 68.67 M
Freigegebene Dateien
Anzahl freigegebener Dateien: 270
Durchschnittliche Dateigröße: 4.40 GB
Größte freigegebene Datei: 122.41 GB
Gesamtgröße freigegebener Dateien: 1.16 TB
Rekorde
Festplattenplatz

This post has been edited by hooligan3000: 15 January 2021 - 02:02 PM

[QICKV8]

Thank you fox88, I have been running eMule 0.60 for 3 months 24/7 and not had 1 crash

[fox88]

A tiny update to the release 0.60b (build 3) was published in Github.

This should fix regression in PartFileConvert GUI.

As usual, the link is in the topmost post.

This post has been edited by fox88: 08 October 2023 - 04:28 PM

[Stulle]

I found a possible memleak in CGetMediaInfoThread::GetMediaInfo.

The code used to be

				case ID3FID_WWWUSER:
				{
					wchar_t
					*sURL = ID3_GetStringW(frame, ID3FN_URL),
					*sDesc = ID3_GetStringW(frame, ID3FN_DESCRIPTION);
					CString strURL(sURL);
					strURL.Trim();
					if (!strURL.IsEmpty())
					{
						CString strDesc(sDesc);
						strDesc.Trim();
						if (!strDesc.IsEmpty())
							strFidInfo << _T("(") << strDesc << _T(")");

						if (!strDesc.IsEmpty())
							strFidInfo << _T(": ");
						strFidInfo << strURL;
					}
					delete[] sURL;
					delete[] sDesc;
					break;
				}

Now it's

				case ID3FID_WWWUSER:
					{
						wchar_t *sURL = ID3_GetStringW(frame, ID3FN_URL);
						wchar_t *sDesc = ID3_GetStringW(frame, ID3FN_DESCRIPTION);
						CString strURL(sURL);
						if (!strURL.Trim().IsEmpty()) {
							CString strDesc(sDesc);
							if (!strDesc.Trim().IsEmpty())
								strFidInfo << _T("(") << strDesc << _T("): ");

							strFidInfo << strURL;
							delete[] sDesc;
						}
						delete[] sURL;
					}
					break;

Only deleting sDesc in case !strURL.Trim().IsEmpty() appears wrong to me. In case the test expression is false we have not copied it to a CString but then again, that wouldn't change anything about the local pointer or the memory it points to either.

Am I missing something or do you agree?

This post has been edited by Stulle: 17 January 2021 - 01:56 PM

[fox88]

Thank you.
The idea was to process description inside the conditional block.
This statement ought to be two lines lower:

wchar_t *sDesc = ID3_GetStringW(frame, ID3FN_DESCRIPTION);

[Stulle]

Yeah, that sounds about right, too. Happy to help.

[Heliotropo]

Hi. Since the first version of emule0.60 x64 was released, I have been doing many tests on two computers and in all of them I get the same result: I lose most of the users from the upload queue. I've been following the emule forums and no one seems to have anything like this happening, which frustrates me even more.

I am a low ID user and I can't fix it because I don't have access to the router. My two laptops, a hp (eighth generation intel i5) and a vaio (first generation intel i7), have windows 10 pro x64 and 8 gigs of RAM.

[Heliotropo]

I have used several configurations in emule, but the results regarding the problem have not changed. Download capacity 3000 KB/s Upload capacity 3000 KB / s, dw and up limit 1200 KB/s (also 800 or 1800), file hardlimit 50, Max connections 150, Max new connections 20, Max half open 9 ... With previous versions 0.50a or 0.51d, for example, with the same network (100Mb/ADSL), on the same computers and with similar configurations, I have never had this problem. When you activate verbose, the message that repeats continuously is ...

17/01/2021 17:32:38: Adding client to upload list: Direct add with empty queue. Client: 92.xxx.xxx.37 'xttp://emule-project.net' (eMule v0.50a,None/None/None)
17/01/2021 17:32:42: Removing client from upload list: CUpDownClient::Disconnected: CClientReqSocket::Disconnect(): Error 10053: A connection established by the software on your host computer has been aborted. Client: 92.xxx.xxx.37 'xttp://emule-project.net' (eMule v0.50a,None/Uploading/None) Transferred: 3 secs SessionUp: 76.17 KB QueueSessionPayload: 74.12 KB In buffer: 285.88 KB Req blocks: 1 File: xxxxxxxxx xxxxxxx xxxx.avi
17/01/2021 17:32:42: WSAGetOverlappedResult return error: An existing connection was forced to break by the remote host.

Sometimes, although much less frequently, I have also seen error 10054. And one thing I have also noticed is that aMule or ePlus users seem to have a better chance of staying in my upload queue.

[Heliotropo]

I have come to think that users with high IDs have not realized that they lose many users in the upload, because they have many. But in my case, that with low ID I don't have so many users in my upload queue, with the old versions of emule I can upload 5GB per hour and with emule 0.60b, if I'm lucky, I get to 1GB.

I am sending this long message with the sole intention of giving information to the developers, to whom I thank the generous effort they are making to update emule and to reactivate the emule community with it. I will continue trying with later versions, but, although I see that the download of this new version is good, that it seems that the memory and energy use is lower and that even when it does not reject a user on the upload, it seems that this is stable, I will continue using the versions that allow me to share more. Sincerely.

[fox88]

Hi Heliotropo
Do you have poor upload or download, eMule cannot search and so on?

[Heliotropo]

I only have problems with the upload. Emule finds users normally, but in the first seconds of the connection most of the users are rejected, the connection is cut. With the users who stay on the climb it seems that everything is going well. As can be seen in the lines of the verbose that I have put, the problem is that the remote host forces the break connection for some reason.

This post has been edited by Heliotropo: 20 January 2021 - 04:22 PM

[fox88]

Few people are running eMule 24/7, and there could be prolonged time spans when no peers would be downloading (have seen empty queue many times - with high ID).
If you try to look at longer periods like days or weeks, will the uploaded amount be significantly lower than with previous versions?