Gnutella Forums

Gnutella Forums (https://www.gnutellaforums.com/)
-   Mac OSX (https://www.gnutellaforums.com/mac-osx/)
-   -   Lime Pro 4.6 and 4.8.1 quits constantly (https://www.gnutellaforums.com/mac-osx/35200-lime-pro-4-6-4-8-1-quits-constantly.html)

bigearedone March 16th, 2005 07:05 PM

Lime Pro 4.6 and 4.8.1 quits constantly
 
using a dual 450 os 10.3.8 and a Titainium 1.5ghz os 10.3.4

I upgraded to limewire Pro 4.6 and it would quit after a while then I went to 4.8.1 because I thought they might have fixed the bugs but still the same problem.

Using activity monitor it looks like Limewire is using a lot of cpu power and lots of threads(whatever they are)

after downloading some files it just quits.

I have about 2200 incomplete files which doesnt help but I have spent ages finding them and dont really want to delete them. I have taken out files that I was sharing in the hope of easing the burden - SHAME ON ME!! I'd prefer to have a program that worked well and that I could share everthing I have.

nothing else has been running on the dual 450 but I think one quit might have been caused by Software Update launching and daring to use some cpu power.

Help, please correct everything in the next version of Limewire and solve world hunger too!!

Peace and love and wellinton boots!

bigearedone March 16th, 2005 07:06 PM

onr more thing
 
I forgot to mention that i have run various versions of Limewire 4 without any problems its just 4.6 and 4.8 that I have had problems with

great program by the way - well done!!

profolio March 23rd, 2005 04:49 AM

More of the same
 
It seems there is a serious Java issue at play between Limewire Pro 4.8 and OS X 10.3.8
It's the only misbehaving app. on my box ( even Acquisition runs neatly) that stalls and quits constantly. Support from Limewire seems to be non-existant at best.
I think they should be more upfront about known bugs.
G4 twin 867 running 10.3.8 1gig ram

bigearedone March 23rd, 2005 06:14 AM

it was on os 10.3.4

I thought there was tech support when you bought the pro version but thats not the case so I wish they could just come clean and not offer it as a feature of buying the pro version

is there any solution if it is a java related problem?
like matching versions etc

Im just waiting for the next update but by then I think my 6months of free updates will be up which is annoying to say the least

ollieh March 31st, 2005 10:56 AM

hey hey i think i solved it. I had exactly the same problem. So i downloaded java update 1.4.2 and voila works perfectly.
I'm running a ibook g4 with mac os x 10.3.8
And limewire is working fine

bigearedone March 31st, 2005 11:59 AM

i have java 1.4.2 too
 
i have java 1.4.2 too so I am wondering if I have to delete old versions

how did you check your version was it with system profiler?

how many download files do you have in line waiting to download?

It seems when i launch the program and it queues everything up and then starts to download some.
it puts everything its checked into a "needing more sources" status

if I select a bunch of them and then hit resume it starts to look again and then puts them into the "awaiting status" category

its usually on this resume button that it can crash a few minutes later - like it just cant deal with new stuff in the queue or a change in order

I had about 3000 files waiting and deleted them from the search page down to 1500, but the ones i deleted are still in the library so I can load them sometime later

I have emailed Limewire several times and no answer

stief March 31st, 2005 12:43 PM

OS X can has a limit of 1,024 connections, IIRC.

So, you have far too many incompletes, especially if each one needs more than one connection. ;)

Quit LimeWire and find the incomplete folder. Sort the list so you can delete all the zero KB files and try again. The fewer incomplete files, the better LW works. Try to keep under ten.

For Java versions on OS X, you don't delete old versions: all are needed in case a particular progam needs an older version.

To check your version, just look in the About LimeWire box when LimeWire is running.

or

You can also check with the Terminal (in your Utilites folder). Open it and type exactly (there's a space in front of the minus sign):

java -version

then hit return. Copy the results to Textedit, and quit Terminal. You'll probable see something like
Quote:

java version "1.4.2_05"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_05-141.4)
Java HotSpot(TM) Client VM (build 1.4.2-38, mixed mode)

bigearedone March 31st, 2005 01:05 PM

thanks stief

I checked in about limewire and java is 1.4.2_05

which I think is the most up to date but I am going to try the latest java download and see if it says I should install it

regarding the about of in completes

I have set the auto delete to after 155days but there are still incomplete files in there from last august - so I dont know if its a bug in the software that they arent getting deleted?

its a little annoying that after spending ages searching for files and then hitting download that you end up deleting them

also there are some strange things about Limewire and I dont know enough about how networks function to figure it out. For example I am watching a file downloading but if I go search for this movie file it doesnt appear, in any permutation of search??

I couldnt really find a good explaination of the idea or mechanism behind selecting a "needs more sources" or "awaiting sources" file and clicking resume

has anyone figured out how to get a file that always appears in a search result but yet never gets downloaded

also if you set your anti-leech setting to 600 files you find people with 10 or no files on offer downloading from you???

stief March 31st, 2005 01:43 PM

Quite honestly, I'm quite surprised your LW is still working if there are hundreds of old files waiting. SO much in the code has changed, with more to come. Frankly, I'd just create a new OS X user account and install LimeWire there, and start fresh, or at least trash the old incomplete folder, and a brand new one will be created. The two files that store all the info about incompletes are the downloads.dat and downloads.bak files. I'm guessing they are a mess! The annoyance at losing all that research will probaly be repaid by a fresh start. YMMV.

Anyway, the old incompletes are probably useless by now, since those files are probably either gone from the network or are being hosted by a different IP. There aren't many hosts who keep the same static IP--most ISP's give out dynamic IP's, and many change nightly. I suspect LW is already ignoring those files.

The code behind the "Awaiting/Need/Resume" messages is often tweaked and improved, so it's difficult to know exactly what it means from version to version. Heh--the FAQ can't even keep up! The good part is that the versions keep improving, as the overall net growth shows.

As for the searches, a good busy host won't return results (those serrvents that return results for files, even though all the slots are filled, used to be far more annoying.

For the files that always show, check the file size. Some spammers have figured out how to show the name you type, but the file is spam. Control-click the file and choose a bitzi search to get more info.

As for the anti-leeching, it was deactivated for a while, and I don't think it works the same way it once did (if at all). Just ignore it, and let the network take care of it. I think sharers tend to attract better connections, so anti-leeching is in effect handled elsewhere.

bigearedone April 3rd, 2005 11:44 AM

forgot to say thanks for the advice so far stief - you seem to know more than use mere mortals. or perhaps you read the manual, ehem,

just on the point of limewire not being able to find a file that you have requested because the person sharing the file has logged back into the system and is now on a different IP address that his isp randomly assigned to him

Surely this cant be the case??

I mean it would be a really basic problem to fix if developping software

like when a user puts new files into their shared folder and hits refresh/update in limewire then the software would give each file a unique ID based on the name, no of bytes, file type etc and the ip address could be in there but not high in priority as a condition of finding the file ever again

if one finds a file based on the name surely Limewire is capable of finding it by name again

If its the case that Limewire finds the same file but at a different IP and isnt smart enough to dump the other file from the old ip and to see that the file on the new ip is the same and to then continue downloading it - then thats not a great situation.
Its impossible to know which incompletes fall into this category?

I know that if I have a file that is incomplete and have had it for months and decide to do a new search and click on a file with the same name to download, Limewire will warn me that I am downloading the file already

anyway to end this ramble I just think that a unique file id would mean that the change of ip for a bunch of shared files wouldnt matter - could that be possible? it would certainly then be based on a realistic understanding of the how the shared folders are existing and being used

the other annoying this is that some people have figured out how to take searches that people are doing and dynamically rename files that are actually their own ads

thre must be a way to stop this clogging things up?

I dont know how they end up being on so many peoples computers either. If you search for something really obscure and suddenly there are 47copies of a small graphics file which contains an advert??? the trick cant be renaming the files on other peoples computers? perhaps this ties into the unique file id topic

it would be great to be able to hold and extra key down when deleting a download and get it to delete the file and ref in the incomplete folder?

stief April 3rd, 2005 12:51 PM

Good to hear from you again bigearedone

re the incompletes being able to be refound, I wish it were easy.

There does exist a unique identifier, called a hash (sha-1). It's used for the bitzi lookup, magnet links (control-click a file in your Library Pane to see one of those), to verify that the file you received *exactly* matches the one sent, and probably more. There is also a more recent method of checking smaller chunks of a file, generally callled THEX, and it is still being improved/implemented more widely. I asked zab (now HE is expert on this part) if maybe one could resurrect an old incomplete file just from the bits already downloaded, but it doesn't look likely. And so, if the data in the downloads.dat file becomes corrupt or useless, there's not a method currently used to rebuild it.

Also, searches by hash have been . . .in short, banned. Not sure of the exact reasoning, but they were found to be easily abused and the network apparently suffered. Hashes are also "expensive" in terms of CPU use, but I gather this is a tradeoff to prevent a network being flooded by fake files because of a quicker and less secure hash method.

Keyword searches will indeed find current sources, but the problem is the cost of matching the new bits with the old. Too, files which may seem similar (size and much of the name) may actually be different in a few bytes. I guess the answer is currently coded as "just start from scratch after 6 failed attempts."

btw--I've quickly found "reading the manual" is not very reliable, since the developers are rightly spending their time developing. heh--in a dynamic network, it makes sense that the info is dynmaic too: static manuals get outdated pretty fast. The new wiki at http://www.the-gdf.org/wiki/index.php?title=Main_Page should help the developers update the info more, and I'm finding reading there quite interesting.

Sorry I can't be clearer with answers to your questions: I am not an expert, but you're welcome to what I've read ;)

And yes, there is hope about the new spam. The LW folks are talking with the Credence developers, for example. I guess the risk is that any "banning" mechanism can be tricked to ban legitimate hosts, which poses a risk to the network. The more I read, the more aware I've become of the 'politics' of p2p network development. LW is getting to be quite the grandfather here with its upcoming 5 years of development, and its growth is more fun to watch than many sports matches :D

bigearedone April 3rd, 2005 02:45 PM

on the old downloads thing - this is what I did

I copied off the whole "incomlete" folder onto a different computer, 2800 files. I took 2000 out and left in a folder and started limewire. Limewire loaded the old downloads and then I went into Library and incompletes and refresh then I selected everything in that window and hit resume

It seems to have worked and Limewire seems happier and faster to respond. It has crashed but only after a few hours on when I noticed most of the files had the 'need more sources' status so I selected 40 or 50 and hit resume and it started looking but I think this sort of messes with Limewires system and it just craps out a while later

I am curious about trashing the downloads file itself in the incomplete folder and seeing if the incomplete files themselves can be loaded and downloads start?
I suppose Im not desperate enough yet to try it but I could do it with just a few files on another computer - or perhaps someone had done that?

have you ever got in touch with any of the Limewire people? - I thought when I went pro that I would at least get some reply to my emails?
Nada.
Now I know I didnt pay much and perhaps there are only a few people working behind the scenes but I think encouraging some feedback or having a little button somewhere to suggest a new feature might be beneficial to the developers and ultimatly to us the end user?

a mass network of creative minds brainstorming a problem . . . .

on that thought Im wondering if there is any lunux / open source / copy left aspect to Limewire or is that covered in the generocity to share files and thats enough...?

stief April 3rd, 2005 04:00 PM

You're right about the brainstorming . . . and although these forums are independent of LW, members of the "team" http://www.limewire.com/english/content/team.shtml do get involved here, and often ask for suggestions http://www.gnutellaforums.com/forumd...?s=&forumid=24 or encourage feedback with beta testing http://www.gnutellaforums.com/showth...threadid=32702

I did get an answer through Pro support a once after a while, but honestly found the help in these forums faster. There's LimeWire.com, the commercial side; and LimeWire.org, the opensource project side. I figure if I stay away from the .com email support, more o' me bucks ends up supporting the .org side ;)

Back on topic: if you lose the relevant "downloads.dat" or its associated "downloads.bak" file, your incompletes cannot resume at more than zero kilobytes. So, another way to trim the incomplete folder is to weed out all the zero KB files.

Try running LW with less than 10 incompletes and see the difference (even 800 is too many).

Cheers

bigearedone April 21st, 2005 04:43 AM

just an observation I wanted to share with other users

deleting all the downloads in the main window doesnt delete any of the incomplete files so what I have been doing is deleting all the downloads in the download window and quiting.

then I reboot and go into the incomplete folder in the library window and select all and hit resume

after a few minutes things start downloading and the whole thing seems to work better and files that have been sitting there doing nothing start downloading

its a bit like spring cleaning

if I have no files downloading or waiting I will now delete all the downloads and quit and restart them

yihaa!!!

Does anyone know why this is the case?
Its as if Limewire does a better search for the files whereas before it might have been looking for a file on a specific IP?

any ideas??


All times are GMT -7. The time now is 11:35 AM.

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2025, vBulletin Solutions, Inc.
SEO by vBSEO 3.6.0 ©2011, Crawlability, Inc.

Copyright © 2020 Gnutella Forums.
All Rights Reserved.