Open UnforeseenOcean opened 7 years ago
Check your download thread setting in RipMe.
And why are you using an ancient Java ?
how did you try this? We can not add multiple url, it will say wrong format. Please tell us how did you do that?
Answers to above two questions:
Yep, but as far as I can understand it's only meant to accelerate downloading speed on THIS link only, not start another download before current one finishes. It's set to 5.
Type 1 URL, then press Rip. Then put another link, then press Rip button again. It adds them to the queue.
^ I'm at this very moment using RipMe to fetch my favs folders from DeviantArt, which means half a dozen links, no problem. The difference is I'm using Java SE 8 Update 141. Uninstall all old Javas you have and install 8 Update 144 from http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html
8 Update 144 released 2017-07-26, which is 2 days ago at the time of writing. Release notes: http://www.oracle.com/technetwork/java/javase/8u144-relnotes-3838694.html
First of all,
And second, I will try again after updating.
^ That pic makes no sense.
The picture is saying "Oh. My brain crashed."
And after updating, I don't think I can replicate the error. But here's the thing; Could any of you code-savvy people check the code to see if it does handle queues as they are supposed to?
They're supposed to finish one download THEN move to the next link, not download more than one simultaneously.
^ If I understand you right, it's ripping simultaneously from oneballharry.tumblr.com
and bearlounge.tumblr.com
instead of getting multiple files at once from oneballharry.tumblr.com
before bearlounge.tumblr.com
?
Yes. Exactly.
It is working fine .
Maybe it's something related to OS interaction and stuff? I really have no idea why or how is this happening.
@UnforeseenOcean: Can you confirm, is the problem only happening when you clicked stop and then tried to resume? I notice strange behavior with that sometimes. The handling of queues / stop / resume might have some bugs. The common use case for the program is to download one thing at a time. FWIW if your downloaded images are getting sent to the right folders, it's not really wrong, except that you're potentially downloading files you don't actually want.
The workaround for the latter scenario is to close the app, restart it, and rip only the things you want. (I mention this mainly because a bug with a workaround is a bug that will tend to be lower-priority.)
@rautamiekka: I've noticed you're on a crusade against older Java versions. Definitely admirable to get folks updated. A few things to note: we ask what version people are running, not so we can evangelize a crusade to get people to update, but because it's possible older Java can have bugs that affect correctness in RipMe, but that's not substantially likely in general, in my experience. Consider this: we don't operate on the fringes of the language or standard library, which means the Java language and JVM features we are using are well-tested and widely-used. Updates are not as likely to fix bugs in those areas as they are to fix security bugs around the edges (e.g. preventing arbitrary malicious untrusted Java code from running in Java applets in the browser) or add entirely new language features. These days, most web browsers entirely block Java apps from running when downloaded from the web into the browser, and RipMe is not a server app, so for our purposes, security issues are not a major concern, and new language features are not either because AFAIK we still stick to 1.6-compatible code. That said, 1.7 is quite old temporally and semantically, and is certainly old enough (as it is the previous semantic minor revision), that bug fixes may have occurred in areas we care about. However, we can be nicer about how we invite people to update their version of Java. For example, rather than asking "why?" [1], I'd take an approach like this:
The version of Java you're running (1.7.0_79) is from 2015-04-14, and that's old enough that it might be the cause of a bug. Please update to the latest version of Java (Java 1.8 Update 144) and confirm that this bug still occurs for you.
(Dates from https://en.wikipedia.org/wiki/Java_version_history#Java_SE_7)
[1] Besides, the most likely answer to "why?": When your web browser doesn't allow you to run Java, Java doesn't tell you to update anymore (seems like a recent thing, maybe it's because I uncheck the box to ask me to update or install via Ninite which does the same), and you've got nothing running Java, there's no reason to update, and most people (even developers of non-Java software) would not think to update on their own.
@metaprime No, it happens when normally using without stopping. The rip button does work, but the Stop button doesn't work when that happens. The queue SHOULD be processed one by one but it somehow managed to download two or more things at the same time. It might have something to do with thread management.
@metaprime RipMe may not but Java is used for other things too and ppl tend to totally forget Java could be updated and then are surprised why nothing works -or- refuse to update when the app complains a much newer Java is needed, thinking they already have the newest.
Plus it helps me stay on track when the chance of old Java is already ruled out instead of having to rule out everything else before possibly, if ever, concluding if it's a problem with old Java. Another story would be if a beta version would be needed for some reason, but I doubt we'll get to that point.
@rautamiekka Trying a basic repro on your end with your latest Java should be able to tell you whether a problem exists. If you want to go any further than that, you can ask the person reporting the issue to update their Java and try again.
@UnforeseenOcean I'm not sure it's a bug per se for the queue to be processing two downloads simultaneously. In fact, considering all of the anti-rate-limiting delays we have added, it probably makes more sense to do multiple downloads in parallel (if connecting to different domains). I can see why it would be annoying that the logs get conflated, but your downloaded files should all be going to the correct directories, right?
java -version
): 1.7.0_79oneballharry.tumblr.com
andbear-lounge.tumblr.com
)Expected Behavior
It downloads one link, Stop button is functional, then moves to next link
Actual Behavior
It tries to download two URLs simultaneously and Stop button is disabled (as shown by disk monitor, log and pending counter jumping between two ranges)