|
resuming download I just installed LW 2.0.2 under linux (using Sun jre 1.3.1) and i found that something strange is going on when resuming files. I had a bunch of incomplete download froom my previous installation of LW 1.8, when i find the file and click on it for downloading it again it can happen one of the following things 1) resumes the file (perfect behaviour) 2) starts downloading a new file cos of a a difference in the name (this should really be fixed! who cares about the name when the checksum is the same?) 3) overwrite the file restarting it from scratch (this just happened once but i lost 80MB of download :( ) 4) start downloading from scratch the file *without* setting its length to zero... that means that he simmply re-writes the file and when u get to the end continue downloading the part that was missing before I hope to have been clear. Can anyone please explain to me what causes these (erratic imho) different behaviours? thanks |
Same on Mac I get the same thin on Mac OS 9.2. 90% of the time, it starts over from scratch, and does not update the "Incomplete" files in the Library |
Same here, it used to resume fine until I downloaded 2.0. |
Resume doesn't seem to work at all with anything above 1.8c. If I have an incomplete transfer with 2.0+ I have to load 1.8c so I can resume. 2.0+ will overwrite the file from the beginning even if the checksum is the same in the Incomplete folder. |
force resume with 2.1 i just keep pushing 'force resume' ,then i scratch my head, then a 4 letter word comes outta my mouth,then i realize i've wasted the last 2 hours........nothing at all happens. |
Same problem here, running RedHat 7.2, slightly modified 2.4.7-10 kernel, ext3 fs, LimeWire 2.1.1. The behaviour seems erratic here too; I've been trying, unsuccessfully, to find a pattern. The most common scenario is that an attempted resume will ignore the incomplete file and start over, this time storing the new download *nowhere at all*. When the new download is "done", it copies the *old* incomplete file over to the shared directory. So I'm left with an incomplete file even though I waited for the full download to complete the second time around. |
Another common scenario seems to be that the resume fails and the download restarts from 0%, but when the new download reaches the size of the incomplete file, it starts adding to the end of it. Better than the scenario described above, because you actually get a complete file in the end, but still not good. |
This isn't listed in the "known bugs" is there a work around for this. |
DEVELOPERS Where the hell are you? |
resuming download I am getting the same absolute aggravating behavior in 2.1.1. This happens even when I am downloading from the SAME JERK that keeps interrupting the download. It most often happens when the other end kills the download. You then get a totally dead connection and have to kill it yourself later. If you do the kill, it will not resume where it left off. This has happened to me repeatedly in downloading large mpegs. It is truly aggravating as heck. |
Dear Developers, Why should I use Limewire 2.x if I cant resume? Even in version 2.1.3 beta this isnt fixed. Please hurry up to hold your fans. I am still using version 1.7 for resuming!! For the reason thers no alternatives on a Mac for filesharing, im still using your program. BUT... Greetings, mad26 |
Resuming download and other gripes Developers: In addition to my earlier `resuming download' gripe, again, you have not resolved the grouping issue. If the file is the same size, and has the same checksum, and the search grouped it together because of the same name CONTENT, I do not want you starting a new download if the names are not absolutely identical. PLEASE resume the download on the file that it has already started. I know you can do this because if I happened to have already downloaded the file, you complain about my attempting to write over the file! Thanks for your efforts. The use of multiple servers for downloads, and ultrapeer technology is sweet but these nagging aggravations destroy the enjoyment. |
Bumping this to the top; it's the most comprehensive thread on this issue. |
Most comprehensive, only nothing has been solved yet. I have 230MB of incomplete files (modem connection!). I was trying to copy one file under all the different names that it can be found under - hoping to resume. Now I know it was a nonsense - can't fool a machine. It won't resume until it reaches the incomplete file size. I hate computers! |
RESUME!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Is it possible to get the V1.8 for mac on the limewire website again?, cos it seems that the goods stopped there. |
Can I Get A Copy of An old Version Does Any1 know where I can get a Copy of an old LiveWire which actually resumes coz this is really frustrating and not to mention a waste of time and for us/those people who have an ISP with a download limit. Take Care And Thanks In Advance |
FAQ 1-1. The 1.8 versions resume properly I believe. |
Doesnt look like too many people from limewrie are steppign up to the plate on this one!!!!!!!!!! Resume resume resume piece of |
Resume Have same problem - tried to download a big avifile. the uploader got offline and i had once again only the half of the file. but there is no way to resume this file. One other question - i have dsl - why is my downstream so bad? BobMorain |
Same to me. All versions 2.x up are practically worthless, because there are so many *sorry* ****heads cutting the lines. version 2.20 behaves a bit better, it resumes at least some files, after a system i don't get til now :) another nice trick in <2.0 were renaming files in the library and resume from another file (same file with other name). btw. please dont rename your files after download. there easier to find then. cu Mike |
Just Click "Force Download"! Easy As That |
hey! That doesn't work. Duh... |
Hello Everybody I finally managed to get a reply from a LimeWire Developer: In the private message, he wrote this: "We basically don't reply because we don't have time to monitor the forums enough to know that the thread exists. This is because we're working constantly to improve LimeWire, fixing issues such as this. It's really just a constant tradeoff that we have to make -- the more time we spend on the forums and many other places (Gnutella developer groups, for example), the less time we have to write code to make the software better. We try to do the best we can, but it's just a difficult situation because the less time we spend coding, the more people complain about problems with the current version, leading to more time spent discussing those issues with users, which leads to yet less time spent coding, etc. etc. So, I do apologize that we have not addressed these issues on the forums. There are really only 5 of us, though, and I assure you that we have our hands quite full. I have neglected the forums in the past several weeks to devote more time to writing code, but hopefully I will have some time to devote here fairly soon. Thanks for your concern." In one of the threads, he wrote this: "Thanks for all of the comments. Our apologies for not responding to some of the threads -- we really do have limited resources and have to make a tradeoff between working on the program and answering people's questions or responding to their comments. As you probably know, I and the other LimeWire people who post here are the developers who actually write the software (and there are only five of us!), so it's just a constant battle to try to get to everything! We are working on the resuming issue in various ways. Actually, we're really tackling it by just improving the general architecture of the network so that resuming will improve along with a bunch of other things. The changes will really be on two fronts: 1) HUGE (Hash/URN Gnutella Extension), as mentioned above, will introduce a really nice scheme for efficiently finding duplicate of file on the network in a really robust way, which will improve resumes when you need to resume from another host and 2) Far better swarmed downloading using HTTP 1.1, which will make resuming an issue less often. This change will significantly improve download speeds. So, we have at least a couple a neat features coming along in LimeWire 2.3.0 fairly soon. We will also be updating the integrated player at least on OS X to use the native QuickTime API, so you'll get the best sound available on any system, at least on OS X. We may integrate this as an optional download on other platforms as well." So I guess they are really working on it! |
Problem is they've been "working" on this same problem *forever*. LimeWire has always been infamous as one of the worst peers for resuming files - makes it kind of useless for anything larger than a few meg. Many other gnutella peers (Gnucleus for one) manage this quite well with the current protocol by just having a re-search option to find more sources. LW tries half-heartedly, but if it can't resume immediately it either overwrites (should never be allowed to happen) or more likely just gives up enitrely. There's nothing more frustrating than having 90% of a 100+ meg file in your download folder, being able to find more sources in a search, but having absolutely no way to use them to resume. |
I agree, when I used BearShare it never happened, and it resumed fine.The only reason why I am using LimeWire is Ultrapeer. But I guess they're really trying hard. |
This is not an advertisement, but on AG Satellite the resume starts before my browser opens (seems like anyway)and there is no shortage of songs, DL tends to be a bit slower but that's made up in the fact that you don't have to re-DL a file you have 95% of already. Not all of us have 100 gig hard drives, you know. I'll hang onto this program and see if the next version is better but I am totally fed up. |
Open Source Whiners OK, I'm guilty of cluttering this up with the same spammy crap I'm bitchin' about but I can't stand it anymore!! I'm amazed how many people post nothing more than a whiny compaint about how the folks writing their free software won't answer to their every whim. If you don't like it, go use something else and leave the forums for pointing out legit issues. Maybe they could get to more of the real problems if they didn't have to listen to 100 morons saying nothing more than Waaaa! |
Re: Open Source Whiners Quote:
|
fixed resuming... patch here I haven't tested everything completely yet, but I believe I've fixed most of the problems associated with resuming downloads. Below is a patch for the source release currently available at http://download.limewire.org/servlet...wnload&dlID=15. Code: diff -br -C 2 core/com/limegroup/gnutella/DownloadManager.java ../limewire_new/core/com/limegroup/gnutella/DownloadManager.java |
Some clarifications on my patch above: It fixed two problems with resuming which I observed on my system (RedHat Linux 7.2); I make no guarantees as to how it'll work on your system. The patch will not do anything to let you resume old incomplete files which were on your system before the patched version was installed; it'll only help for new files. Finally, it should be noted that this patch will completely disable the "remove incomplete files after x days" feature; incomplete files will stay until you delete them manually. More specifically, the patch does two things: Firstly, it removes the "isOld()" check when purging the incomplete file directory, because that check returned true every time for files which were in the process of being downloaded when the check occured. Secondly, it adds a function which loops through and actively stops all active downloads on shutdown. This because data on the downloads wasn't being updated on shutdown, but I noticed that data was updated when I stopped a download manually. I'm sure there are much better ways of fixing both bugs, but I'll leave that to the real developers. |
It's not just Linux... #@%%$No Support? I just updated to the Win version of 2.2.3 and now incomplete files don't resume. I've got a bazillion partials in the incomplete folder ... ALSO, 2.2.3 insisted on updating JVM, and now my Gnotella program won't work unless I uninstall Limewire. Swell. And I actually, for once in my life, paid for the shareware. WHERE ARE THE TECH SUPPORT PEOPLE!!! |
anyone have uploadable old version (pre 2.00)?? Is it permissible to FTP from 'my' webspace an older (1.8 ?) version that's unregistered? Idea just came to me. |
Why not just ... I have LimeWare 2.2.1, and in the beginning it worked OK. I could shut the program down, and when I came online gain, it would resume any file that wasn't complete. Last time I went on - today - all the current downloads were gone from the download list, but they were still in the temp directory. When I found one I had a part of, it would resume correctly as I see it. But why can't I choose "Resume all incomplete files" and then it searches for any of these online, and resumes them. Preferably using hash/size match, as so many jerks out there renames the files. It is to benefit of ALL if the names stay the same. And if you want to put a comment about "share, share" or whatever, leave it out of the file name, use the description, PLEASE ! |
Re: Why not just ... Quote:
|
This software is unsupported!!!! Jezzz Don't you love it.... people throwing their hands up in the air after wasting hours of time trying to get broken software working, and the support people are nowhere to be seen. It's a great system: Limewire says pay us $9 for the Pro version and you'll get 6 months of support. So you pay - it's a nice thing .... support. Then - when you need it - which doesn't take long - they tell you to go to this forum for support. you come here, post your lament, and nothing. WHY CAN"T ALL OF US POSTING HERE ABOUT NOT BEING ABLE TO RESUME INCOMPLETE DOWNLOADS GET AN ANSWER??????? MAYBE IT'S TIME TO START E-MAILING ZD-NET ABOUT THIS, SINCE THEY'RE THE ONES THAT POINTED ME OVER HERE. Why do we hang on - I guess now THAT"S the question. Because it's a nice helpful program ... I've tried everything I can figure, including downloading the last several versions - but no help. They ALL can't handle the incompletes. Funny thing is, I could swear this used to work in the older ones - so what did 2.2.3 overlay..... |
Have anyone tried the code.. on page 2 of this thread posted for linux. I'm wondering if anyone has tried it in a windows enviroment. I'm just curious before I check it out for myself. And also to see if anyone has stopped bitching long enough to stop and try a posted solution. |
Re: Have anyone tried the code.. Quote:
|
Swell - let's all get in and patch the code That's a great solution. The developers aren't going to pay attention to the problems resuming downloads, so let's all get in there and start hacking at the code and try to fix it ourselves. Never mind we may not be programmers. |
It's time to e-mail zdnet That's on MY list for today. And to also get my $9 back. It's the principle of the thing. |
Windows too! It does the same thing in windows! Fcuking hell! fix it! you did it before so do it again! |
Java workaround Hi everybody! The resuming problem is really disgusting! Is anybody here who is able to present the Java fix (see above) in a way understandable for non-programers (exe-file or something)?? Would be great for all the people who are JUST users and music lovers, not porgramers!! I payed for the pro version and this resuming thing really ****es me of!!!! cu |
Yes I am aware that it "cross-platform". Maybe I didnt state my case properly. I was wondering if anyone has tried out the changes in a windows enviroment. (i'm not a java programmer) I just figured there has to be a reason that different versions are put out for each diff operating system. Like I said i'm not a java programmer.... just a ****ed off user. If you can explain it to me great, i'm all for gaining extra knowledge. Here is the non tekky speak of what you are seeing on page 2. What you see in the post is a output of a "file compare" program. (which one i dont know) From my limited knowledge what I see is this: The numbers you see *************** *** 433,436 **** --- 433,446 ---- basicly means that lines 433 to 436 are changed in the original 433 to 446 (or visa versa.) download the files from the link the "Unregistered" person proveded. what I did was to open the file using ultraedit. (i.e core/com/limegroup/gnutella/DownloadManager.java ) and replaced the lines of code that the posted provided (433 to 436) with the lines of code that are similar (433 to 446) you will have to remove the "+"s. You will recognize the code when you get to the specific line numbers. Then you will have to compile it. (i'm hoping I have time to do this tonight) I havent compiled it yet but I will post my result when I am done. |
Changing filenames Don't tell people not to change filenames for god's sake. Just because some moron named a file completely incorrectly (Mrs R*b*nson by the B**tles?, anything slightly heavy metal labeled as Metallica etc. etc.), shouldn't mean that I have to keep that file with a ridiculous name because of it. From using Morpheus/Kazaa, its resume function worked perfectly, and without any reliance on the actual name of the file, purely on checksums/filesize... Don't try and force people to conform to other's file arranging just because it makes your life harder. One of the great things about P2P is getting access to an amazing range of files, and having everyone conform to one thing will stifle this. The program needs to be fixed, not people's typing habits. __________________________________________________ Edited to comply with the House Rules. Warez, copyright violation, or any other illegal activity may NOT be linked or expressed in any form. |
Minor technical correction, Morpheus/Kazaa used/uses an MD5 file signature, not a checksum. An MD5 signature (or "fingerprint" as the official documentation refers to it) is a 128-bit value calculated by putting the file contents through a rather involved algorithm which if virtually guaranteed to be unique across all data patterns. In other words, it is virtually (and quite likely literally) impossible for two files to have the same MD5 signature. If you find a MD5 signature match, it IS the same file. While a checksum is also a value calculated using the contents of a file, comparing a checksum to a MD5 signature is a bit like comparing a height/weight/hair color description to a person's full DNA mapping. I don't know what the gnutella plan is for uniquely identifying files, but MD5 is a very good way to go. While the algorithm is owned by RSA, they allow it to be freely used as long as they get mentioned somewhere in the documentation. |
Actually it IS possible for two files to have the same MD5 - just unlikely enough that you don't really need to worry about it. A hash by definition can never be 100% perfect, you just can't fit an infinite number of possibilities into a number of finite size. If it was perfectly unique, you could just send someone the hash and they could recreate the entire file from that alone! ;-) Of course, you can't because it IS possible to create multiple files with the same MD5. I believe gnutella is going to use SHA which has a larger bit-size (160 vs 128) and is therefore *more* resistant to duplicates... http://www.secure-hash-algorithm-md5-sha-1.co.uk/ Of course you can't have more than "perfect" ergo MD5 isn't ;-) |
Yes, it is possible for two files to have the same MD5, but it's a one in 340282366920938463463374607431768211456 probability. I'd be willing to take my chances on those odds. |
I've been digging through the forum trying to find a way to fix this problem and I haven't come up with a thing. This has been going on for months and is in almost every version of limewire. Why hasn't anyone fixed it?!?!?! I just switched over from morpheus while they're down for remodeling, and so far I've downloaded 3 gigs and don't have a single file completed!!! One of my divx movie has restarted itself three times so far and I have three different incomplete files with a slight variation in file name on my hard drive. If this is the way limewire works, I'm just going to have to find another program. |
Alright! Thast's ****ing it! I've been looking through this forum for 3 days now and 44 posts are on this thread with no response. Iam not really happy with my 230MB file that won't resume from 83% I am on AOL and as all you otehr gAyOLers know gAyOL cut you off after a certaintime if you are not using "their" browser. Not IE or Netscape. The Ugly Multi-colored. aimed towards Britney Spears fan 14 year old girls with theri ****ty an anoyying news, that is "their" browser. It also has problems with other programs DLing stuff such as Morpheus, Limewire, Software that automaticaaly updates itself etc.... So I MUST have a resume feature. It took long enough to DL Limewrie and that damn java patch. Yes their maybe only five developers but I know programs with TWO developers (Checkout www.zsnes.com/yabbse "in the Bugs section" ) Dark Force and Pagefault that give about 1000 times more support than Limewire does. And zsnes never asks you to pay for it either. They are also multi-source and multi-platform. Of course this program is a Snes Emulator and not a Gnutella client. But I reallt think programming an Emulator is Assembler is alot harder than making some Java based program. I mean even my little sister (she is 13) knows enough java to edit Limewire. I personally never had this problem with Morpheus i don't think many did. But when It went to Gnutella things changed. And alot of other Gnutella clients are ****y too Bearshare won't "share" or connect or anything. But this resume bug is the worst. At least if i never connect I do not waste 8 hours on a modem DLing something that I will never be able to finish. I am going back to KAZAA/FasTrack. Hopefully they will get their problems straightenend out in the New Client they made. But as for Limewire. **** your "5 developer we are too lazy bull****" I provide more service than this for My own program SNES9X and we only have 3 maybe 4 when one of us isn't eating taking some time off or just doing something else for once. And you should too especially if every time i log on you ask me to pay for it. |
LimeWire has a fabulous opportunity to capitalize on the Morpheus situation. The client Streamcast chose to, uh, use as their baseline leaves a lot to be desired. So now you've got maybe 20 million people trying to decide if they should jump to Kazaa and put up with the spyware or if they should try to find a gnutella client that's better than the "new" Morpheus. A quick look around the internet will show there are few options and, on the surface, LimeWire appears to be one of the better choices. But spend a little time in these forums and you discover two things: there is very little action here, which suggests to me there aren't many people using LimeWire, and the place is run by absentee landlords. I paid the $8.50 to try to un-adware version of LimeWire, but so far I think I might as well of flushed that money. You go to the support link on the official web site and it says to come here for support, but there is clearly no support here. Unless they straighten up quick, LimeWire is going to blow the opportunity of the decade as far as gnutella clients go. |
Quote:
On a related note, has anyone tried the posted patch on a windows system yet? Update on my downloads: I've finished one (just one!!!) file and two more have stopped at 99%...total downloaded, 4 gigabytes |
| All times are GMT -7. The time now is 12:25 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.