Outline · [ Standard ] · Linear+ possible bug: eMule stops responding/refreshing, "Transfer" tab does not refresh

Hello, I have observed the following odd behavior/eMule not responding.

First, my system details:

Pentium MMX 233, 144MB RAM
Windows 2000, SP4, all drivers and patches up to date.
eMulePlus v1g

eMulePlus runs well on this configuration, good download speed, and DL/UL ratio of very close to 1. I am happy with that.

Now the problem: it usually happens after the program has been running for some time, about 4-5 hours or more. I have about 20 downloads on the list, and at any time, usually about 10 of them are downloading. I usually have about 40 people uploading from me at any given time. I then do my business as normal, and occasionally check on eMule.

The problem: during one of these normal checks, I open eMule from the task bar and I discover that the "Transfer" tab does not refresh, it is blank/grey. No downloads are seen there, not even the columns. The servers tab and all other tabs work well, the prefeences tab also works. I can switch servers, or change settings. But every time I go to the Transfers tab, the eMule transfers screen is grey, nothing is there. There is little or no disk activity, which is normal during eMule operation.

Now, I decide I want to restart eMule, maybe this will fix the Transfer tab. So I click "exit" and then confirm Do you want to exit? Yes. It does not exit, but stays there, very little hard disk activity, almost no CPU utilization. The behavior is just as before, but now the exit button does not work, i.e. it does not ask me again Do you want to exit?. But eMule is still there, after 2-3 minutes of waiting. I finally kill the process using Task Manager.

Then, when I restart eMule again, it rehashes all the files again. On my machine this is slow, but normal. And, there is almost always 2-3 corrupted files that cannot be loaded upon startup. I noticed that these corrupted files are often newly added (almost always).

This behavior I have noticed three times in the last five days.

Any idea what could be the problem?

JM

It is somewhat a known bug.. Only problem is that nobody can find it and nobody have succesfully made this happen 'on purpose'..

So it is rather hard to find and solve it ..
And another thing is that it is a highly random bug .. And rare for most users... Some never sees it.

Can you tell how to reproduce the bug?

Then I'm sure it will be solved pretty fast

JB

I had this behaviour when minimizing-restoring (reported bug: minimizing-restoring crash) if the displayed screen was traffic one when minimizing.

Unfortunately, I cannot reproduce the bug yet. But the "bug" is pretty consistent in its symptoms. So at least I know I am experiencing the same bug when it happens.

I was thinking that a clue may be that newly added files are the ones being corrupted after a restart.

I have enabled the option to save sources for each downloaded file, i.e. to save 10 sources for each file, every 3 hours, and to keep them a maximum of 5 days.

Could it be that this save sources feature is the problem? If someone else has experienced the same bug, can they check if they have enabled this save sources feature also? Conversely, for users who have never had this problem, are there some users that have enabled the save sources feature? Let's hear from several users of each kind. I think the feature is disabled by default.

Can this writing of sources be done in such a way that sometimes it does not "exit" correctly, so eMule hangs?



And before anyone asks me the obvious questions, here are the answers:
No, I do not have any type of firewall.
No, I do not use any type of memory management tool.

JM

This post has been edited by jmichka: Aug 13 2003, 21:11

Some users reports that rising the process priority of eMule from "normal" to "high" avoid the problems.

Ok, I have had the bug with new files added are corrupted after a restart and I'm using eMule Plus with 'normal' priority.

Have anyone had this bug with eMule on HIGH priority?

JB

i had the disappearing downloadlist myself 2-3 times (without reproducable information sorry). i notice that clickin on the grey area where the files would have been DOES change the header of the details-pane showing the filename.

i've always have "save sources" disabled.
process-priority is "above normal" (i don' think this makes any diffrence)
i've NO corrupted files that couldn't be loaded at restart

i hadn't this for some weeks now and i didn't try myself before, but u could do checkout if resizing the whole application (i've always had it maximized / minimized) might "repaint" the whole transferlist again.

syrus

You can reproduce this refresh bug if you run some app that will heavily use the CPU. It may help if you run Emule Plus with the priority set to high. I havent't tested if this behavior would somehow interfere with the download - this must be tested still.

By the way if you do a refresh based on Windows timer events - they may discarded on heavy CPU load

iirc, viewing downloads via webserver showed normal transfer activities and progress although gui was broken in the meantime. so i'd say if u have good speed let it run.

btw, resizing the app doesn't help.
and to be precise: all details are correctly when u click on the list

Hmm, when this unresponsiveness happens here, not only Transfer window is effected but the whole app (even taskmanager says 'not responding'), but CPU usage is almost 0 % at that time.
After 5-30 sec. it responds again, but during that time nothing special is happening (e.g. heavy HDD activity...), I can normally work with all the other running apps but emule really doesn´t react at all (e.g. I can´t change to Server window)

uhh i love timer dependant code

I had the same problem as netwolf.. with 1g that is

Maybe it is something external, something to do with the shell menu? since it's not effecting everyone.. it's very select, but not by OS..

Or am I just thinking weird things again