Author Topic: [unofficial]qBittorrent git master builds: 3.3.0alpha_20150621_5e400d31174  (Read 17444 times)

Nemo

  • qBittorrent Forum
  • Administrator
  • Forum addict
  • *****
  • Posts: 1467
  • Karma: +90/-0
    • View Profile
Very stable indeed, replaced v3.2.0 for me as my new stable. Few small issues.. Well which program doesn't have it :). New features and optimizations can bring new small issues with it also. Overall it works great just like any alpha/beta.
Forum Rules and Guidelines

Forum Admin.
Dutch & Turkish Translator.




tekko

  • Guest
IMO, there's enough important updates for the next alpha release. i.e. torrent states, trackers, resume data, torrent renaming, etc.

DarkeningNightofSofia

  • Newbie
  • *
  • Posts: 3
  • Karma: +0/-0
    • View Profile
I think I found the reason what was causing "stopped responding" message, when I change "Transfer list refresh interval" to 1000ms instead of default 1500ms qBittorrent might stop responding. This happens with every qBittorrent release so far. If I keep it on 1500ms which is default then qBittorrent is very smooth and doesn't stop responding. So I think 1000ms will inject too much information at the same time to qBittorrent which then causes lag or something. Even though I have 3x ssd on RAID0 which gives 1500/1000 speeds, 500ms difference is not that big of a deal anyway.

tekko

  • Guest
With 3.2.x, it happens to me even at 3000ms...

sledgehammer_999

  • qBittorrent maintainer
  • Administrator
  • Forum addict
  • *****
  • Posts: 2397
  • Karma: +148/-1
    • View Profile
Here is a build of qBittorrent 3.3.0alpha sha1 5e400d31174 from git master with:
boost 1.55
libtorrent 1.0.6
qt: 4.8.7

Built using msvc2013

Git changelog from last alpha: https://github.com/qbittorrent/qBittorrent/compare/2e6c890883d2a290426ace1c8abf5fc4a2b2944e...5e400d311746b1f5595e358fbae8bf149c74217e

BIG FAT WARNING
The v3.3.x series have a new saving system for torrent progress. It isn't backwards compatible with pre v3.3.0 versions. You'll be presented with a message box to migrate to the new system. If you continue there is not going back.

Not really
You can go back if first you go to the BT_backup folder and remove the trailing "dot number" from the fastresume names. This could break in future releases though.

Link 1: http://www.fosshub.com/qBittorrent.html
Link 2: http://builds.shiki.hu/qbittorrent_3.3.0alpha_20150621_5e400d31174_setup.exe

tekko

  • Guest
Nice, thanks.
Why not just forget about v3.2.x and concentrate on v3.3.x ?
3.3.x is so much smoother, no freezing every few clicks.
« Last Edit: July 14, 2015, 11:51:54 AM by tekko »

coolio2013

  • Member
  • **
  • Posts: 20
  • Karma: +1/-0
    • View Profile
I was also surprised to see a new 3.2.1...

In general both 3.3alphas are really well done. It would be great to have versions with some distinguishing version numbers (3.1.1.1, 3.3alpha2 or something)...


What is really bugging me on the last 3.2alphas/betas and 3.3alphas is the following:

a.
As soon as the connection is interrupted, QBT will not come on again and pick up traffic. The only way to get traffic is restarting QBT.
In 3.1 (afair) it was possible to get back traffic by changing the port, this doesn't work any more.

b.
This may take a lot of time (on my setup with network shares), I always have to kill QBT in this status. 30minutes of waiting after the last .fastresume has been written should be sufficient, right? Also SystemInternals process explorer (nor SI's process monitor) doesn't show any activity then, just a few contect switches and only some internal packets of network traffic.

This should be easily repeatable with 5 minutes without network, be it a VPN, WiFi or LAN, ESPECIALLY if a certain network interface is set in Advanced settings.

Could someone please confirm this? I'm on WinXP-32.

Cheers!
« Last Edit: July 15, 2015, 11:58:35 PM by coolio2013 »

Nemo

  • qBittorrent Forum
  • Administrator
  • Forum addict
  • *****
  • Posts: 1467
  • Karma: +90/-0
    • View Profile
Thanks for the new alpha build sledge.
« Last Edit: July 16, 2015, 01:21:12 PM by Nemo »
Forum Rules and Guidelines

Forum Admin.
Dutch & Turkish Translator.




DarkeningNightofSofia

  • Newbie
  • *
  • Posts: 3
  • Karma: +0/-0
    • View Profile
When we can expect x64 portable version of qBittorrent 3.3.0? I would be happy to test that out and inform possible bugs.

jeps

  • Veteran
  • ***
  • Posts: 78
  • Karma: +2/-0
    • View Profile
Hi!

So qBittorrent finally got the "store torrent on mapped network" working, so I can start using it again, yeah!

I have discovered what must be a qBittorrent bug.
When I download a torrent made with several RAR files, one or more of the RAR files are corrupt.
(the same thing doesn't happen with single files, they are always working,)
I then force qBittorrent to recheck, it finds the error and re-downloads the pieces, but... the same RAR file is still corrupt.
When I then load the same torrent in µTorrent it finds the same error and re-downloads the faulty piece(s), and this time the RAR files are working.
This happens whether or not I have preallocate files enabled or not.

Can someone confirm this bug?

PS.
It is annoying, that saved .torrent files aren't saved with their "real" names.
It makes it complete impossible to do some clean-up in files not needed.
(that is probably a request  :) )
« Last Edit: July 19, 2015, 11:57:11 AM by jeps »

sledgehammer_999

  • qBittorrent maintainer
  • Administrator
  • Forum addict
  • *****
  • Posts: 2397
  • Karma: +148/-1
    • View Profile
Hi!

So qBittorrent finally got the "store torrent on mapped network" working, so I can start using it again, yeah!

I have discovered what must be a qBittorrent bug.
When I download a torrent made with several RAR files, one or more of the RAR files are corrupt.
(the same thing doesn't happen with single files, they are always working,)
I then force qBittorrent to recheck, it finds the error and re-downloads the pieces, but... the same RAR file is still corrupt.
When I then load the same torrent in µTorrent it finds the same error and re-downloads the faulty piece(s), and this time the RAR files are working.
This happens whether or not I have preallocate files enabled or not.

Can someone confirm this bug?

PS.
It is annoying, that saved .torrent files aren't saved with their "real" names.
It makes it complete impossible to do some clean-up in files not needed.
(that is probably a request  :) )

I don't understand in the begining you say tha mapped networking works but then you say RARs don't work... What is happening? Are they 2 unrelated issues?

Saved torrents(in the BT_backup folder) are removed by qbt when you remove the torrent from the transferlist. No need for self cleanup.
They use the torrent hash as name. You can see your torrent's hash from the "General" button in the bottom of the qbt mainwindow.

jeps

  • Veteran
  • ***
  • Posts: 78
  • Karma: +2/-0
    • View Profile
The mapped network drive works - in the way that they don't give "fatal I/O errors anymore".

The error I have experienced (now in 2 multi-file (.RAR) - torrents) is as I describe.
qBittorent basically corrupts data in RAR files (the only type that makes a check when you unpack the files I have tried).
I don't know if the same corruption occurs in other file types as-well.

It is not the BT_Back folder I am worried about, it's the folder you use when you enable "copy .torrent file to".
Lets say, like in my check of the file corruption, that I would like to use another bittorrent program.
I would then like to simply load the .torrent file from my own ".torrent folder", but that is impossible given the names they have got.
I am pretty sure, that earlier versions of qBittorrent didn't work that way.
 

sledgehammer_999

  • qBittorrent maintainer
  • Administrator
  • Forum addict
  • *****
  • Posts: 2397
  • Karma: +148/-1
    • View Profile
The mapped network drive works - in the way that they don't give "fatal I/O errors anymore".

The error I have experienced (now in 2 multi-file (.RAR) - torrents) is as I describe.
qBittorent basically corrupts data in RAR files (the only type that makes a check when you unpack the files I have tried).
I don't know if the same corruption occurs in other file types as-well.

It is not the BT_Back folder I am worried about, it's the folder you use when you enable "copy .torrent file to".
Lets say, like in my check of the file corruption, that I would like to use another bittorrent program.
I would then like to simply load the .torrent file from my own ".torrent folder", but that is impossible given the names they have got.
I am pretty sure, that earlier versions of qBittorrent didn't work that way.

Are the RARs saved to a mapped drive? If yes, try saving them to a local drive and see if the corruption persists.
About the exported metadata: What is their name? <infohash>.torrent ?

jeps

  • Veteran
  • ***
  • Posts: 78
  • Karma: +2/-0
    • View Profile
"Their names" is something like "TV show S01E02" = something readable for humans
What I don't want is the hexadecimal name, which don't say sh.. to ordinary people.

I will try and download a torrent to a local drive, but can you confirm the bug when qBittorrent saves to a mapped network drive?
As I explained earlier, I did download the same torrent (that failed in qBittorrent) in µTorrent.
µTorrent found the corruption that qBittorrent had saved, but also managed to download and save the pieces without corruption (unlike qBittorrent).
qBittorrent did find the corruption in a re-check, downloaded the pieces again and then saved a corrupt version again.

jeps

  • Veteran
  • ***
  • Posts: 78
  • Karma: +2/-0
    • View Profile
Okay, so now I tried downloading the exact same torrent, but this time to a local drive.
The .RAR files was not corrupt in this scenario.