Feedback on Tixati v2.35 Alpha-1 - Help and Support

Help and Support
Ask a question, report a problem, request a feature...
<< Back To Forum

Feedback on Tixati v2.35 Alpha-1

by Bugmagnet on 2016/03/31 11:53:12 PM

It is early into the testing, but so far the channel chat for the new beta version is positive. Most are finding it more responsive.

On restart, with seeding 1900+, it took less than 2 minutes to reach full UL BW of 1024 KiB/s.

sweet!

by Bugmagnet on 2016/04/01 03:02:28 PM

After more testing, on windows 7 Pro 64 bit, I confirmed that a huge DL level no longer decimates my UL speeds.

Under v2.28, a DL of about 20 Mib/s would cause my UL to drop by 75%. With v2.35a1, I can nearly max out my entire ISP DL level, flatlining my tixati limit cap set at 6144 KiB/s (48 Mib/s), while my UL BW drops only about 5%. A HUGE improvement since v2.28. I would attribute some of that to incremental changes between v2.28 and 2.34, but v2.35a1 is the icing on the cake. So Sweet!

http://imgur.com/a/1Gr22

So far, I haven't personally observed any behavior with this new beta that I would consider a bug. That is on Windows though.

Another user in our tix Help and Support channel has detected what appears to be a bug, a design flaw, on the linux version. When they click on the Gear icon to open tixati settings, it takes 5 seconds or so for it to appear and during that time all UL and DL transfers and channel traffic are halted. Video link sent to the DEV.

How's your testing coming? If you find any unusual behavior during this beta testing period, please add a post about it to this thread.

Viva Tixati!

by Bugmagnet on 2016/04/03 02:53:38 AM

finally found a bug I think.

I downloaded several torrents which were assigned a category. I had custom preset file locations for both download and seeding when completed for that category.

After download, the files were not moved to the seeding folder.

by Guest on 2016/04/03 02:07:12 PM

Alpha-1 continues to redownload pieces of torrents I've long since downloaded and been seeding in previous versions of tixati for months.

by Bugmagnet on 2016/04/03 05:37:48 PM

Guest, can you please list the OS platform you are using when experiencing this behavior?

I am using windows 7 pro 64 bit and seeding 1600+ torrents and I don't see any repeated pieces at all.

by YandereKate on 2016/04/03 06:21:16 PM

Linux 4.5 here and none of my torrents are redownloading either

by Guest on 2016/04/03 07:39:55 PM

I found a Bug..(or at least I think so)

how to reproduce:
1. open Tixati and join/start the Channel Books
2. rightclick a user with a high number of shares (40.000+) and click browse. (loading the complete list from these users takes a long time being in the channel !!)
3. when the browse window opens, one of the cpu-cores will go to 100 % usage and it will kill the bandwidth until the browse window is finished loading all the shares.
4. after it has opened and loaded the window, one of the cpu-cores will spike at 100% every 7 seconds, the bandwidth looks also affected.
5. close the browse window and all is well again.

see pictures for more explanation (you are looking at the gnome system monitor): http://imgur.com/a/FBptB

what I would like to see:
high cpu usage only once (when loading the massive list) not every x seconds after that :-)

my system specs:
tixati 64bit package v2.35a-1
linux 64 bit - Debian Jessie (8) with Gnome
intel dual core cpu
4gb ram

Keep up the good work :-D

by Bugmagnet on 2016/04/04 02:25:06 AM

On learning of this Browse bug on linux, I decided to test on my Windows 7 64 bit platform, since another bug reported earlier seemed to affect the linux version only. This bug affects windows also.

Image album showing affects on CPUsage, TCP and more is at: http://imgur.com/a/DJsdT

by YandereKate on 2016/04/04 03:32:57 AM

I found a Bug..(or at least I think so)

how to reproduce:
1. open Tixati and join/start the Channel Books
2. rightclick a user with a high number of shares (40.000+) and click browse. (loading the complete list from these users takes a long time being in the channel !!)
3. when the browse window opens, one of the cpu-cores will go to 100 % usage and it will kill the bandwidth until the browse window is finished loading all the shares.
4. after it has opened and loaded the window, one of the cpu-cores will spike at 100% every 7 seconds, the bandwidth looks also affected.
5. close the browse window and all is well again.

see pictures for more explanation (you are looking at the gnome system monitor): http://imgur.com/a/FBptB

what I would like to see:
high cpu usage only once (when loading the massive list) not every x seconds after that :-)

my system specs:
tixati 64bit package v2.35a-1
linux 64 bit - Debian Jessie (8) with Gnome
intel dual core cpu
4gb ram

I can confirm on OpenSUSE Tumbleweed, Linux 4.5, KDE/Plasma 5, 16GB RAM, AMD FX(tm)-8320 Eight-Core Processor
http://i.imgur.com/cNVxouD.png

by Guest on 2016/04/04 01:36:09 PM

win 7 x64, still continues to redownload 1% of 2 random torrents.

by Guest on 2016/04/04 05:47:27 PM

by Guest on Mon, 04 Apr 2016 11:36:09 GMT
win 7 x64, still continues to redownload 1% of 2 random torrents.

send those torrents to devs. support at tixati dot com

by Bugmagnet on 2016/04/04 07:19:50 PM

by Guest on Mon, 04 Apr 2016 11:36:09 GMT
win 7 x64, still continues to redownload 1% of 2 random torrents.

Please provide more details as to your OS and hardware..

As I stated earlier, I also am using win 7 pro 64 bit, and though seeding 1800+ torrents I do not see any that are re-downloading pieces. It may be that you have a couple corrupt torrents or files.

As another 'guest' suggested, it might be necessary to send the torrent links to the DEVteam if no one else can confirm the problem you are experiencing.

Have you rolled back to prior versions to test for when this behavior was not present? If you can do that it might help isolate the underlying cause.

by Bugmagnet on 2016/04/05 11:29:58 AM

New Bug: torrent with multiple files which on which a shell command operates on completion fails to move to the seeding folder.

win7 pro 64 bit

I have this shell command on .avi file completion:
.avi:ffmpeg -i %1 "E:\Converted\$name+avi2.mp4"

Settings call for moving the torrent on completion from my "incoming" folder to my "finished" folder, both on the same HDD

Downloading a torrent containing a single .avi file was moved without error.

Downloading a torrent containing 3 .avi files failed with: error fast-moving folder: Access denied (5)

In the latter case, 2 of the avi files had the same exact creation and modification times, indicating that multiple instances of ffmpeg were running simultaneously. Conversion of all 3 files was successful, but contents of the torrent remained in the incoming/incomplete folder.

Performing a "force check" later on the torrent resulted in 100% but the contents were not moved. I had to manually move it.

Add Reply

<< Back To Forum