Official eMule-Board: [fix] Downloadlistctrl - Official eMule-Board

Jump to content


  • (2 Pages)
  • +
  • 1
  • 2

[fix] Downloadlistctrl emule v0.26d

#1 User is offline   Maella 

  • Magnificent Member
  • PipPipPipPipPipPip
  • Group: Members
  • Posts: 410
  • Joined: 27-December 02

Post icon  Posted 19 February 2003 - 02:32 PM

Hi,

The bug (thread) has been fixed.

Files:Maella.DownloadListCtrl.eMule0.26d.zip (Great thanks to Dr.Slump for the hosting)

:) Maella

This post has been edited by Maella: 19 February 2003 - 03:17 PM

0

#2 User is offline   Maella 

  • Magnificent Member
  • PipPipPipPipPipPip
  • Group: Members
  • Posts: 410
  • Joined: 27-December 02

Posted 19 February 2003 - 03:21 PM

Ok,

I changed the link. Thanks to Dr.Slump.

The previous edonkey link is not valid any more, so I can switch off now my computer!

Regards
Maella
0

#3 User is offline   Unknown1 

  • Wanna be Dev
  • PipPipPipPipPipPipPip
  • Group: Admin
  • Posts: 1288
  • Joined: 11-September 02

Posted 19 February 2003 - 04:53 PM

Thanks.. I'm testing this right now.. Seems to work very well.. But, it seems to have one of the problems that was inherited from the original code...

If you have a file with a lot of sources expanded.. Then try to expand another file with a lot of sources right above it, it doesn't expand correctly sometimes..

I don't think it's a bug in the source, but a case where the autosort function could interfering with it.. But not sure..

That's why I was thinking of a complete rewrite of the transfere window.. Add some more views and stuff..

But, since this class seems to be working very well.. I can delay this work for more pressing issues.. :)

#4 User is offline   Maella 

  • Magnificent Member
  • PipPipPipPipPipPip
  • Group: Members
  • Posts: 410
  • Joined: 27-December 02

Posted 19 February 2003 - 08:26 PM

@Unknown1
If you have a file with a lot of sources expanded.. Then try to expand another file with a lot of sources right above it, it doesn't expand correctly sometimes..

I never saw that, but I will make some test later by my own.

Maella
0

#5 User is offline   Unknown1 

  • Wanna be Dev
  • PipPipPipPipPipPipPip
  • Group: Admin
  • Posts: 1288
  • Joined: 11-September 02

Posted 19 February 2003 - 10:41 PM

It's a strange "bug".. Because it only happens sometimes (Usually with several files that have a large source list both being expanded with the bottom one expanded first...)

#6 User is offline   SlugFiller 

  • The one and only master slug
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 6988
  • Joined: 15-September 02

Posted 20 February 2003 - 12:16 AM

Oh, I think I know what's causing this bug, noticed it a while ago(in the code, haven't actually seen it in action). It's a problem with the way the sorting works. You see, the sorting is done in the windows kernel, probably using nlogn methods. The problem is that sources aren't sorted as children of the files(as in files sorted first, the sources), but instead the sources are sorted along with the files.

An inherent problem is the misinterpretation of 0 returned by the comparing function provided by the user. When uncertainty arises as to which of two files should be sorted first with sources from different files, the returned value is 0, hence the sources don't know whether to go up or down to attach to their own files, either may be possible at that time.

A proper fix would be to somehow use some actual tree implementation or faximily, something that would actually attach the sources to their appropriate files, and do proper double-sorting, first sorting only the files with the sources moving fully with them, and then sorting the individual sources. The point is to basically make the sources non-independant.

Another solution is to make sure file comparison never returns 0, that in case of equal standings on the current sort-by, an outside, constant, unique measure would be used to make the ruling, part.met filename would work fine, or perhaps pre-assigned indexing. This would be annoying with double-sorting though(since that requires the 0 base), unless actual multi-sorting is enabled(I actually already got the source for that, really simple fix), and then only in the case of all selected sorting modes failing the predetermined ruling would be used.
Why haven't you clicked yet?

SlugFiller rule #1: Unsolicited PMs is the second most efficient method to piss me off.
SlugFiller rule #2: The first most efficient method is unsolicited eMails.
SlugFiller rule #3: If it started in a thread, it should end in the same thread.
SlugFiller rule #4: There is absolutely no reason to perform the same discussion twice in parallel, especially if one side is done via PM.
SlugFiller rule #5: Does it say "Group: Moderators" under my name? No? Then stop telling me about who you want to ban! I really don't care! Go bother a moderator.
SlugFiller rule #6: I can understand English, Hebrew, and a bit of Japanese(standard) and Chinese(mandarin), but if you speak to me in anything but English, do expect to be utterly ignored, at best.
0

#7 User is offline   Unknown1 

  • Wanna be Dev
  • PipPipPipPipPipPipPip
  • Group: Admin
  • Posts: 1288
  • Joined: 11-September 02

Posted 20 February 2003 - 02:34 AM

Hmmm, I had to roll back to the old downloadlistctrl...

It wasn't displaying the transfer speed correctly for the sources..

It's hard to explain, but all the transfer speeds were on the wrong sources.. It seemed to total speed for the file was correct though...

There was a moment when it showed about 10 people as downloading, but it was actually only downloading from one source.. :/

#8 User is offline   Maella 

  • Magnificent Member
  • PipPipPipPipPipPip
  • Group: Members
  • Posts: 410
  • Joined: 27-December 02

Posted 20 February 2003 - 10:12 AM

@Unknown1

Strange :blink: , I didn't have such kind of problem yet.

Until that I can reproduce it, it would be hard to fix, but I have a idea.

Question: The 10 downloading people were a same and unique source?

Try this modification in CDownloadListCtrl::AddSource()

  // The same source could be added a few time but only time per file 
  // #ifdef _DEBUG
  {
  	// Check if this source has been already added for this file
  	std::pair<ListItems::const_iterator, ListItems::const_iterator> rangeIt = m_ListItems.equal_range(source);
  	for(ListItems::const_iterator it = rangeIt.first; it != rangeIt.second; it++){    
    CtrlItem_Struct* cur_item = it->second;
    // ASSERT(cur_item->owner != owner);
    if(cur_item->owner == owner){
    	cur_item->type = newitem->type; // to check
    	cur_item->dwUpdated = newitem->dwUpdated; // to check
    	delete newitem;
    	return;
    }
  	}
  }
  // #endif
  m_ListItems.insert(ListItemsPair(source, newitem));


I guess it is the source of the problem.

Maella
0

#9 User is offline   Maella 

  • Magnificent Member
  • PipPipPipPipPipPip
  • Group: Members
  • Posts: 410
  • Joined: 27-December 02

Posted 20 February 2003 - 11:07 AM

Well, the previous modification could not be enough

In my opinion these changes are easy to understand so I won't give more explanation.

First: you need to fix CUpDownClient::SwapToAnotherFile(bool bIgnoreNoNeeded)

old
theApp.downloadqueue->CheckAndAddKnownSource(SwapTo,this); 
return true;


new
theApp.downloadqueue->CheckAndAddKnownSource(SwapTo,this); // It may failed...
return (reqfile != NULL); 


Second: in CDownloadListCtrl::AddSource()

  // The same source could be added a few time but only one time per file 
  {
  	// Update the other instances of this source
  	bool bFound = false;
  	std::pair<ListItems::const_iterator, ListItems::const_iterator> rangeIt = m_ListItems.equal_range(source);
  	for(ListItems::const_iterator it = rangeIt.first; it != rangeIt.second; it++){
    CtrlItem_Struct* cur_item = it->second;

    // Check if this source has been already added to this file => to be sure
    if(cur_item->owner == owner){
    	// Update this instance with its new setting
    	cur_item->type = newitem->type;
    	cur_item->dwUpdated = 0;
    	bFound = true;
    }
    else if(notavailable == false){
    	// The state 'Available' is exclusive
    	cur_item->type = UNAVAILABLE_SOURCE;
    	cur_item->dwUpdated = 0;
    }
  	}

  	if(bFound == true){
    delete newitem;	
    return;
  	}
  }
  m_ListItems.insert(ListItemsPair(source, newitem));

Last point: some cleanning in file DownloadListCtrl.cpp

dwUpdated is a DWORD and not a boolean
dwUpdated = false must be changed to dwUpdated = 0

It's a mistake common to all versions of this file (patched/unpatched).

Maella

PS: So far, so good but I keep testing this new version
0

#10 User is offline   Jolinar 

  • Member
  • PipPip
  • Group: Members
  • Posts: 19
  • Joined: 10-October 02

Posted 20 February 2003 - 03:45 PM

Hi,

first sorry for my englisch ;)

@Maella

I test your Code, is good, Thx for This

but i have the same Prob. wo Unknown1

Quote

It wasn't displaying the transfer speed correctly for the sources..



I change the Code and Work´s Correct, I hope :)

In

void CDownloadListCtrl::DrawSourceItem(CDC *dc, int nColumn, LPRECT lpRect, CtrlItem_Struct *lpCtrlItem) {

Yours

case 4: // speed
if (lpCtrlItem->type == AVAILABLE_SOURCE && lpUpDownClient->GetDatarate()){
if (lpUpDownClient->GetDatarate()==0) buffer=""; else
buffer.Format("%.1f %s", lpUpDownClient->GetDDatarate()/1024.0f,GetResString(IDS_KBYTESEC));
dc->DrawText(buffer,buffer.GetLength(),lpRect, DLC_DT_TEXT);
}
break;
case 5: // file info


MY changes

case 4: // speed
if (lpCtrlItem->type == AVAILABLE_SOURCE && lpUpDownClient->GetDownloadDatarate()){
if (lpUpDownClient->GetDownloadDatarate()==0) buffer=""; else
buffer.Format("%.1f %s", lpUpDownClient->GetDownloadDatarate()/1024.0f,GetResString(IDS_KBYTESEC));
dc->DrawText(buffer,buffer.GetLength(),lpRect, DLC_DT_TEXT);
}
break;
case 5: // file info

========

and in

int CDownloadListCtrl::Compare(CUpDownClient *client1, CUpDownClient *client2, LPARAM lParamSort, int sortMod) {

Yours

case 4: //speed asc
return client1->GetDownloadDatarate() - client2->GetDownloadDatarate(); // return client1->GetDatarate() - client2->GetDatarate();
case 5: //progress asc


My changes

case 4: //speed asc
return client1->GetDownloadDatarate() - client2->GetDownloadDatarate(); // return client1->GetDatarate() - client2->GetDatarate();
case 5: //progress asc


the transfer speed is displaying now in my Client


Thanks an Bye
0

#11 User is offline   Unknown1 

  • Wanna be Dev
  • PipPipPipPipPipPipPip
  • Group: Admin
  • Posts: 1288
  • Joined: 11-September 02

Posted 20 February 2003 - 06:24 PM

Jolinar:

Ahh, I think you hit the nail on the head.. :) I'll change that when I get home today and see how it does.. :)

#12 User is offline   Maella 

  • Magnificent Member
  • PipPipPipPipPipPip
  • Group: Members
  • Posts: 410
  • Joined: 27-December 02

Posted 20 February 2003 - 09:29 PM

@Jolinar

Great, I hope that there is no remaing bugs this time.

GetDatarate() should never be used in this file.

:) Maella
0

#13 User is offline   Unknown1 

  • Wanna be Dev
  • PipPipPipPipPipPipPip
  • Group: Admin
  • Posts: 1288
  • Joined: 11-September 02

Posted 21 February 2003 - 10:10 PM

Hmm, one more thing with this class and I havn't had time to check out..

It doesn't update the status for things like if it stops a file with insufficient disk space or when a file completes.. (It keeps the waiting status.. ;) )

Everything else works pretty well now.. :)

#14 User is offline   Maella 

  • Magnificent Member
  • PipPipPipPipPipPip
  • Group: Members
  • Posts: 410
  • Joined: 27-December 02

Posted 21 February 2003 - 10:48 PM

:huh: Then buy a new disk and download only big rare files. Don't forget to change your fast modem with a very slow one (2400 baud)....

Or wait a few days that I (or somebody else) find the time to look at it :D

Is it really a new bug with my patch? :huh:

Maella

This post has been edited by Maella: 21 February 2003 - 10:51 PM

0

#15 User is offline   Unknown1 

  • Wanna be Dev
  • PipPipPipPipPipPipPip
  • Group: Admin
  • Posts: 1288
  • Joined: 11-September 02

Posted 22 February 2003 - 12:40 AM

Maella, on Feb 21 2003, 04:48 PM, said:

:huh: Then buy a new disk and download only big rare files. Don't forget to change your fast modem with a very slow one (2400 baud)....

Maella

Hehe, yeah.. reminds me of the the joke.. Hey Doc, it hurts when I bend my arm like this.. Then don't bend it like that.. :)

#16 User is offline   SlugFiller 

  • The one and only master slug
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 6988
  • Joined: 15-September 02

Posted 22 February 2003 - 01:00 AM

Maella, on Feb 22 2003, 12:48 AM, said:

:huh: Then buy a new disk and download only big rare files. Don't forget to change your fast modem with a very slow one (2400 baud)....

Or... use my Check Diskspace patch. Although, probably smart to wait until I port it to 0.26<whatever the letter may be by then>.
Why haven't you clicked yet?

SlugFiller rule #1: Unsolicited PMs is the second most efficient method to piss me off.
SlugFiller rule #2: The first most efficient method is unsolicited eMails.
SlugFiller rule #3: If it started in a thread, it should end in the same thread.
SlugFiller rule #4: There is absolutely no reason to perform the same discussion twice in parallel, especially if one side is done via PM.
SlugFiller rule #5: Does it say "Group: Moderators" under my name? No? Then stop telling me about who you want to ban! I really don't care! Go bother a moderator.
SlugFiller rule #6: I can understand English, Hebrew, and a bit of Japanese(standard) and Chinese(mandarin), but if you speak to me in anything but English, do expect to be utterly ignored, at best.
0

#17 User is offline   Maella 

  • Magnificent Member
  • PipPipPipPipPipPip
  • Group: Members
  • Posts: 410
  • Joined: 27-December 02

Posted 22 February 2003 - 04:19 PM

Quote

or when a file completes..


Without this change it could crash with a 'clear completed' cmd... Crash confirmed <_<

void CDownloadListCtrl::RemoveFile(CPartFile* toremove){
	// Retrieve all entries matching the File or linked to the file
	// Remark: The 'asked another files' clients must be removed from here
	ASSERT(toremove != NULL);
	for(ListItems::iterator it = m_ListItems.begin(); it != m_ListItems.end(); ){
  CtrlItem_Struct* delItem = it->second;
  if(delItem->owner == toremove || delItem->value == toremove){
  	// Remove it from the m_ListItems
  	it = m_ListItems.erase(it);

  	// Remove it from the CListCtrl
    LVFINDINFO find;
  	find.flags = LVFI_PARAM;
  	find.lParam = (LPARAM)delItem;
  	sint16 result = FindItem(&find);
  	if(result != (-1)){
    DeleteItem(result);
  	}

  	// finally it could be delete
  	delete delItem;
  }
  else {
  	it++;
  }
	}
	ShowFilesCount();
}


Maella

This post has been edited by Maella: 22 February 2003 - 04:20 PM

0

#18 User is offline   Unknown1 

  • Wanna be Dev
  • PipPipPipPipPipPipPip
  • Group: Admin
  • Posts: 1288
  • Joined: 11-September 02

Posted 24 February 2003 - 03:19 AM

Got it.. Working good.. :)

#19 User is offline   khaos 

  • Khaotic Modder
  • PipPipPipPipPipPip
  • Group: Members
  • Posts: 410
  • Joined: 24-November 02

Posted 24 February 2003 - 04:59 AM

I'm not sure if this is a bug or a feature (lol), but your fix differs from past versions of eMule in that it draws the yellow parts for EVERY source, instead of only the ones transferring. In other words, if a source has a part, and SOME source is transferring that part, then it gets drawn yellow. It used to be that yellow pieces were only drawn when a source was actually transferring that part. Did you intend for this, Maella?

EDIT: It's not doing it anymore... Strange. I will watch some more to either confirm or rebuke this claim.

This post has been edited by khaos: 24 February 2003 - 05:00 AM

0

#20 User is offline   JustusJonas 

  • Advanced Member
  • PipPipPip
  • Group: Members
  • Posts: 55
  • Joined: 09-November 02

Posted 24 February 2003 - 05:44 AM

khaos, on Feb 24 2003, 04:59 AM, said:

I'm not sure if this is a bug or a feature (lol), but your fix differs from past versions of eMule in that it draws the yellow parts for EVERY source, instead of only the ones transferring. In other words, if a source has a part, and SOME source is transferring that part, then it gets drawn yellow. It used to be that yellow pieces were only drawn when a source was actually transferring that part. Did you intend for this, Maella?

EDIT: It's not doing it anymore... Strange. I will watch some more to either confirm or rebuke this claim.

i've noticed that behaviour in all emule versions.. :blink:
0

  • Member Options

  • (2 Pages)
  • +
  • 1
  • 2

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users