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 - gspbeetle

Pages: [1] 2
1
Same, auto shutdown on Windows 10 after a few days using 4.1.6 at startup and the 'fix' does not work either.
Happens when memory build up to around 2300-2400mb (on 4.1.5 qB uses >3000mb memory).
Download to 4.1.5 and works fine again, so the database is not corrupted.
Most likely related when running qB with alot of tasks (thats probably the reason why we need x64 anyway).

2
Windows / Re: Option to not show myself in Peers list?
« on: August 19, 2018, 09:14:38 AM »
4.1.2 still show myself 2 time in peer list, one is DNS gate (192.168.1.1) and the other one is my ISP IP.

It seems 4.0.3 already have this.

3.4.0 does not have this issue.

Most likely qt side.

3
Windows / Option to not show myself in Peers list?
« on: July 27, 2018, 02:08:11 PM »
The one appeared twice using qBittorrent 4.1.1 with port 6881 is myself.
Does not affect the tasks but do look weird.
Is it possible to hide the loop back in qB 4.0+?

4
Windows / Re: Saving torrent progress, shutdown aborted
« on: November 20, 2017, 01:06:14 PM »
Yes, it has been like that for qB with alot of tasks, since... I don't know when. (v3.2 I think?)
Just force shutdown anyway, it shouldn't break anything.

5
Windows - QA Department / Re: Unofficial 64-bit installer/archive 3.3.x
« on: November 10, 2016, 03:15:56 PM »
x64 version actually works quite well with those ridiculously fast XMP DDR4s out there.
So far, when in profile 1 (2800mhz), it significantly improved the startup time (the time need for the add task windows appear when qb is startup by opening up a .torrent) and shutdown time (the time qb stays at background cleaning up garbage after told to exit) for a client with over 2000 tasks.
When in non-oc mode (2133mhz)[...]

You know xmp is just a profile to make the memory run as per manufacturer specs? instead of setting it up manually which would scare people away. xmp is not an oc mode or anything like that. Also, mhz isn't everything, there's a bucketload of sub features for memory that can make them slow.

Yes, manufacturer specified clock, but nevertheless it is still overclocked since the clock is in fact increased.
(In my case, I have to tune up my bclk slightly in order for xmp to run at 2800mhz with my i5-6500)
I know XMP isnt exactly new technology, but it wasn't that cheap and ridiculously fast when we were in the DDR3 era.

And yes, I agree that "mhz isn't everything", that's exactly the reason why I am being surprised by the performance boost it actually outputs.
I didn't really expect it to reduce the shutdown time of qb at all when I bought those memory modules, and these memory are not gamer graded either, they got a rather high CL rating (16).

6
Windows - QA Department / Re: Unofficial 64-bit installer/archive 3.3.x
« on: November 09, 2016, 03:41:33 PM »
x64 version actually works quite well with those ridiculously fast XMP DDR4s out there.
So far, when in profile 1 (2800mhz), it significantly improved the startup time (the time need for the add task windows appear when qb is startup by opening up a .torrent) and shutdown time (the time qb stays at background cleaning up garbage after told to exit) for a client with over 2000 tasks.
When in non-oc mode (2133mhz) with the same memory module, it would take around 8 minutes for qb to completely exit, in xmp mode it takes around 3 minutes to complete the cycle. It is kind of unexpected. The run time, active speed, cache, memory usage etc is of similar value of cause, but I havnt got alot of samples to proof it either.

7
Windows / Re: 3.3.6 often becomes unresponsive during high speed transfers.
« on: September 20, 2016, 06:52:24 PM »
x64 is "unofficial" they say, no idea what does that means.

I have a much lower transfer rate (10-15Mibps) with around 2000 seeding tasks, usually 200 active, but the average ram usage is similar (1.2Gb - 1.5Gb).

But I have to use x64 too, not really qb's fault but its the limitation of x86...

I remember that when Win10 anniversary update was released, qb can cause a huge memory leak, but that was due to Killer's faulty networking drivers.

8
Bittorrent in theory should not care it is downloaded or simply copied, qB can detect that change and move to re-check automatically.
I am doing this automatically since I am also running deluge in parallel (for seeding only), just in case any of the client crashed and interrupting the seeding to the hive.
But for some reason, the 32-bit version of qB will most likely crash, only the 64-bit version will survive this massive re-checks.

I am not sure is this a feature as well (most likely not intended), but when I migrate qB progress to another machine by copying everything in the BT_backup folder only (%Userprofile%\AppData\Local\qBittorrent\BT_backup), it will not recheck the files and go seeding immediately; given that the file path is the same of cause.
But even the file path doesn't match, it will just simply show as "Errored" without any issues.

9
Windows / Re: My Experiences With 3.3.4 & 3.3.5
« on: July 09, 2016, 04:40:14 PM »
Just use 3.3.4 for Windows for now.

10
Windows / Re: web access , need help
« on: November 10, 2015, 02:24:56 PM »
I think he used dyndns for address.

Edit:  if you are running windows 10, you may have to set "word wide web publishing service" to manual (from automatic) in "services.msc", since this bloatware from m$ occupies port 80 & 8080 for no good reason.

11
Windows / Re: New torrents showing as "stalled" in version 3.2.5
« on: November 09, 2015, 03:23:28 PM »
Did 3.2.3 worked for you?

If yes, you can try downgrade to 3.2.11, run once, then exit.
(http://sourceforge.net/projects/qbittorrent/files/qbittorrent-win32/)
Then upgrade back to 3.2.5 and try to see if it works ok or not.

It happens there are some sort of config corruption during upgrading from 3.2.4 -> 3.2.5. (happened before during 3.2.4 deployment)

12
Windows / Re: QQDownload?
« on: October 07, 2015, 08:43:03 AM »
I don't know the cause of it, since there are countless successful upload of the same client; nor I don't think the devs for QQdownload will care (it is a bloatware full of PUPs claimed to be "lightweight without ads")...

But I do think it is a concern for us qBittorrent as well, uploading 4GiB worth of data from a 400MiB file does not seems logical at least.

But either way, perhaps we can schedule a prevention to safeguard this issue from future releases, i guess.

Not something urgent thou, since we can still manually ban them, if we can spot one....

13
Windows / Re: QQDownload?
« on: October 06, 2015, 12:52:16 PM »
Quote
But the thing is, we shouldn't be uploading over 10x data to any single client.
Depends on how many pieces that are being rejected/dropped by that particular peer because of some problem at the remote end.

Why not? It is not something that your client is in control of. Do your client stats (properties panel)  show that you HAVE uploaded almost 7GiB for that particular task??

Yes, actually alot more than that since that torrent has alot of peers and transfers, so that cannot prove anything, I guess. (48GiB over 9 hours)

However, I did observed for an extra hour before I banned them for good, these two clients have been constantly transfering at this rate for the whole hour.  Which for the 200KiB/s client should have completed 400MiB file 2 times.

14
Windows / QQDownload?
« on: October 05, 2015, 03:24:42 AM »
Have anyone share the same experience that recently QQDownload seems buggy and eating bandwith endlessly?

For example at screenshot below, I have uploaded 2.3GB & 4.6GB worth of data over hours, while the actual file is only 450MBs and "wasted" only shows around 20mbs.

There are alot of other instance of the same problem, all having 99.8% progress and the client are also QQDownload.

But the thing is, we shouldn't be uploading over 10x data to any single client.


15
Windows / Re: 3.2.0 problem in searching peers
« on: May 24, 2015, 03:40:06 AM »
No problems here 3.2.0 RC1

Thats true, RC1-4 dont have any issues, but RCs didnt use the new lib and interface that the stable version currently running.

Settings are reseted on every setup, the only thing i have changed is the connection ports and removing the connection/speed limit.

Interestingly, RC 5 shows DHT 'disabled' and title is blanked if using magnet link.
However in release version, DHT shows 'working' again and title become hash, but still no help.

EDIT: After disable encryption, issue resolved. (although it looks more random to me and doesn't seem to make sense)

Current settings:
Listening port:
UPnP/NAT - disabled (not supported)
Connection limits:
Global maximum - 2000
Max per torrent - 100
Max upload slots - 20
Max upload per torrent - 10
Global rate limits
Upload - unlimited
Download - unlimited
Enable uTP - checked
(Others n/a, due to no rate limits)
Privacy:
DHT - checked
PeX - checked
LSD - checked
Encryption mode -> disabled
Advanced:
Max half open connections: 100

Pages: [1] 2