Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Switeck

Pages: 1 ... 98 99 [100] 101 102
1486
Windows / Re: qBT 3.0.10 >500MB cache size can trigger crash + hashfails
« on: September 21, 2013, 08:03:15 AM »
Still crashes for me, but this time it happens around 1900-1950 MB ram used despite having the cache set to 1600 or 1700 MB.
Offset:  00252155

When I set the cache size limit to 1000 MB, qBT uses 1300 MB ram with only the single torrent loaded.

1487
Windows / Re: qBT 3.0.10 >500MB cache size can trigger crash + hashfails
« on: September 04, 2013, 05:11:19 AM »
One thing that I suspect is that libtorrent marks the cache as not swappable to pagefile/disk and maybe windows has a hard limit on that.
Were the trigger being a hard limit on non-swappable memory use in windows, that wouldn't explain why earlier versions of qBitTorrent could get to ~1650 MB of ram use before triggering the same "Not enough space" error.

1488
Windows / Re: qBT 3.0.10 >500MB cache size can trigger crash + hashfails
« on: September 03, 2013, 06:53:07 AM »
The procmon log was from shortly before but not during a ~530 MB memory use crash. That activity seems to be happening the whole time qBT runs, which really seems excessive.

I was seeding torrents not downloading them when these crashes occurred, so it is probably the read-side cache that's filling up.
Unless you have a combination of high upload speed (like >200 KiB/sec) and/or lots of peers/upload slots (like >30) that are trying to queue up 1+ MB at a time, you probably won't trigger the crash.
But a single peer in a 100 mbit/sec LAN test should be overkill.
And a loopback test can be done on a single computer if you can run 2 BitTorrent clients at once, where qBT acts as the seeder and the other one acts as the peer.

1489
Windows / Re: qBT 3.0.10 >500MB cache size can trigger crash + hashfails
« on: September 02, 2013, 05:24:59 PM »
I finally broke down and at least did a preliminary qBT test while running procmon. I was hoping to find a flagged event around the time of the memory overload/crash.
What I found may not be related... but I did find something rather odd:

3:09:06.5115596 AM   qbittorrent.exe   2732   QueryOpen   C:\Documents and Settings\Switeck\Application Data\qBittorrent\qBittorrent-resume.ini   SUCCESS   CreationTime: 7/13/2013 1:58:22 AM, LastAccessTime: 9/2/2013 3:07:23 AM, LastWriteTime: 9/2/2013 3:07:23 AM, ChangeTime: 9/2/2013 3:07:23 AM, AllocationSize: 4,096, EndOfFile: 759, FileAttributes: ANCI
3:09:06.5121887 AM   qbittorrent.exe   2732   QueryOpen   C:\Documents and Settings\Switeck\Application Data\qBittorrent.ini   NAME NOT FOUND   
3:09:06.5122778 AM   qbittorrent.exe   2732   CreateFile   C:\Documents and Settings\Switeck\Application Data\qBittorrent.ini   NAME NOT FOUND   Desired Access: Generic Read, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: Read, Write, AllocationSize: n/a
3:09:06.5123706 AM   qbittorrent.exe   2732   QueryOpen   C:\Documents and Settings\Switeck\Application Data\qBittorrent.ini   NAME NOT FOUND   
3:09:06.5130581 AM   qbittorrent.exe   2732   QueryOpen   C:\Documents and Settings\All Users\Application Data\qBittorrent\qBittorrent-resume.ini   PATH NOT FOUND   
3:09:06.5131045 AM   qbittorrent.exe   2732   CreateFile   C:\Documents and Settings\All Users\Application Data\qBittorrent\qBittorrent-resume.ini   PATH NOT FOUND   Desired Access: Generic Read, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: Read, Write, AllocationSize: n/a
3:09:06.5131796 AM   qbittorrent.exe   2732   QueryOpen   C:\Documents and Settings\All Users\Application Data\qBittorrent\qBittorrent-resume.ini   PATH NOT FOUND   
3:09:06.5138020 AM   qbittorrent.exe   2732   QueryOpen   C:\Documents and Settings\All Users\Application Data\qBittorrent.ini   NAME NOT FOUND   
3:09:06.5138646 AM   qbittorrent.exe   2732   CreateFile   C:\Documents and Settings\All Users\Application Data\qBittorrent.ini   NAME NOT FOUND   Desired Access: Generic Read, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: Read, Write, AllocationSize: n/a
3:09:06.5139283 AM   qbittorrent.exe   2732   QueryOpen   C:\Documents and Settings\All Users\Application Data\qBittorrent.ini   NAME NOT FOUND   
3:09:07.0151895 AM   qbittorrent.exe   2732   QueryOpen   C:\Documents and Settings\Switeck\Application Data\qBittorrent\qBittorrent-resume.ini   SUCCESS   CreationTime: 7/13/2013 1:58:22 AM, LastAccessTime: 9/2/2013 3:07:23 AM, LastWriteTime: 9/2/2013 3:07:23 AM, ChangeTime: 9/2/2013 3:07:23 AM, AllocationSize: 4,096, EndOfFile: 759, FileAttributes: ANCI
3:09:07.0159103 AM   qbittorrent.exe   2732   QueryOpen   C:\Documents and Settings\Switeck\Application Data\qBittorrent.ini   NAME NOT FOUND   
3:09:07.0159983 AM   qbittorrent.exe   2732   CreateFile   C:\Documents and Settings\Switeck\Application Data\qBittorrent.ini   NAME NOT FOUND   Desired Access: Generic Read, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: Read, Write, AllocationSize: n/a
3:09:07.0160935 AM   qbittorrent.exe   2732   QueryOpen   C:\Documents and Settings\Switeck\Application Data\qBittorrent.ini   NAME NOT FOUND   
3:09:07.0167045 AM   qbittorrent.exe   2732   QueryOpen   C:\Documents and Settings\All Users\Application Data\qBittorrent\qBittorrent-resume.ini   PATH NOT FOUND   
3:09:07.0167556 AM   qbittorrent.exe   2732   CreateFile   C:\Documents and Settings\All Users\Application Data\qBittorrent\qBittorrent-resume.ini   PATH NOT FOUND   Desired Access: Generic Read, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: Read, Write, AllocationSize: n/a
3:09:07.0168372 AM   qbittorrent.exe   2732   QueryOpen   C:\Documents and Settings\All Users\Application Data\qBittorrent\qBittorrent-resume.ini   PATH NOT FOUND   
3:09:07.0174174 AM   qbittorrent.exe   2732   QueryOpen   C:\Documents and Settings\All Users\Application Data\qBittorrent.ini   NAME NOT FOUND   
3:09:07.0174792 AM   qbittorrent.exe   2732   CreateFile   C:\Documents and Settings\All Users\Application Data\qBittorrent.ini   NAME NOT FOUND   Desired Access: Generic Read, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: Read, Write, AllocationSize: n/a
3:09:07.0175499 AM   qbittorrent.exe   2732   QueryOpen   C:\Documents and Settings\All Users\Application Data\qBittorrent.ini   NAME NOT FOUND   
3:09:07.5156084 AM   qbittorrent.exe   2732   QueryOpen   C:\Documents and Settings\Switeck\Application Data\qBittorrent\qBittorrent-resume.ini   SUCCESS   CreationTime: 7/13/2013 1:58:22 AM, LastAccessTime: 9/2/2013 3:07:23 AM, LastWriteTime: 9/2/2013 3:07:23 AM, ChangeTime: 9/2/2013 3:07:23 AM, AllocationSize: 4,096, EndOfFile: 759, FileAttributes: ANCI
3:09:07.5160241 AM   qbittorrent.exe   2732   QueryOpen   C:\Documents and Settings\Switeck\Application Data\qBittorrent.ini   NAME NOT FOUND   
3:09:07.5160940 AM   qbittorrent.exe   2732   CreateFile   C:\Documents and Settings\Switeck\Application Data\qBittorrent.ini   NAME NOT FOUND   Desired Access: Generic Read, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: Read, Write, AllocationSize: n/a
3:09:07.5161811 AM   qbittorrent.exe   2732   QueryOpen   C:\Documents and Settings\Switeck\Application Data\qBittorrent.ini   NAME NOT FOUND   

This is troublesome, because it may be a bug that qBT is trying to access qBittorrent.ini so often...and failing.
The actual location for qBittorrent.ini is:
C:\Documents and Settings\Switeck\Application Data\qBittorrent\qBittorrent.ini

Not
C:\Documents and Settings\Switeck\Application Data\qBittorrent.ini
or
C:\Documents and Settings\All Users\Application Data\qBittorrent.ini

Wrong file location pointers? Win XP-specific flaw? Windows-anything specific flaw?

Any chance all these failed file opens could be eating memory?
(They do seem to be occurring on 0.5 second intervals.)

1490
Windows / Re: qBT 3.0.10 >500MB cache size can trigger crash + hashfails
« on: September 02, 2013, 01:51:16 PM »
It's a case of I cannot duplicate on demand, only that it could rarely happen and I've seen it only 1 or 2 times in the past out of the 100's of 500+ MB memory overload attempts I've done.
I tried to trigger it again and failed. I'm sure it'll crop up again when I'm not trying.

What's important to me is that you personally have have managed to trigger the crash-to-desktop or at least the "Reason: Torrent file () error: Not enough space" via the testing method I laid out.
If you can see the problem "in action" as it were, you might have some more ideas for how to attack it, corner it, and defeat it.

1491
Windows / Re: qBT 3.0.10 >500MB cache size can trigger crash + hashfails
« on: September 02, 2013, 03:22:17 AM »
qBT still crashes, it's just not a crash-to-desktop:
When qBT 3.0.10 reaches ~530 MB ram used, I get this weird error message:
13/07/2013 04:57:34 - Reason: Torrent file () error: Not enough space
13/07/2013 04:57:34 - An I/O error occured, 'Torrent' paused.

And no, the app won't get to much greater than 530 MB...it probably won't even reach 550 MB at 50 MB/sec. Instead high speeds seem to make the crash more severe. It can still crash-to-desktop even without opening Options when that happens.
I've had to readd the torrent a few times because qBT forgot it after crashing under those extreme tests. :(

1492
Windows / Re: qBT 3.0.10 >500MB cache size can trigger crash + hashfails
« on: September 01, 2013, 01:07:25 PM »
Some details in how I triggered the bug:
http://qbforums.shiki.hu/index.php/topic,2042.msg7319.html#msg7319

Also, just before the ~530 MB threshold is reached, I attempt to open qBT's Options window with ALT+O. Without doing that final step, the odds of a complete qBT bomb-to-desktop crash is far lower. Timing is critical, I have to have Windows Task Manager open to the side to monitor qBT's memory use to trigger the crash reliably...plus I have to slow down qBT's upload from >10 MB/sec to about 1 MB/sec so it doesn't overshoot the ram trigger point before I can click. If I just let qBT run at 1 MB/sec the whole way, each test would take probably >10 minutes instead of <5 minutes.

You'll need the Disk Cache size set to >500 MB...preferably 1000-2000 MB.
Also, just to give you more time to trigger the bug, set Disk Cache Expiry Interval to 600 seconds (max allowed). Incidentally, 10 minutes seems really short for slowly downloading or uploading 4 MB pieces.

I was previously running torrents small enough to fit entirely within ram cache, so I figured I might as well take advantage of that when I triggered this bug in the first place. But for duplicating the bug, it's best to use 1 torrent of 2-5 GB size.

1493
Windows / Re: qBT 3.0.10 >500MB cache size can trigger crash + hashfails
« on: August 31, 2013, 09:02:31 PM »
Crash as usual, at the same memory level (~530 MB).

The debug log was somewhat long, so rather than flooding here I'm linking to it at pastebin:
http://pastebin.com/C2mWkg5R

1494
Windows / Re: Seeding
« on: August 23, 2013, 11:18:48 AM »
Only the newest versions of qBittorrent 3.1.0alpha allow more than ~8 global upload slots, regardless of "maximum upload slots" value.
Hopefully, either the upload slot fix is pushed into qBittorrent 3.0.11/12 or qBittorrent 3.1.0 is released soon.

1495
Windows / Re: qBT reporting 0 % progress in peer list.
« on: August 20, 2013, 11:53:00 PM »
I think this is related to the other peer. For example take a look at the 3rd peer. The progress says "80.8%" and upload "340.9MiB". This means that the progress shows how complete a torrent is for that peer. (the peer advertises this info).
Some clients have an option to NOT advertise that info, so they constantly show up as 0% complete. Until they become a seed, they're effectively leeches since no peer knows what pieces they can request from them.
The same clients that do that tend to also have the ability to rename their client id...so they can appear to be almost anything.

1496
Suggestions / Re: Configuration Assistan
« on: August 20, 2013, 11:46:40 PM »
1.Historically, incoming port for BitTorrent was from 6881-6900 ...however that was a convention rather than a BEP mandated default from what I understand.

6.Global upload slots is added as a configurable option in qBT 3.0.10 and/or qBT 3.1.0 alpha/beta...so that's another default setting to consider.
However that value is strongly tied to upload speed max.
Global upload slots should NEVER exceed total upload speed in KiB/sec.
Global upload slots should also be equal or greater than the number of active torrents that have peers, otherwise someone could leech torrents by setting global upload slots to 1 and upload speed to 1 KiB/sec and starting lots of torrents at once.

Beyond that, a fixed global upload slots value of 10 doesn't work well if total upload speed is >200 KiB/sec or <30 KiB/sec.
4 upload slots per torrent also suffers a bit outside those ranges, especially if too few or too many torrents are active at once.

1497
Suggestions / Re: Connections Per Torrent Within Client
« on: August 20, 2013, 10:40:32 PM »
Yes, although I'd go so far as say this is true for all seeding torrents.
A seeding torrent shouldn't be consuming lots of download bandwidth (at least relative to its upload amounts), nor need to connect to seeds, nor need to stay connected to lots of peers at once.
A seeding torrent can run ok with a max connections limit of only 10. That's so low it's almost silly for a downloading torrent, unless upload speed and possibly download speed too were <10 KiB/sec.
It's like the exact opposite goals of a downloading torrent...but most BitTorrent clients give both the same default settings.

Other BT clients have priority controls for torrents.
They often do so by giving a greater percentage of the total upload speed and total upload slots to "high" priority torrents, which may have no effect on download speed of overseeded torrents -- the very torrents "hogging" your bandwidth!

Torrent priority controls could easily get so complex and unworkable that even the developers don't fully understand how they interact. (See Vuze for an example.)
Another form of torrent priority is sequential downloading of the torrent's files and pieces. This too can serve to reduce the torrent's download speed and increase the rarity of pieces only seeds have, as many seeds are set to leave after they upload 100-200% of the torrent's size even if that means doing the first part of the torrent many times over. Tixati combines "regular" torrent priority (9 different levels in fact) with "sequential, on/off/aggressive" and "front and back first". Seems too much to adjust and setting highest priority on 1 torrent may mean every other torrent's upload slots run at <0.5 KiB/sec resulting in lots of BT clients auto-snubbing yours!

1498
Suggestions / Re: Connections Per Torrent Within Client
« on: August 20, 2013, 01:18:29 PM »
To me, this request is about torrent priority -- giving one torrent more connections and hopefully more download/upload speed as a result.
So as a means to a useful end...it's a decent idea.

As each downloading torrent finishes and starts seeding, I'd want to lower its max connection limit from something like 50-100 down to only 5-20.
No sense staying connected to 50-100 peers anymore if I'm only going to upload to 4-10 at a time and I'm not using strict super seeding. Saves bandwidth.

1499
Suggestions / Re: Configuration Assistan
« on: August 20, 2013, 12:09:07 PM »
qBT's default settings have issues which precludes me from recommending them as a good starting point.

1.Default of port 6881? ...many ISPs block or throttle that.
2.500 global connections max? Lots of networking will run into problems with that!
3.100 connections per torrent? Even for seeds that only upload to 4 (upload slots) people at a time?!
4.50 KB/sec default max upload speed?  That's not balanced with the other settings, and likely won't match the average user's line.
5.50 max half open connections?! Nevermind that certain Windows OSes limit to 10, 50 is insane/excessive unless you're trying to connect to 100's of torrents at once on a 100 mbit/sec or faster direct fiber optic line on a very powerful server computer.
6.qBT v3.0.8 and v3.0.9 (and perhaps earlier!) refuses to use more than 8-10 GLOBAL upload slots. This makes it less-than-optimal on a fast line with >200 KiB/sec upload speed and potentially crippled beyond ~1000 KiB/sec upload.

1500
Load-balancing would have to be done by the OS, which could be a mess if there's only a few connected peers/seeds.
It might be even harder to get private trackers to work with multi-WAN connection peers/seeds, because such peer/seeds would appear multiple times as different ips. (one for each WAN connection)

Pages: 1 ... 98 99 [100] 101 102