goatie
-
Posts
26 -
Joined
-
Last visited
Content Type
Profiles
Forums
Gallery
Downloads
Events
Blogs
Store
Posts posted by goatie
-
-
some interesting info posted by 'demonzon' regarding the RSS issue. uTorrent staff can this
be addresses and fixed?
--------------------
For some reason utorrent sends Content-Length: 0 in its GET request. lighttpd does not accept this.
For example' date=' TPBs High Def TV Shows requests are requested (in utorrent) as this:
GET /208 HTTP/1.1
Host: rss.thepiratebay.org
User-Agent: BTWebClient/3100(26595)
Accept-Encoding: gzip
Connection: Close
Content-Length: 0
The "Content-Length: 0" is not valid in a HTTP GET request.[/quote']
Thanks for the info. I'll attempt to reproduce this bug, and update you tomorrow.
Using Firefox & Live Headers, I'm getting :
GET /201 HTTP/1.1
Host: rss.thepiratebay.org
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20100101 Firefox/9.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-gb,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
HTTP/1.1 200 OK
Content-Type: text/xml
Etag: "2246646985"
Accept-Ranges: bytes
Last-Modified: Thu, 15 Dec 2011 18:03:05 GMT
Content-Length: 62346
Date: Thu, 15 Dec 2011 18:04:02 GMT
Server: lighttpd
for Pirate Bay
and
http://www.mininova.org/rss.xml
GET /rss.xml HTTP/1.1
Host: www.mininova.org
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20100101 Firefox/9.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-gb,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
HTTP/1.1 200 OK
Cache-Control: no-cache, must-revalidate
Expires: Mon, 31 Oct 2005 00:00:00 GMT
Content-Type: application/xml; charset=utf-8
Content-Encoding: gzip
Vary: Accept-Encoding
Connection: close
Transfer-Encoding: chunked
Date: Thu, 15 Dec 2011 18:00:35 GMT
for Mininova
source (snippet) from PB via FeedDemon is :
<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE torrent PUBLIC "-//bitTorrent//DTD torrent 0.1//EN" "http://xmlns.ezrss.it/0.1/dtd/">
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
<title>The Pirate Bay - Movies</title>
<link>http://thepiratebay.org/</link>
<description>The newest torrents from The Pirate Bay.org</description>
<language>en-us</language>
<pubDate>Thu, 15 Dec 2011 20:06:06 +0100</pubDate>
<lastBuildDate>Thu, 15 Dec 2011 20:06:06 +0100</lastBuildDate>
<docs>http://blogs.law.harvard.edu/tech/rss</docs>
<generator>TPB RSS Generator 1.2</generator>
<item>
<title><![CDATA[Fist.2.Fist.2011.DvDRip.XviD.Ac3-Feel-Free]]></title>
<link>http://torrents.thepiratebay.org/6890064/Fist.2.Fist.2011.DvDRip.XviD.Ac3-Feel-Free.6890064.TPB.torrent</link>
<comments>http://thepiratebay.org/torrent/6890064</comments>
<pubDate>Thu, 15 Dec 2011 18:51:37 +0100</pubDate>
<category domain="http://thepiratebay.org/browse/201"><![CDATA[Video / Movies]]></category>
<dc:creator><![CDATA[maximersk]]></dc:creator>
<guid>http://thepiratebay.org/torrent/6890064/</guid>
<enclosure url="http://torrents.thepiratebay.org/6890064/Fist.2.Fist.2011.DvDRip.XviD.Ac3-Feel-Free.6890064.TPB.torrent" length="23373" type="application/x-bittorrent" />
<torrent xmlns="http://xmlns.ezrss.it/0.1/">
<contentLength>1176360960</contentLength>
<infoHash>6EE0DFFF7DE46721987C1B4DA3D90DB18AF215C9</infoHash>
<magnetURI><!for mininova:
<?xml version="1.0" encoding="utf-8"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>Mininova</title>
<link>http://www.mininova.org/</link>
<description>Latest Mininova torrents</description>
<language>en-us</language>
<atom:link href="http://www.mininova.org/rss.php?chttp://www.mininova.org/rss.php?cat=1&recache=0%22%20at=1&recache=0%22%20%22%20rel=%22self%22%20type=%22application/rss+xml%22%20/%3e" rel="self" type="application/rss+xml" />
<item><title>DJ Dyce, DJ Cannon Banyon & DJ Effect present Apollo - Kakalak Kid</title><guid isPermaLink='true'>http://www.mininova.org/tor/13202670</guid><pubDate>Thu, 15 Dec 2011 19:31:29 +0100</pubDate><category>Music</category><link>http://www.mininova.org/tor/13202670</link><enclosure url="http://www.mininova.org/get/13202670" length="64192206" type="application/x-bittorrent" /><description><![CDATA[
Category: <a href="http://www.mininova.org/cat/5">Music</a><br />
Subcategory: <a href="http://www.mininova.org/sub/64">Hip Hop</a><br />
Size: 61.22 megabyte<br />
Ratio: 1 seeds, 4 leechers<br />
Language: <img src="http://mnstat.com./images/flags/us.gif" /> English<br /> -
build 26595 - still getting odd cases of single hashfails preventing the torrent from completeing, abd than clearing after a force recheck.
Som RSS feeds have stopped working, too.
http://rss.thepiratebay.org/201 returns nothing, although my feed reader shows plenty of content
http://www.mininova.org/rss.xml on the other hand is fine.
Only difference I can see is that mininova includes the xml pagein the URL, PB doesn't?
-
Hash fail is fixed as of 26563
Still not getting anything turning up in the RSS feeds I set up
Noticed there is a ghost bar in the 'from URL' box, across the bottom
-
I just had a torrent get stuck in RC3 (diskio.low_prio_disk = *false, if it matters) with two 1MB pieces (64 blocks each) left in cache. Status says "Flushing to disk (128)" but then they never get flushed, even though there is no other disk activity and it is the only active torrent.
Stuck Dump: http://www.mediafire.com/?drwz5e8q1jraa87
After I created the dump I restarted my other torrent, stopping the stuck torrent, and did a Force Recheck, which caused the program to hang. Let it go for awhile to see if it would be temporary but 3 hours later, still frozen.
Hang Dump: http://www.mediafire.com/?iuns6fghrl6vs5t
Also, please respond to the remaining items in my main post: http://forum.utorrent.com/viewtopic.php?pid=620310#p620310
Thank you.
build 26519 - getting the flushing issue with 12 x 16 blocks left = 192.
no hashfails, iskio_low_prio = true
No sign of heavy activity in disk, write stats show the cache is slowly growing, but virtually 0kbps on any meters. Only one other dl running at present, with very activity at present.
Stopping and forcing recheck locks UT up, leading to a forced app stop, restat and torrent is straight back to downloading, and last 12 pieces start downloading again and promptly finish in around 10 seconds. Looks like tythe flushing gets dropped and new copies of piiees cures the problem?.
-
26519 not looking any better than previous.......
-
New RC is refusing to download at the moment?
-
Amazed you've gone to RC1 with fundamental issues like hashfails and slow rechecks!
All still happening.
-
just had a force re-check jam on me. Seemed to stall part way through and max out the CPU. Not clear why yet as there was nothing different about it. The one I had to re-check for bad hashs after that was fine.
-
The RSS feeds don't seem to be doing much right now?
I've set up some from TPB, and they work in FeedDemon, but nothing at all appears via UT?
-
Let me try to have a guess here on that 99.9% issue... Since uTorrent tries to rename files at that point, why don't you try to set a "full control" security privileged to "everyone" on your download directory ?... Who knows...
If you mean the hashfails, and the last few getting stuck, no. The only reason it hits 99.9% is because a dozen hashfails are left behind at the end, which makes for about 99.9%. Until the recheck clears the hashes, its going nowhere, and you could just as easily do the recheck at 90%, have no more fails, and it finish without further issue.
-
Mm yeah, I take it all back, just had 3 torrents get stuck at 99%, 512kB piece size. Then when I stopped them and hit Force Recheck for all 3 µTorrent froze with Disk Overloaded 100%. Had to kill it in Task Manager... Reopened and it still has the crash bug of forgetting window width and torrent list height.. So yeah, reopening it started to redownload all 3 again, and of course Disk Overloaded 100% again.. 192/32mb on the Disk Statistics tab... not good, not good.
"Stuck" peices in Disk Cache + Force recheck = Hang.
Hang + Kill process = Forgotten window width and torrent list height.
Disk overload is definitely a µTorrent problem since I have paused all torrents except one and watched the write cache fill up to Disk Overloaded 100%, then I pause that torrent too. The Pieces tab stays full of completed pieces (32/32 blocks completed on many pieces) for ages, then, even though there is 0 other activitiy on this disk, it slowly writes them out, showing as sawteeth (from 0 to 128kB) on the right write graph (currently showing from 0 to 1). Is this a hashing issue? Why aren't these "finished pieces" getting written immediately as the Disk Cache options state? Looks like they're being written out as "untouched blocks" every 2 minutes instead, no?
You sure?
Doing a force recheck takes forever, but I haven't had a hang happen...
I often get messages about disk overloaded, but doesn't cause me a problem - I justr fugire the amount of data being dealt with is high?
-
Can you check if this happens when you set Pref.->advanced->diskio.use_partfile to false ? The torrent needs to be "added" as a new torrent again' date=' tho... [/quote']
Got a torrent again today which kept hanging at 99.x% even after changing that setting. Restarted uTorrent and the torrent finished near instantly.
Tried this, to no avail. Both torrent stills appear to be dropping their last few packets, and keep reverting back to about 99%. At least its not 97%!
Current workaround is to stop torrent, force recheck and start again.
Assumng you've caught all the pieces that are going to fail, it will finish. Otherwise ytou might have to do another stop/check/restart cycle later.
-
1) Torrent stuck on 99.9% for hours (with lots of seeders), only finishing after restart of the client.
Can you check if this happens when you set Pref.->advanced->diskio.use_partfile to false ? The torrent needs to be "added" as a new torrent again, tho...
(They might have screwed it up with this fix:
-- 2011-10-21: Version 3.1 beta (build 25835)
- Fix: Hang writing partfile for multifile torrent containing a file > 4GB
)
Yes it does. So safe to assume this is either a red herring, or has caused it, since current 3.0 build doesn't suffer the hashfail problem
-
On 26419 there is still the issue of torrents stuck on 99%-ish. Really bothers me... BTW piece size does not relate to this issue - I have issues with 1mb pieces.
hashfail issue has nothing to do with piece size, just the ocurance of any hashfails!
Haven't managed to find a bad torrent yet to test new build on, yet.
-
Do the alpha testers get more speed than others?
More speed at what?
-
Some updated info for you - I was downloading a larger than average torrent - about 10k pieces - yesterday and got a hashfail after a couple of hundred ok pieces. After that I was getting a steady cascade of hashfails' date=' until I removed and restarted the torrent, after which its carried on with no issues, and all the failed peices aresuddenly ok, and we're talking about 2500 of these! Almost like first hashfail mangles something about all the peices that come after it, even of they're ok?[/quote']
It could be. Could you try those same torrents with 3.0 and let us know if the same thing happens?
Thanks.
OK
Using build 25824 with torrent of 10k + pieces.
I'll let you know as soon as
UPDATE!!
10329 pieces, 82 hashfails (164Mb wasted)
10.1Gb downloaded in roughly 6 hours, completed
-
Whe you have to reset a torrent to kill the dud hashfails, the 'downloaded' value is zeroed and the ratio thus goes wrong, so you cannot tell when 1:5 or whatever has passed.
If it can work out what parts of the torrent have been downloaded ok, and which haven't, can't the 'downloaded' value be reset to be equivalent to that?
-
goatie
Maybe you either got a "poisoned torrent" as Firon says?
That was my first thought, but on each remove/restart, the bad pieces clear and the torrent behaves until the next hashfail.. The four torrents that have been affected so far have completed and are now seeding fine, having been reset a couple of times.
I've had poisoned torrents in the past where the fail count has been high, but these have never had to be abandoned.
The behavour here is too much like each failed piece gets stuck failing until the whole torrent is reset.
-
I've had this issue with 3 files now since updating to the latest build (25835)' date=' 2 from RSS, one from file. Downloads stop at 99.9% and seem to continually download and discard the last block. If I delete and re-add the torrent it checks it and begins seeding, so it at least appears the files are complete[/quote']
Thanks for testing and for this! We filed a bug.
Some updated info for you - I was downloading a larger than average torrent - about 10k pieces - yesterday and got a hashfail after a couple of hundred ok pieces. After that I was getting a steady cascade of hashfails, until I removed and restarted the torrent, after which its carried on with no issues, and all the failed peices aresuddenly ok, and we're talking about 2500 of these! Almost like first hashfail mangles something about all the peices that come after it, even of they're ok?
-
the alpha take too much of my cpu and thus needs to take less
Which build are you on? This seems to be ok with current.
-
As you start UT, the log window shows your own IP address being banned for being the same as an existing peer.
OK, this doesn't have any effect on downloads but is the kind of thing that could either hide other bugs or be the presented symptom?
-
I've had this issue with 3 files now since updating to the latest build (25835), 2 from RSS, one from file. Downloads stop at 99.9% and seem to continually download and discard the last block. If I delete and re-add the torrent it checks it and begins seeding, so it at least appears the files are complete
Getting this with 25835 - two recent downloads have stuck on last handful of pieces being rejected for bad hash, causing a number of IPs to be banned, even though each DL had scores of 100% IPs listed.
Now, I've had a few dodgy torrents in the past where the hashfails have been upwards of 50%, but they have always got there in the end, and never multiple fails on the last few pieces. This is certainly different.
#update# can confirm that removing the torrent and adding it back causes a complete check, which then confirms the last handful of failing pieces as OK, and the torrent starts seeding.
-
build 25788
Already posted about the continued memory leak, but just noticed there is a lag on the 'inactive' screen, where the number of visible torrents is left behind by the incative numbe falling, until you switch to another list and back again.
-
Hello. This release program is very large memory consumption. This is a permanent memory leak. After an hour of relaxed utorrent was consumed 250Megabayt and memory consumption are increasing.
P.S: 112 Torrent: 10 invalid, 80 completed and stopped, 22 active, 2-6 is always active.
My upload speed is usually about 2-4 Mbit \ sec. You have my attention for further development. Please release an update soon to fix a memory leak. Thank you.
http://img38.imageshack.us/img38/1494/20110918194942windows.jpg
http://img851.imageshack.us/img851/3159/20110918210535torrent3.th.jpg
build 25788 on windows 7 still has the memory leak.
I'm running five torrents, with two downloading at present. 190Mb on UT after a couple of hours.
26 peers on one, rest about a half dozen each, so not under heavy load of anything!
µTorrent 3.1 stable (build 26671)
in Announcements
Posted
Two of three PB ones are fine now, so I'd say yes!