aMule Forum
English => Feature requests => Topic started by: sandal-hat on September 12, 2007, 10:19:40 AM
-
First of all, thanks for the good job, I've been using Amule for Linux for years.
My request :
For those of us who regularly search to see if new files have appeared on the network, for the same keywords and same searches, this option could be really useful.
It would add any file to "known.met" and change the color of the file, that way I don't have to re-download it if I've forgotten about it, or for the searches that have a lot of results, it would help to "manually" filter the results once and for all, making the new files easy to spot.
When installing a new distro, importing all the known files with "known.met" would be really easy, too.
I'm not sure if I'm very clear, please give me some feedback.
Cheers.
-
hello ? no takers ? :)
-
. . . I agree!
As far as I remember:
This feature request is quite old and comes up from time to time.
This feature request is argumentative disregarded in favor of an "Intelligent Fake recognition".
Although, IMHO, this are two pairs of shoes, non of the features seem to find its way into aMule.
That is very sad, as it is a great piece of software!
-
First of all, thanks for the good job, I've been using Amule for Linux for years.
You're welcome.
It would add any file to "known.met" and change the color of the file, that way I don't have to re-download it if I've forgotten about it, or for the searches that have a lot of results, it would help to "manually" filter the results once and for all, making the new files easy to spot.
When installing a new distro, importing all the known files with "known.met" would be really easy, too.
Adding a file to "known.met" requires information that the search does not provide. There are two different classes: CSearchFile and CKnownFile. Both descend from CAbstractFile, but as you might guess, you cannot construct a CKnownFile from a CSearchFile. "known.met" provides the date, the hashset and other tags from the file, and IIRC, these informations are not available at the time of the search.
On the other hand, the file hash, name and size are available to both CSearchFile and CKnownFile, but we would be missing the file date and the hashes, because the file does not exist in our disk, and this information is obtained as soon as the transfer is complete.
So, I don't see that as an "easy task", because we just don't have the required information. If you could please give some more details of the implementation that you have in mind, I might be able to implement it. But please, base your argument on the real world, not on statements like "that should be easy!".
I can imagine the following solution: if we commit the incomplete information we have about the file on "known.met", that entry would be just enough to recognize the file by its hash. The only problem here is that we might be breaking the file "known.met", and to be sure of that this is valid, I would need more documentation on that file or some advice from eMule authors or someone with the necessary knowledge, like Kry, but unfortunately he has been very busy with real life issues.
Cheers!
-
Hi again,
As of tomorrow, the CVS code will have the feature "mark as known" implemented, but commented. Anyone that wishes to test it must manually remove the following #ifdef at line 572 of SearchListCtrl.cpp:
#warning Uncomment this here to test the MP_MARK_AS_KNOWN feature. Beware! \
You are on your own here, this might break "known.met"
#if 0
menu.Append(MP_MARK_AS_KNOWN, _("Mark as known file"));
menu.AppendSeparator();
#endif
The warning says it all. Plese report your findings. Worked fine here, I marked a file as known, exited, re-entered aMule and the file was still known, what means that the information has been saved to "known.met", but I don't know about long term consequences.
Cheers!
-
wow, I've been away for a while and this is a nice surprise, thanks, I will test it right away
-
Please, post your impressions.
Cheers!
-
Hi,
sri, but it seems, this doesn't work over sessions here. Actually, the files stay only marked during the current session.
cu
-
It's probably not a good idea to use the current approch, as we do not know the long term consequences. A simpler solution would be to simply save the filename (optional, but useful information), hash and size to a list, and then check against that.
-
Hi,
sri, but it seems, this doesn't work over sessions here. Actually, the files stay only marked during the current session.
Did you remove the #if 0 / #endif pair from the source code?
If not, please read my post above.
-
Hi to the board
@phoenix:
what does this feature is really good for? (Maybe I do not understand the sens/target behind it)
IMHO the normal procedure, specially for multimedia content, is the following:
- search for files related to a topic "XYZ".
At this stage it is unrealistic to decide to 'mark as known' because I know nothing about the available files.
- start to download some files related to the topic "XYZ".
- After some (short) time I can preview the files in the actual processing downloads.
Now I can decide (after ~5% downloaded) to dump the file or to proceed the download.
At this stage it is realistic to decide to 'mark as known' because I can rate the content of the file.
So to me it would make more sens to be able to
- 'mark as known' - a partial downloaded file, because I could rate the content, from the transmission window
- stop or abort a download, that I, for some reason, did not want to proceed.
- Start a new search after 1/2 year.
- Realise the already known files in the search list,
although I aborted approx. 90% of them
- send a big thank you to the coders for this nice feature
Comments welcome and
Regards to the coders
-
Did you remove the #if 0 / #endif pair from the source code?
If not, please read my post above.
Hi,
yes, of course, otherwise, I probably couldn't mark the files at all. The popup also provides the corresponding menuitem, and files can be marked. But, after a newstart, they are "forgotten" again.
cu
-
@phoenix:
what does this feature is really good for? (Maybe I do not understand the sens/target behind it)
The feature does exactly this: gives you the capability of adding any searched file to known.met. That way, in a next search it will appear with a different color, as if you had already started a download with it.
The idea behind it is that you have prejudged that you know the file and you are not interested, so the next time you search you can concentrate on files you have not downloaded or prejudged.
Hi,
yes, of course, otherwise, I probably couldn't mark the files at all. The popup also provides the corresponding menuitem, and files can be marked. But, after a newstart, they are "forgotten" again.
This is odd because it has worked here, but it has been a while since I last used it. Could you do a quick check to see if the file has been added to known.met?
Cheers!
-
@phoenix:
what does this feature is really good for? (Maybe I do not understand the sens/target behind it)
The feature does exactly this: gives you the capability of adding any searched file to known.met. That way, in a next search it will appear with a different color, as if you had already started a download with it.
The idea behind it is that you have prejudged that you know the file and you are not interested, so the next time you search you can concentrate on files you have not downloaded or prejudged.
Sorry to say,
to me that is an odd feature, or procedure, with regard to real live and usage of this software.
How can you prejudge something you do not know? Where do you get the information from?
-
Hi leofisch,
There are many obvious fake files, it is easy to prejudge on some cases.
There are other uses as well, you could for example have lost known.met because of a full reinstalation, and you are sure about certain files that do not interest you.
I know it is not THAT usefull, but that is what it serves for.
-
Hi phoenix,
I can confirm the following:
6 files marked as known in initial session.
this 6 files stay as known in search list as long as the session is not terminated.
After first restart of a session 2 from 6 files are forgotten.
After second restart no changes: remaining 4 files still known.
After 8th restart the remaining 4 files still known.
Tested with global search "java gui",
Target files where those 6 files with more than 1000 sources.
ciao
2008-004-12:
mone of those files are 'kown'
it looks like this feature does not work. :'(
-
Hi,
yes, of course, otherwise, I probably couldn't mark the files at all. The popup also provides the corresponding menuitem, and files can be marked. But, after a newstart, they are "forgotten" again.
This is odd because it has worked here, but it has been a while since I last used it. Could you do a quick check to see if the file has been added to known.met?
Cheers!
Hi again,
(and sri for the late reply... - the rl...)
Hm, strange. For some reason, now everything works as expected. However, I'm using todays cvs. So pse excuse the trouble. :-\
Be that as it may, the filenames are written to known.met _and_ kept there. :D
cu
-
To make it clear for people (like me) that were confused because they thought the # means a comment char: The code has to be as follows (at least I guess so):
//#warning Uncomment this here to test the MP_MARK_AS_KNOWN feature. Beware! You are on your own here, this might break "known.met"
//#if 0
menu.Append(MP_MARK_AS_KNOWN, _("Mark as known file"));
menu.AppendSeparator();
//#endif
BTW I am really waiting for this functionality, that every file downloaded partly and then canceled comes in a "known canceled file" list, too!
-
I cannot see any use of the context menu in the search result list. It makes only sense for me in the download list because i only know a file after partially view/unpack it.
-
Hi phoenix,
I took the liberty to extend your patch to support multi-selections, so that multiple files can be added to known.met with one call of the context menu...
I created the patch against aMule-CVS-20080910.tar.bz2, works fine here.
Cheers,
LA
diff -Naur amule-cvs/src/SearchListCtrl.cpp amule-littleabacus/src/SearchListCtrl.cpp
--- amule-cvs/src/SearchListCtrl.cpp 2008-08-09 22:38:01.000000000 +0200
+++ amule-littleabacus/src/SearchListCtrl.cpp 2008-09-12 14:19:32.000000000 +0200
@@ -685,16 +685,15 @@
void CSearchListCtrl::OnMarkAsKnown( wxCommandEvent& WXUNUSED(event) )
{
- int index = GetNextItem( -1, wxLIST_NEXT_ALL, wxLIST_STATE_SELECTED );
- if (index == -1) {
- return;
+#ifndef CLIENT_GUI
+ long index = GetNextItem(-1, wxLIST_NEXT_ALL, wxLIST_STATE_SELECTED);
+ while (index > -1) {
+ CSearchFile *searchFile = (CSearchFile *)GetItemData(index);
+ CKnownFile *knownFile(new CKnownFile(*searchFile));
+ theApp->knownfiles->SafeAddKFile(knownFile);
+ UpdateAllRelativesColor(searchFile, index);
+ index = GetNextItem(index, wxLIST_NEXT_ALL, wxLIST_STATE_SELECTED);
}
-
-#ifndef CLIENT_GUI
- CSearchFile *searchFile = (CSearchFile *)GetItemData(index);
- CKnownFile *knownFile(new CKnownFile(*searchFile));
- theApp->knownfiles->SafeAddKFile(knownFile);
- UpdateAllRelativesColor(searchFile, index);
#endif
}
-
Hi LittleAbacus,
Thank you for your patch, I have committed it and it will be on tomorrow tarball.
It is easier for us if you attach your patch as a file, otherwise, copy/paste does not work as well because of tabs. Anyway, this was just a small one, but bigger patches might be unpractical.
Cheers!
-
It is easier for us if you attach your patch as a file
Sure thing - next time. Shit happens when I'm working when there's sunlight outside...
-
Sure thing - next time. Shit happens when I'm working when there's sunlight outside...
lol :D
-
Another extension: since I'm not the foremost mouse freak and using this feature pretty regularly on large lists, I added an event listener which allows to "delete" marked files by just hitting the del key. Compiles and works fine here.
Cheers
LA
-
Because I have problems to fully understand the code by just reading the patch:
Will it ask before deleting the file(s)? It is a very useful function (because it is very intuitive), but I would NOT want to accidentally delete some files. An Undo-function is not feasible, I'm afraid.
Edit: There was a "NOT" missing...
-
Nope, this can't go in.
//#warning Uncomment this here to test the MP_MARK_AS_KNOWN feature. Beware! You are on your own here, this might break "known.met"
#if 0
menu.Append(MP_MARK_AS_KNOWN, _("Mark as known file"));
menu.AppendSeparator();
#endif
The feature is still highly experimental, and the risks are not analyzed yet. Your patch adds a (fully available) keyboard shortcut to the feature, while the mouse context menu still is unavailable without patching the code.
Before the feature itself is not qualified to go into the code we can talk about easing the access to it (and enabling it by the way).
-
Well then, how about a config option under advanced which affects
- the directive #if 0,
- CSearchListCtrl::OnMarkAsKnown (...) {
if mark_as_known_option_is_active {
//code from my patch
}
}
-
How about a proper investigation of the feature instead ? Then it either goes in or it goes out. Like Master Yoda says:
Do. Or do not. There is no try.
-
Neither do I know the amule source nor wxwidgets NOR c++ well enough to know what needs to be tested or even where to start looking. From what I gathered from this thread it's all about a "cast" from CSearchFile to CPartFile. I've been running this feature for about half a year and had no problems so far.
Anyways, I got what I want here, I'm content.
-
@wuischke
Sorry, overlooked your post earlier. Currently, there's no confirmation query.
cheers
LA
-
I don't get it how the feature can be useful in the current form.
So your search reveals 16 hits, 5 of which are known (downloaded before) and marked. What do you want to do with the others ? You can only start downloading them, and then quickly determine by the upcoming filenames which are fake. So the "mark as known" should rather be a "mark as fake and cancel" in the transfer window. Also a "mark as fake and delete" in the share window if you only detect it after downloading. And fake files should be stored in a different file. Master hash (and maybe size) should be enough.
Right now - why would you mark the extra 11 as known without ever checking them? Except if you did start downloading them and then mark them in the search window as known having no other option.
If nobody disagrees I'd implement the "mark as fake" and ditch the "mark as known". This also does away with the risky storage of information inknown.met which doesn't belong there.
-
I wouldn't count this feature out just yet. Imagine this use-case:
1. You enter a certain combination of keywords (rather coarse) and geht several hundred results.
2. Now you want to do some refining, so you enter some keywords you don't want to have, filter by them negatively and mark the yielded result as known.
3. repeat #2 arbitrary
4. remove the filter, press Ctrl+A and hit enter.
Got the idea? On the other hand, your "mark as [fake|known] and cancel" for the transfer window would be a nice (complementary) feature, no doubt. However, why replace it? Why start downloading only to have to cancel downloads again which you hadn't had to start, had you exercised the above use-case? Let alone the transfer window allows no filtering (which is just fine).
-
Got the idea?
No, sorry.
Why start downloading only to have to cancel downloads again which you hadn't had to start, had you exercised the above use-case?
Because the filename may be exactly what I'm searching, but the content still be just some cheap porn. Exercising your usecase won't help against that. Also it will spam known.met. Permanently.
-
No, sorry.
Ok. I've made the experience that (since the mark-as-known-feature) it's often easier to search by coarse keywords and refining the search than to do fine-grained searches in the first place.
Because the filename may be exactly what I'm searching, but the content still be just some cheap porn.
ACK. However when you start searching, you of course know everytime what you don't want to be yielded in the result list right from the beginning? Well, I don't and therefore BY looking at a coarse result list I can approach the results I want step by step without having to engage a whole new search.
Exercising your usecase won't help against that.
Of course not, it was never meant to. That's why I consider your proposed cancel-and-mark-as-<whatever>-from-transfer-window a useful complement to mark-as-known-from-searchresults.
Also it will spam known.met. Permanently.
What's the difference to "spamming" a file called let's say fakes.met? Somebody engaging in p2p might as well have a few spare MBs for amule's config itself. How those "known"-data is divided and where it's saved is but a paradigma and has nothing to do with the actual functionality discussed here.
-
What's the difference to "spamming" a file called let's say fakes.met?
A "known file" is a rather heavyweight structure, and the list of known is files held permanently in memory. Blowing it up with remainders from searches is way besides its intention and a waste of resources.
I still don't grasp how you want to refine your searches using "mark as known", but a permanent marker is definitely the wrong approach for that.
-
It's beside the point because the CSearchFile is just cast to CKnownFile instead of creating a new CKnownFile and setting the appropriate fields.
@grasp
Sorry, my fault, I forgot to mention that I employ the checkbox "hide known files" within the search dialog.
@wrong approach
What's wrong when it does the trick? Of course, speaking strictly technically you're right. However unless you provide a function which gives an equivalent functionality, don't remove it - or better: don't cripple amule. (speaking of equivalent: your proposal for the transfer window is not equivalent but complementary... but I already stated that).
If I still didn't convince you, at least just don't remove the feature but please post a reverse-diff-patch so those people who still want it can reverse-patch your reverse-diff. Or so.
-
If nobody disagrees I'd implement the "mark as fake" and ditch the "mark as known". This also does away with the risky storage of information inknown.met which doesn't belong there.
I disagree. It is made to be "mark as known" and the file actually becomes "known". The semantics given to "known" is a problem of the user. I have implemented and used it myself and in spite of some people considering it not useful, it actually IS usefull to some people (me included).
What can be argued is that the present implementation sucks, and I certainly agree with that, it has been a quick and dirty hack that can be improoved. The "risky storage of information inknown.met" should not be an issue in a proper implementation. My idea was that the patch evolved from there, if I thought it was totally useless, I would not have wasted my time implementing it at all.
A question to be raised is: what if you "mark as known" by mistake? That means that "Unmark as known" should probably be implemented too.
And now that we are at it :D let me suggest a related and also usefull feature: weak sort by "knownness".
Cheers!
-
The sorting by status is a nice idea. Shouldn't be too hard, so I'll see to it over christmas...
-
What can be argued is that the present implementation sucks, and I certainly agree with that, it has been a quick and dirty hack that can be improoved.
I'm glad you joined the discussion, phoenix, I was hoping for a word from you.
Sorry, but I don't count commented-out code as "implementation", rather as unfinished business. If you still find the feature useful, please go ahead and finish and release it.
The "risky storage of information inknown.met" should not be an issue in a proper implementation.
So - is it useable right now or not ? What happens if a user switches back to eMule and eMule tries to open the known.met ?
A question to be raised is: what if you "mark as known" by mistake? That means that "Unmark as known" should probably be implemented too.
Another issue with it.
I can of course leave it as it is and implement the "mark as fake" side-by-side. Problem is we have then two different approaches for almost the same purpose which is not helpful for the useability.
So I'd rather cover LittleAbacus' usecase with a "preselect" feature. You could select (or deselect) search entries and show all/preselected/not preselected entries. But the preselection would not be persistent (not stored after exiting the app). Persistance would only be available for known files like today, and for files marked as fake.
-
I'm glad you joined the discussion, phoenix, I was hoping for a word from you.
Sorry, but I don't count commented-out code as "implementation", rather as unfinished business. If you still find the feature useful, please go ahead and finish and release it.
Call it whatever you like, that is just semantics. The fact it that I have put this for trial for those who got interested and want to test it. I have no resources to go on hacking aMule right now, so all I can say is that I will do it Soon(TM).
So - is it useable right now or not ?
It is useable and works. But it could eat your cat or wash your brain. :)
What happens if a user switches back to eMule and eMule tries to open the known.met ?
You tell me, I don't use windows. If there is a problem, aMule should suffer it too. And it should definetely be fixed. The only reason why I have put this under comments is that I don't have the time to study the implementation properly, and any such feature, even if experimental, should be carefully planned.
I can of course leave it as it is and implement the "mark as fake" side-by-side. Problem is we have then two different approaches for almost the same purpose which is not helpful for the useability.
I agree. But why do you want the separate "mark as fake"? You are just imposing semantics, I don't see the gain. Also, I don't see spamming know.met as a problem, this is rather a user's choice.
So I'd rather cover LittleAbacus' usecase with a "preselect" feature. You could select (or deselect) search entries and show all/preselected/not preselected entries. But the preselection would not be persistent (not stored after exiting the app). Persistance would only be available for known files like today, and for files marked as fake.
Not usefull to me, I would need persistency. I also find it unnecessary GUI compication (bloat), but if someone sees a reasonable use for it, go ahead. I personally don't.
Cheers!
-
The only reason why I have put this under comments is that I don't have the time to study the implementation properly, and any such feature, even if experimental, should be carefully planned.
Well, so it will stay on hold until Soon(TM).
But why do you want the separate "mark as fake"? You are just imposing semantics, I don't see the gain.
Several people have asked for this already. The gain is:
- It will be available from the transfer and share windows, when you have had a chance to detect if it's fake or not.
- You can distinguish between files you have and files you rejected as fake.
- Fakes can be stored way more compact than known files, both on disk (unimportant) and in RAM (important).
-
You're just missing the point.
-
Then put me back on track please and explain to me what I'm missing.
-
Hi phoenix,
here's your sort feature. I refrained from determining the exact status the search results have in the DownloadList but just distinguished between "queued" and "finished", but see for yourself. For I made some other (private-to-me) changes, the patch should apply with an offset of a few lines but otherwise cleanly.
Cheers
Update: please use the v2.patch
-
Hi LittleAbacus,
Nice patch, I have committed it with a simple modification, because although aMule compiled fine, it was breaking the aMuleGUI build. SearchFile.cpp is "core", and amuleGUI does not use "core" files. I have passed the function DetermineStatusPrintable() to SearchListCtrl.cpp as a static member. If you disagree with something, please tell me. The committed patch is attached for your appreciation.
Thanks for your cooperation!
-
Hi phoenix,
on the contrary, I'm glad I could help. The subtle reason for your modification is exactly what I'm talking about when I say I don't really know C++/wx. One cosmetic thing: in line 79 of the patch there still exists a now obsolete commented-out declaration of CSearchFile* file.
We probably could somewhat tune the whole thing to
uint32 DetermineStatus(){ //detection routine like now}
and
wxString DetermineStatusPrintable(... toShow) {
switch (DetermineStatus(toShow)) {
case 1:
return wxT("foo");
break;
case2:
...
}
}
In order to avoid having the same code for several occasions (i.e. the new column and for color determination for a search result line)... Thoughts?
Cheers,
LA
-
Hi LittleAbacus,
My comments were not about C++ or wx, "core" refers to the way the aMule suite is divided internally. No rocket science, really and you did a good job. I will remove the unnecessary comment.
As for tunning and not duplicating code, indeed, that can be done and is a good practice, but please, before you post the next patch, compile aMuleGUI too to be sure it does not break :D
Cheers!
-
Hi phoenix,
attached you'll find the patch to remove duplicate code for status determination.
Regards
LA
-
Hi folks,
This thread has been around for three years, so it's time to decide.
The other developers seem to consider this not useful. Some users disagree.
The feature is currently commented on the code. I have not enabled it at first because I had no time to check whether the change in known.met was legal. The other devs have not shown any sympathy for the feature, so it remained in the dark and very few people tested it.
If anyone can guarantee that it does not break known.met, I can enable it.
It is more than time to decide, if people find it useful or like it, please say here, and the main thing: tell us if there are issues with the file known.met. Otherwise it will be removed from the code. Soon (TM).
Cheers!
-
I'll have a look on that later this week.
-
tell us if there are issues with the file known.met
I'm afraid this results in a memory leak. Known.met is loaded into knownfilelist which is kept in memory all the time, and entries are never purged from known.met.
On a sidenote: we have a list of canceled files meanwhile. Can't say if this throws a different light on this issue. At least canceled files are more efficient (just the masterhash, nothing else).
-
Not exactly a leak, but certainly crap laying around.
I like the sql approach you mentioned in the other thread to keep this stuff out of memory.
-
Having another look on it I believe it's safe to enable. Though I can agree with Stu in that "Mark as cancelled" might be a better feature.