mldonkey-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Mldonkey-users] Re: pango-20021128b


From: Sven Hartge
Subject: [Mldonkey-users] Re: pango-20021128b
Date: Thu, 28 Nov 2002 22:48:17 +0100
User-agent: tin/1.5.14-20020926 ("Soil") (UNIX) (Linux/2.4.19-109 (i586))

Thomas de Grenier de Latour <address@hidden> wrote:
> On Thu, 28 Nov 2002 21:22:32 +0100 Sven Hartge <address@hidden> wrote:
>> Pierre Etchemaite <address@hidden> wrote:

>>> That looks like a totally logical modification, so either mldonkey
>>> was so far acting as greedyly as possible (maybe sometimes finding a
>>> new source by luck), or there's something obvious I'm missing.
 
>> If you are downloading files belonging to a series of files, then
>> there is a very high chance of discovering new sources this way.
 
>> Problem is: mldonkey cannot know, which files are "linked".

> We could imagine a few heuristics, like asking all other mp3 files you
> are downloading with the same album name in id3 tags (there is some code
> for id3 tags I think, the one used for in searchs).

One thing I learned is: heuristics never work, and if they work, they
work the wrong way.

> Another one could be "all other files with a significant common
> substring in one of the file names" (by significant, I mean "of a
> sufficient lengh". "Ally_Mc_Beal" for example is significant).

> This will only sometimes (often?) works, but it was also the case with
> the original behavior.
 
> We could also imagine a new command for explicitly grouping files.

This is the better way IMHO. The heuristics could be implemented in the
GUI, like a command to search files belonging together and leaving it up
to the user to actually mark them as such.

S°

-- 
BOFH excuse #281:

The co-locator cannot verify the frame-relay gateway to the ISDN server.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]