torrent ratio excessively high

[antikythera]

I am using the GTK version of 2.84 (14307) on Fedora 21 32-bit MATE-Compiz spin.

I am seeding ​http://torrent.fedoraproject.org/torrents/Fedora-Live-MATE_Compiz-i686-21.torrent. To save downloading it again because I already got the files from mirrorservice.org I created the Folder Fedora-Live-MATE_Compiz-i686-21 manually and placed the required ISO and checksum files in it. Then I loaded transmission and verified the local files. It did that fine and seeding started.

The ratio however is ridiculously high. Since install it has been increasing faster than it should. I tried clearing transmission cache files with bleachbit and it only made it worse, not better.

For example the torrent file size is 1.02GB. The uploaded data is currently 878.9MB. The total ratio (I am not seeding any other torrents and have not done so since a fresh install of Fedora 21) is showing 568. for the session today it is 94.3 after uploading 146MB.

from the Fedora 2.84-2.fc21 package changelog:

• 2014-08-18 Fedora Release Engineering <rel-eng@…> - 2.84-2
• Rebuilt for ​https://fedoraproject.org/wiki/Fedora_21_22_Mass_Rebuild

Please let me know if you need any further information

[cfpp2p]

I tried clearing transmission cache files with bleachbit and it only made it worse, not better.

bleachbit has a bug.

​https://github.com/az0/bleachbit/issues/46

[antikythera]

Yes, that bug report was submitted by mike.dld as a result of our discussion

[antikythera]

Hello, one cause of the ratio issue has been resolved. I went on your IRC channel and mike.dld answered my questions. Here is a summary of the main discussion we had:

_

I've established the cause of the ratio problem with some assistance tonight. bleachbit has a transmission cache clearing function. On #transmission IRC with the extremely helpful mikedld I asked about the files it was deleting.

In summary of the chat he explained what this script does and which deleted files are causing the problem.

​https://github.com/az0/bleachbit/blo...ansmission.xml

blocklist folder - contains the files storing the blocklisted IP addresses. if a user creates or adds their own in addition urls specified in the program they will be removed by bleachbit and lost.

resume folder - this is what messes up the stats, in particular the ratio. these files should not be deleted if you want the stats to work normally and ratio to be accurate.

I think after reading mike's explanations I believe it is therefore best to leave Transmission 'cache' cleaning unticked in bleachbit. The size of files removed is minimal and really not worth the hassle.

mike is kindly reporting this back to the bleachbit developers. I don't know if they will make any changes based on his report to them. I hope so. even if it was the inclusion of an on-screen warning it would help.

_

However, there is still an issue with session and total ratio calculation.

I thought the progam would total the ratio figure from the individual torrents.

e.g Libreoffice has 0.2, Fedora MATE 0.3 and A N Other 0.75 would equal a total of 1.25

This does not seem to be the case. But it really should be. Let me explain.

I believe currently it is just done off the total data sent and received in stats.json. Which is consequently giving the 'high' total ratio figure. Not all the torrents are the same size. Data that would be shown as 0.1 ratio in a 1GB large torrent is the same as 1.0 or higher in a small torrent. Nobody downloads torrents that are all the same exact size. So you soon end up with 23.7 for example which doesn't reflect the true ratio for the stored torrents on the machine.

Maybe I am expecting too much? If so I apologise for wasting your time.

[x190]

Ticket should be closed as 'invalid', IMO.

[antikythera]

Close it then. I've lost interest IMO.

I really don't care if you think this is invalid x190. The amount of time it has taken for the response I gave (also 3 weeks ago but allowed by moderation 14 hours ago) above your comment to be dealt with on the bug tracker system is risible anyhow.

I gave you guys a fair chance to look at something I thought was a genuine issue. Mikedld has been helpful in solving part of it. As far as I'm concerned I'm done with this ticket. Thanks exclusively for your help Mikedld.