View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000203aMuleSearchpublic2004-11-20 18:522004-12-24 05:21
Assigned ToKry 
PlatformOSOS Version
Product Version2.0.0-rc7 
Target VersionFixed in Version2.0.0-rc8 
Summary0000203: Problems with search files using Webinterface
Description1. The search function iss only available if you choose a file-type, else the webinterface return no results.

2. If I start a search, which returns a lot of files, the browser (i tryied with Mozilla Firefox and IE) isn't able to show the full page, it's cut after a number of files that he found (i think at its around the 150th file). If that happend I'am unable to download a file or start a new search, becouse the buttons aren't on the page anymore.
I have to push the butten "zur├╝cksetzen" (i use german version) in the searchwindow of the aMule-programm, to make a new search with webinterface able. to make the "zur├╝cksetzen" butten available i have to start a search in aMule-prog.
It's the first time I use aMule, don't know if this problems are on every system. i used the debian-linux whitch iss on the knoppix3.4-CD
TagsNo tags attached.
Fixed in Revision
Operating System
Attached Files

- Relationships
related to 0000161resolvedGonoszTopi no result with amuleweb search feature 

-  Notes
GonoszTopi (administrator)
2004-11-24 23:22

About your problems:

1) is solved in current cvs (see [^])

2) it works here, can you confirm if this still exists in current cvs?
torben (reporter)
2004-12-20 19:18

I have the very same issue too, but I can give you a few more infos, all in regard to 2.0.0 rc 7. I have not tested it with current CVS (I am using Debian packages).

First of all, I don't think it has something to do with 0000161, you can workaround this if you click on "Refetch search results" after a few seconds.

What I can definitly reproduce on both long search results and on the shared file listing independently is that the output HTML code gets truncated after 13.140 Bytes (according to Firefox' page info) in all cases I have seen so far.

I can't reproduce this behavoir on other pages - they simply don't get that long in my current setup, but I suspect that this is a general problem.
torben (reporter)
2004-12-21 15:30

Ok, confirmed the same bahavoir for the transfers screen (got a file with a large number of chunks producing a large table) too.

- Issue History
Date Modified Username Field Change
2004-11-20 18:52 beatNukem New Issue
2004-11-24 23:12 GonoszTopi Relationship added related to 0000161
2004-11-24 23:22 GonoszTopi Note Added: 0000415
2004-11-24 23:24 GonoszTopi Status new => feedback
2004-11-24 23:25 GonoszTopi Status feedback => assigned
2004-11-24 23:25 GonoszTopi Assigned To => GonoszTopi
2004-11-24 23:25 GonoszTopi Status assigned => feedback
2004-12-20 19:18 torben Note Added: 0000461
2004-12-21 15:30 torben Note Added: 0000462
2004-12-24 05:17 GonoszTopi Assigned To GonoszTopi =>
2004-12-24 05:17 GonoszTopi Status feedback => resolved
2004-12-24 05:17 GonoszTopi Fixed in Version => 2.0.0-rc8
2004-12-24 05:17 GonoszTopi Resolution open => fixed
2004-12-24 05:17 GonoszTopi Assigned To => GonoszTopi
2004-12-24 05:18 GonoszTopi Assigned To GonoszTopi =>
2004-12-24 05:20 GonoszTopi Status resolved => assigned
2004-12-24 05:20 GonoszTopi Assigned To => Kry
2004-12-24 05:21 GonoszTopi Status assigned => resolved

Copyright © 2000 - 2024 MantisBT Team
Powered by Mantis Bugtracker