[unofficial]qBittorrent git master builds: 3.3.0beta_20151109_c40bab05550

[Nemo]

If im right sledge is away for a little while (seeing his last Github activity was 9 days ago). Im sure we will get a new beta soon when he returns.

Thanks for your understanding and patience.

[Inwoods]

I notice 3.2 is still getting updates; are beta users missing anything good?  Sorta hard to roll back.  Or is 3.3 coming to release soon?

[sledgehammer_999]

[quote="Inwoods"]
I notice 3.2 is still getting updates; are beta users missing anything good?  Sorta hard to roll back.  Or is 3.3 coming to release soon?
[/quote]

https://github.com/qbittorrent/qBittorrent/issues/3800

[fusk]

Also looking for a newer build. Found a bug where using a temp drive makes qbit copy every download back onto the temp drive when windows starts.
So qbit first downloads to temp, then moves to destination. After computer restart it will copy from destination to temp drive. Even tho save path is not the temp drive.

[Inwoods]

I wonder if the client is not closing "well" and needs to recheck those torrents?

Even so, mocing them back into temp to do that seems a bad idea.

[sledgehammer_999]

I'll produce a new beta build soon enough. I discovered a regression with a recent merge, which is probably fixed already by another merge. But I need to do some testing tomorrow to make sure that it was fixed.

[tekko]

[quote="sledgehammer_999"]
I'll produce a new beta build soon enough. I discovered a regression with a recent merge, which is probably fixed already by another merge. But I need to do some testing tomorrow to make sure that it was fixed.
[/quote]

Thanks, take your time... I rather have a good working one.

[Nemo]

My intention is to make Qt5 the default if #2835 is resolved

How goes the progress to use Qt5 as a standard sledge?

qBittorrent v3.2.4 x64 build with Qt5 from Dayman runs fine (attached image).

[fusk]

[quote="Inwoods"]
I wonder if the client is not closing "well" and needs to recheck those torrents?

Even so, mocing them back into temp to do that seems a bad idea.
[/quote]

It doesn't recheck them, it just continues seeding, but gives errors when drive is full. I had to disable the temp drive, then everything seems to be normal again.

[sledgehammer_999]

Here is a build of qBittorrent 3.3.0beta sha1 3a29d70dd55 from git master with:
boost 1.55
libtorrent 1.0.6(git 7db599babdf80a)
qt: 4.8.7

Built using msvc2013

Git changelog from last beta: https://github.com/qbittorrent/qBittorr ... 216c9698f6

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(only as fallback): http://builds.shiki.hu/qbittorrent_3.3. ... _setup.exe

[Inwoods]

One thing I'm noticing right away from the last build (and this was a long standing problem I had even before 3.2) is that the "tracker" column now populates correctly.  It used to leave blanks, and the torrent would show "not contacted" for the trackers when you clicked on it.  Even hours later, it never got around to trying to "contact."

Seems to act normally now.

I don't remember seeing a note in the changes, just wanted to say it seems fixed.

[tekko]

I back up the "BT_backup" folder manually and noticed that the number after .fastresume changes. In what cases do they get changed?

Thank for the new beta.

[sledgehammer_999]

[quote="tekko"]
I back up the "BT_backup" folder manually and noticed that the number after .fastresume changes. In what cases do they get changed?
[/quote]

The number after resume denotes the queue number in the transferlist. I think for seeding torrents that number is always 0.

EDIT: the naming scheme is: <infohash>.fastresume.<queuenumber>

[fusk]

The date bug seems fixed too. When updating from 3.2 to 3.3 the torrents was reported as added in 1970. But those added after the update were correct. Now they're all correct.
Have not tested the temp drive issue i had, yet.

[dominoto]

I was so happy to see "Use proxy only for torrents" option in the new build. Thanks pmzqla and sledge!