match queue not working after source removed

Archived discussion about features (predating the use of Bugzilla as a bug and feature tracker)

Moderator: Moderators

Locked
paka
Posts: 45
Joined: 2004-12-27 19:20

match queue not working after source removed

Post by paka » 2004-12-28 18:32

After I get "File not available" from a user or after I remove him as a source from the queue, match queue doesn't put him as a source (without restarting DC++). I came across it in 0.666 (after "File not available"). The user had a TTH filelist.

And it also occurs in 0.668. This time I did Match queue on a user and he was added as a new source (with the same nickname, not a space of difference). So his nickname appeared twice as a source for the files that he had (but with different source directories for the files in his share, as I saw in Queue.xml). Then I deleted him as a source (both occurences of his nickname). And then I did Match queue again - with no result (I checked the Queue.xml file to be certain, because the download queue window isn't always refreshed). The files were in his share, I added a few of them as a source manually.

In both cases I was able to readd the source manually - either from the search window or from the user's filelist.

I added this to Bugzilla: http://dcplusplus.sourceforge.net/cgi-b ... cgi?id=404.

joakim_tosteberg
Forum Moderator
Posts: 587
Joined: 2003-05-07 02:38
Location: Sweden, Linkoping

Post by joakim_tosteberg » 2004-12-29 02:21

Then DC++ gets "File not available" (or some other error) it removes the user as queue for this file. Right click the file in download queue thenexpand Re-add source in the manu and click on the user you want to re-add. This is expected behavior.

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Re: match queue not working after source removed

Post by GargoyleMT » 2004-12-29 12:06

paka wrote:And it also occurs in 0.668. This time I did Match queue on a user and he was added as a new source (with the same nickname, not a space of difference).
Was the hub the same?

paka
Posts: 45
Joined: 2004-12-27 19:20

Post by paka » 2004-12-29 18:53

joakim_tosteberg wrote:Right click the file in download queue thenexpand Re-add source in the manu and click on the user you want to re-add.
I'm not sure if I understood you correctly, but I couldn't simply readd the source in the queue because the user changed the source directories in his share. So I did Match queue. Besides, there were far too many files to do it manually.
GargoyleMT wrote:Was the hub the same?
It might be not the same. Sorry, I can't remember.

BTW, I think that the user (if his nickname is the same on more than one hub) should be written once as a source for the file in the queue and DC++ would choose dynamically a hub that the user is on. I mean, when I turn DC++ off and on and the user is found on another hub, two occurences of the same source for the file in the queue seem to be useless, don't they? In the second situation that I described above, there are two occurences of the same source (with a different source directory in the user's share, though... however, one of these sources must have been wrong and should have been removed with "File not available" displayed).

The first situation (with Match queue not working after File not available) should be easier to investigate because I didn't do so many things that complicated the reproduction of the bug as in the second case. The steps for this one would be:

1. Enqueue some files from a user.
2. The user changes the directories' names of the source files and his filelist is refreshed.
3. Receive "File not available" on the queued files.
4. Do Match queue on the user.
5. Match queue doesn't work (TTHs are the same, directories are different, but the filelist was refreshed after changes).

Hope it will be as easy to reproduce as it looks here... AFAIR there was no such problem in 0.401.

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2004-12-30 12:58

paka wrote:BTW, I think that the user (if his nickname is the same on more than one hub) should be written once as a source for the file in the queue and DC++ would choose dynamically a hub that the user is on.
ADC makes it easy to know that two users on different hubs are the same (matching CID), but guessing about that in the NMDC protocol might be what is causing your problem. It may not be helped with the $MyINFO changes (share size may be used to help determine if two users are the same).

I'm sure there's something to go on, I'm just not sure where one would start.
1. Enqueue some files from a user.
2. The user changes the directories' names of the source files and his filelist is refreshed.
3. Receive "File not available" on the queued files.
As a side note, you won't receive that error on 0.402+, which requests files by TTH instead of path.

paka
Posts: 45
Joined: 2004-12-27 19:20

Post by paka » 2004-12-30 15:18

GargoyleMT wrote:ADC makes it easy to know that two users on different hubs are the same (matching CID), but guessing about that in the NMDC protocol might be what is causing your problem. It may not be helped with the $MyINFO changes (share size may be used to help determine if two users are the same).
This is the problem of distinguishing users (I've mentioned it because it was one of the steps in the second case - with 0.668), but how about Match queue not working when the source user has already been removed (either with "File not available" or by "Remove user from queue")? In both cases that I described, the final situation was no source for the files and no reaction for Match queue.
As a side note, you won't receive that error on 0.402+, which requests files by TTH instead of path.
How should I understand this? The situation with "File not available+Match queue not working after filelist refreshed" won't happen in 0.402+ or will I get the file successfully because the filelist of the remote user will be refreshed automatically when requesting the given file (AFAIK now it's refreshed only upon filelist requests)? I'm using 0.668.

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2005-01-02 15:46

paka wrote:How should I understand this? The situation with "File not available+Match queue not working after filelist refreshed" won't happen in 0.402+ or will I get the file successfully because the filelist of the remote user will be refreshed automatically when requesting the given file (AFAIK now it's refreshed only upon filelist requests)? I'm using 0.668.
It means what it says: when DC++ 0.402+ asks for the file, it does so by TTH. If the user has moved the files, but not refreshed his list, DC++ will return file not available. If the user has moved the files and refreshed his list, you will get the file.

You're confusing file share refreshing with file list generation - they're separate actions, though the list generation can depend on share refreshing.

paka
Posts: 45
Joined: 2004-12-27 19:20

Post by paka » 2005-01-27 21:27

GargoyleMT wrote:You're confusing file share refreshing with file list generation - they're separate actions, though the list generation can depend on share refreshing.
Right, that was my habit to consider those two actions together as they were carried out in older versions. However, the problem is that I do a Match queue on the user and get no hits. Then I add the updated source from the same filelist manually and the download is resumed. I wonder how this problem is related to the change in 0.4032:
arnetheduck wrote: * When matching queue, users marked with file not available are readded (thanks farcry)
To make this bug easier to confirm, I'll suggest this set of steps (they work for me):

1. Start two instances of DC++ (can be DC++ and BCDC++ if there's a problem with only one instance allowed) and connect to the same hub as users A and B. In my case: client A was BCDC++ 0.401b (and was sharing files) and client B was DC++ 0.668 (and was downloading files).
2. Enqueue some files from user A on user B's client. Start the downloads.
3. Disconnect (with Close connection) user B on user A's client, remove the shared directory in Settings. User B gets "File not available" on the queued files.
4. Readd the directory to user A's share (can be under the same location in the share as before).
5. Do a match queue for user A on user B's client. 0 files matched.
6. Open the filelist (downloaded with Match queue) and readd the files manually. The downloads are resumed.

Of course, autosearch should be turned off on user B's client during the test.

paka
Posts: 45
Joined: 2004-12-27 19:20

Post by paka » 2005-02-02 01:31

Oops, this bug seems to be a duplicate of http://dcplusplus.sourceforge.net/cgi-b ... cgi?id=240.

The problem remains unsolved, though.

Locked