Opened 10 years ago

Closed 10 years ago

#4627 closed Enhancement (invalid)

Ignore Self When Viewing Available Blocks for Seeding Torrent

Reported by: Renara Owned by: livings124
Priority: Normal Milestone: None Set
Component: Mac Client Version: 2.42
Severity: Normal Keywords:
Cc:

Description

I love the little grid in the Activity tab of the inspector, that gives a great visual overview of downloaded and available blocks. However, once a torrent is seeding (you have all the blocks), then this becomes less useful, as the available blocks are always all of them.

What I'd like to propose is that when viewing the activity tab for a seeding torrent that, if possible, the grid shouldn't show locally available blocks. This should either be done for the available grid, or the progress grid, possibly renaming one of them for the purpose, for example to change progress in a "Seeded" grid.

This way it would be possible for the grid to display what proportion of the torrent's blocks are actually in the wild, as the gigabyte uploaded stat doesn't help if we've only distributed the same portion of blocks to many peers, for example. Just gives the grid an extra use once the download is complete!

Change History (20)

comment:1 Changed 10 years ago by jordan

  • Component changed from Transmission to Mac Client
  • Owner set to livings124

comment:2 Changed 10 years ago by jordan

Even though this feature would require changes to libtransmission, I'm reassigning this ticket to "Mac Client" for review by livings124, as the Mac client is the only one that displays a grid.

comment:3 Changed 10 years ago by jordan

Thinking about this suggestion a bit... the current semantics of this feature is to show availability wrt the peers we're connected to. Since seeds don't stay connected to other seeds, when seeding we would always show incomplete even if the swarm was teeming with seeds, which IMO would be confusing.

This feature isn't very useful and is potentially confusing. My vote is against it.

comment:4 Changed 10 years ago by jordan

  • Type changed from Bug to Enhancement

comment:5 Changed 10 years ago by Renara

The feature could continue to ignore seeds, but so long as one or more are detected then it can simply set the grid to 100%? That way it wouldn't need to actually query them in any way, and wouldn't show up as incomplete.

As I don't know what data is actually flying around that comprises the grid, one possible interesting alternative would be to weight the grid-squares based on the quantity of peers that have them. For example, a square with no peers in possession of it would appear "cold" (dark) while a square that is possessed by many peers would appear "hot" (red or bright), giving us a heat map that shows dispersion of the torrent. For that style it would definitely warrant a renamed tab, but it shouldn't matter then if seeds aren't processed, since we don't really care about them anyway (since we know they have all the blocks), but they could always be factored in by simply counting the number of known seeds.

Anyway, I don't think it'd be that confusing, as there is plenty of information telling us that a torrent is complete and now seeding, so it doesn't seem a big deal. Renaming one or both grid tabs would seem a good way to communicate the difference though. Besides, arguably the current display is more confusing, or rather, it doesn't really show any information that isn't already known, so it essentially becomes redundant once a torrent is complete, I just think it's an opportunity to give something more useful for seeds to see what's going on.

comment:6 Changed 10 years ago by jordan

  • Resolution set to invalid
  • Status changed from new to closed

Actually I think the better option would be to remove the grid altogether. I don't think it's a very useful feature, and complicating it further as suggested in this ticket would be lipstick on a pig.

The grid is probably going to stay stuck as-is for the time being.

comment:7 follow-up: Changed 10 years ago by Renara

  • Resolution invalid deleted
  • Status changed from closed to reopened

Can you please stop closing my issues as invalid? Seems like a perfectly valid issue to me, the distinction is that you're deciding not to implement it, not that there's something wrong with the idea.

That said, the grid is surely just another representation of the barcode view (the pieces bar); I think the grid is a decent way to represent the pieces in a more efficient layout. Though it might be nice if the inspector had its own dedicated pieces tab, allowing for a much larger, more detailed grid. As I don't use the pieces bars much since I prefer the compact view, and the pieces bars aren't very useful in that mode, plus it's not really info that I find useful to see all the time anyway, so the inspector is a good place for it.

Either way; this issue applies to the pieces bars as well as the grid, since it's the same information really. When you're seeding a torrent you know that your pieces bar is complete, so showing a 100% bar is redundant, might as well get more use out of it by showing how well the torrent is being distributed to peers, as it might give a better idea of how well Transmission is seeding a torrent.

comment:8 in reply to: ↑ 7 Changed 10 years ago by jordan

  • Resolution set to invalid
  • Status changed from reopened to closed

Replying to Renara:

Can you please stop closing my issues as invalid? Seems like a perfectly valid issue to me, the distinction is that you're deciding not to implement it, not that there's something wrong with the idea.

Don't take it personally. trac has a limited range of choices available when a ticket is closed.

comment:9 Changed 10 years ago by Renara

  • Resolution invalid deleted
  • Status changed from closed to reopened

I thought there is a "wont fix" resolution, which seems more relevant? Apologies if it's just not available to enhancements, but I've definitely seen issues closed that way before; invalid implies the grid already does this, or the issue I've raised doesn't follow any logic or something.

Anyway, you didn't respond to my other comments; whether this behaviour is applied to the grid or not isn't so important, since the same behaviour also applies to the pieces bar; unless you feel that both are pigs then I think the issue still stands.

Sorry to re-open it again, but no-one seems to follow-up on issues once they're closed, and I don't think the issue is resolved anyway as you're dismissing it on the basis of the grid being something you want rid of, rather than whether the information I'm proposing is useful for seeding torrents, which is the important bit to focus on.

comment:10 Changed 10 years ago by jordan

  • Resolution set to invalid
  • Status changed from reopened to closed

"wont fix" implies there's something that needs to be fixed. This is an enhancement request...

comment:11 Changed 10 years ago by jordan

You're dismissing it on the basis of the grid being something you want rid of, rather than whether the information I'm proposing is useful for seeding torrents, which is the important bit to focus on.

It is not useful for us as a seed to know the relative scarcity of pieces in the peers that we're connected to.

Edit: or, rather, I haven't seen any explanation yet of why this is useful information. I'm willing to listen, but since we have no control over what pieces are requested from us by peers, the information such a grid would convey seems moot.

Last edited 10 years ago by jordan (previous) (diff)

comment:12 Changed 10 years ago by Renara

It would give a better picture of seed progress, particularly for a new torrent (where you're the only seed initially). The progress bars don't really tell us anything, as 30% doesn't give any indication as to which 30% those peers have.

In particular, every time I've seeded a new torrent, I've found the lack of such information confusing. For example; I recently seeded a torrent that was on a ratio of 2.35 after less than a day, yet nobody had more than around that 30% mark. The reason being that all the blocks shared by Transmission were presumably the same for all peers, meaning that very little sharing between peers was occurring, so most of my upload bandwidth was being wasted sending the same blocks to each peer I was connected to.

However, I have only my own observations to "prove" this, being able to see which blocks are are being commonly shared amongst peers will allow us to see where potential performance is being lost. And it could lead to useful information about what needs to be, or could be, improved in Transmission, or offending clients that are requesting blocks in a bad order. As I understand it, the best performance for a torrent actually comes when the blocks are seeded very randomly, as it means that peers end up with different portions of the same torrent, which increases the potential sharing amongst leachers; so I think it's very useful to be able to see whether or not that is happening with a seeding torrent as, in theory, the pieces bar and grid should show an even distribution of all blocks, but I'd wager they currently wouldn't.

comment:13 Changed 10 years ago by Renara

  • Resolution invalid deleted
  • Status changed from closed to reopened

comment:14 Changed 10 years ago by jordan

  • Resolution set to invalid
  • Status changed from reopened to closed

This feature isn't very useful and is potentially confusing. My vote is against it.

comment:15 Changed 10 years ago by Renara

  • Resolution invalid deleted
  • Status changed from closed to reopened

Why isn't it useful? I've given more than enough reason why it could be useful, please be more specific in your responses as I'd like to know more about why you're against this.

Do you at least agree that being able to see how, or how well, a seeding torrent is being distributed is useful information? To me this is a good way to implement such information, as while the ratio is fine for quick skimming it gives very little real information, and both the pieces bar and grid currently become redundant once a torrent a complete. I don't really see the issue of confusion either; if a torrent is seeding then you know you have all the pieces, by recolouring the pieces bar and/or grid we could easily highlight that the meaning is changed; there are a ton of ways to potentially eliminate confusion.

I realise that you get a lot of tickets, but I don't like how plainly ideas are simply dismissed here; to me the value of having more seed-related information is self-evident, so if there is any problem then it's something to be properly discussed and explored so that a new ticket can be created, or the details of this one can be adjusted accordingly.

comment:16 Changed 10 years ago by jordan

  • Resolution set to invalid
  • Status changed from reopened to closed

I disagree with almost all of this.

As I said, the value of this information is low because a peer's view of the swarm is incomplete. In addition, your suggestion of debugging distribution doesn't take into account holes created by peers that download and then drop out of the swarm.

Even if the information were useful, it's not actionable by the average users: downloaders, not seeders, decide which pieces to request. It doesn't fit Transmission's goal of being a straightforward, low-bloat application.

comment:17 Changed 10 years ago by Renara

  • Resolution invalid deleted
  • Status changed from closed to reopened

doesn't take into account holes created by peers that download and then drop out of the swarm

It doesn't need to; as that's precisely the kind of picture of the swarm that would be useful! If the only other seeder in the swarm drops out of it then that shows that the coverage isn't complete at all as it means that there aren't enough seeds, which is more useful information.

It doesn't fit Transmission's goal of being a straightforward, low-bloat application.

It's what, maybe a two or three line change to ignore your own blocks? I know nothing about the code but to ignore one peer (yourself) when building the pieces bar and/or grid seems like it'd be a tiny code change, maybe add a colour change for visual clarity and you're done. Besides which, it doesn't 'matter' if it's actionable, it's informational! Just like the current pieces bar; we have no real control over that beyond choosing not to download specific files (assuming the torrent has multiple files at all) so in practise it's no more actionable at all, but it gives the ability to see what's going on, and that's all I would really want from this feature.

Even so, with the information power users would be able to look at their seeding torrents and identify "bad" clients that are requesting blocks sequentially or in some other weird order, potentially allowing those clients to be pushed for improvements, which benefits everybody.

I really can't see why you're so opposed to what should be a simple feature to implement, that gives a wealth of information that we simply don't have right now, there's no real visual complexity, and there shouldn't be any confusion as at all as Transmission already clearly distinguishes between downloading and seeding torrents. Currently all seeders get is a ratio, which doesn't really tell you anything at all as a ratio of 1.0 can just as easily mean that 20 peers have 5% each (no sharing) as it does that one user has 100%.

comment:18 Changed 10 years ago by jordan

  • Resolution set to invalid
  • Status changed from reopened to closed

I appreciate your interest in improving Transmission but I think this is the wrong way for you to go about it. We are going in circles here because you don't accept the reasons I've already given for closing this ticket.

This feature, if implemented, would give an incomplete and unexplained view of the swarm. It would be ignored by most users, confuse some of them, and cause a few to make inaccurate interpretations about the swarm. None of these outcomes is useful.

comment:19 Changed 10 years ago by Renara

  • Resolution invalid deleted
  • Status changed from closed to reopened

You're telling me we're going in circles, but your arguments against the feature are lack of usefulness, and confusion, neither of which I believe are justified! I've given plenty of reason why the view would be extremely useful, and I've countered the claim of confusion; please feel free to refute this, because we're only really going in circles because you're not really giving me your side of this! I've given plenty of reason contrary to what you've argued, but all you've done is repeated your argument; I don't mean to be insulting but you're the one that's causing us to go in circles as you're not giving me any choice to be reiterate points that I believe to be perfectly valid!

Feature is useful because:

  • Current ratio value provides a severely limited view of what's actually going on with a seeding torrent. This value is nothing beyond a simple amount upload over amount downloaded value, which cannot reflect the quality of a torrent's distribution into the swarm. In particular, a newly seeded torrent with a ratio of 1.0 is never (in a practical case) going to be safe to stop seeding, as it may be as little as 30% distributed into the swarm.
  • It can give a picture of how a torrent is being seeded, and over time will give a good picture of the health of a torrent; i.e - the more complete the bar is, the better the torrent is being distributed. It would appear complete so long as there is at least one other seed in the swarm, could even use shades to give a better "health" appearance (so that even with a complete bar the more dark areas, the better).
  • It allows power users to identify bad swarm behaviours, allowing problems with Transmission, or other clients, to be identified; currently Transmission has no real way of knowing which peers are "bad" in terms of torrent health, i.e - those that only download sequentially, even though it is bad for the swarm.
  • By the same vein, it can show you when a new torrent is actually fully seeded in a more useful, visual manner than the ratio. This removes the need to check tracker statistics when deciding if a new torrent is safe to stop seeding.

Feature may be confusing because:

  • Pieces bar/grid will not be complete for seeding torrents. This seems to me the only reason and as far as I'm concerned it isn't a reason for confusion because:

Feature should not be confusing because:

  • Bar/grid can be trivially recoloured and/or relabelled for seeding torrents, to provide a visual distinction.
  • Seeding torrents are already clearly distinguished from downloading ones.
  • An incomplete bar/grid for a seeding torrent is contradictory (a seeding torrent has to have a complete bar or it would still be downloading, if there is some case that this isn't true then please let me know instead of just citing confusion over and over!).
  • Further to this, a fully coloured bar/grid is superfluous for a seeding torrent. Assuming confusion isn't an issue, this feature would be making a currently pointless user interface aspect useful for cases where it currently holds no value.

As for "inaccurate interpretations"; what kind of interpretations? Please elaborate on your points, as currently all we have is the ratio and the peer tab of the inspector, neither of which allow us to give accurate interpretations about the swarm, but with this additional tool available we might at least be able to get ideas of trends. I don't think the view would really be inaccurate at all; simplified, perhaps, but we'd have more information to go-on. Currently if I want to describe how my new torrents are being distributed I can only do so in peer-percentages and speculative informed guesses; if I could see which pieces are being distributed I could at least point and say "uTorrent peers seem to be downloading sequentially, as only the first third of the pieces bar is complete, with peers at 33%". That is a statement with more, better information than I could currently give.

comment:20 Changed 10 years ago by jordan

  • Resolution set to invalid
  • Status changed from reopened to closed
Note: See TracTickets for help on using tickets.