Opened 9 years ago

Last modified 3 years ago

#2790 new Enhancement

When opening a torrent that is already being downloaded, offer option to merge tracker lists

Reported by: gn0s1s Owned by: livings124
Priority: Normal Milestone: Sometime
Component: Transmission Version: 1.80
Severity: Minor Keywords: .torrent management
Cc: llazy@…, noone3@…, the.paper.men@…, david.regev@…

Description

Would be useful for those times when the trackers in your torrent don't have a lot of peers, but the same torrent on another site has other trackers. The current version allows you to paste new trackers into the inspector, however, it doesn't parse out the URL links from blocks of text that have other things in between them, making it a chore to add more than one or two new trackers. With the functionality described in this request, the tracker lists of both torrents are merged no matter how many there are.

Change History (25)

comment:1 Changed 9 years ago by gn0s1s

  • Summary changed from When opening a torrent that is being downloaded, offer option to merge tracker lists to When opening a torrent that is already being downloaded, offer option to merge tracker lists

comment:2 Changed 9 years ago by charles

  • Component changed from Mac Client to Transmission
  • Version changed from 1.80+ to 1.80

comment:3 Changed 9 years ago by lazy

  • Cc llazy@… added

comment:5 Changed 9 years ago by livings124

#2928 appears to be a duplicate of this

comment:6 Changed 9 years ago by dskchk

  • Cc noone3@… added

comment:7 Changed 9 years ago by anicake

sorry for not finding this one and creating a duplicate... My apologies.

However, an appendix to this request would be that the new .torrent files from which tracker lists are extracted need to be trashed as well - if the preference is set to trashing torrent files after adding them.

utmost regards, anicake

comment:8 Changed 9 years ago by anicake

  • Keywords .torrent management added
  • Milestone changed from None Set to 2.12
  • Priority changed from Normal to High
  • Severity changed from Minor to Major
  • Type changed from Enhancement to Bug

comment:9 Changed 9 years ago by livings124

  • Milestone changed from 2.12 to None Set
  • Priority changed from High to Normal
  • Severity changed from Major to Minor
  • Type changed from Bug to Enhancement

Increasing the priority and severity is ridiculous, and unless you're providing a patch (and even if you are) why do you have the right to tell us when we're going to implement this? And how is this a bug in any way?

comment:10 Changed 9 years ago by gn0s1s

It's probably a new user who never used trac before. What I don't understand is that I've seen this happen several times, a new user with no understanding of trac makes this kind of mistake and someone goes ballistic on him. Either the permission for non-developers to change those fields should be rescinded (best), or there should be some clear labeling on the form that those are developer-only fields (good), or there should be some expectation of n00bness (and accompanying grace) on the developers' end regarding those who do end up changing those fields (minimal common courtesy). I certainly didn't know what the rules were regarding those fields the first time I posted or commented on an issue, and sadly the only way I learned was seeing a dev tear down another new poster for doing the same thing.

This guy was respectful, stated his request clearly, and even ended with "utmost regards". I think at the very least, he's deserving of a little grace and civility when dealing with his obvious lack of knowledge of how trac works.

Having said all that, it would still be nice to see this feature, but very fact that it was my original submission, coupled with the paragraphs I just wrote above, probably means that it will never see the light of day (I've seen this film before!).

comment:11 Changed 9 years ago by livings124

Any assumption of misunderstanding was given up when priority and severity were changed.

I don't know why you assume this will never happen - the ticket is still open for a reason. If someone wanted to submit a patch, that would sure increase the chances, however.

comment:12 Changed 9 years ago by gn0s1s

Fields that are changeable beg to be changed. Most people see a form as a request for information and fill everything out, even if everything is not required or wanted. Most new users have no way of knowing that the fields being requested of them are not what they think the priority and severity of an issue are, but that they are actually changing those values for the entire ticket and stepping on others' toes.

Having seen the way previous users have been responded to with regards to this same issue, I don't believe that there was ever any "assumption of misunderstanding" to be abandoned. And barring changes to the trac system itself, I can't see how half-hearted justifications can mitigate the intensity of the over-reaction or encourage other new users to submit their suggestions.

Last edited 9 years ago by gn0s1s (previous) (diff)

comment:13 Changed 9 years ago by livings124

This is an argument for the sake of having an argument.

Last edited 9 years ago by livings124 (previous) (diff)

comment:14 Changed 9 years ago by gn0s1s

That's a dismissal for the sake of not owning up to one's own rashness.

comment:15 Changed 9 years ago by livings124

I stand by my statement. The milestone component might not be straightforward, but priority and severity sure are. This isn't going to go anywhere...

comment:16 Changed 9 years ago by charles

Livings is right that it doesn't rise to the level of high priority, and isn't a bug.

But, I think this feature would be nice to have, and I expect it will be implemented sometime.

It's clear to me that anicake was being led down the garden path by trac. It's happened to many users before. The Transmission team experimented in the past with reducing what ticket fields were user-editable, but IIRC that caused a different set of problems. IMO it's better to accept that the milestone faux pas is going to happen sometimes and not worry about it.

comment:17 Changed 9 years ago by anicake

I am really really Sorry!!!

comment:18 Changed 9 years ago by anicake

I am a big adulator of the transmission team because of "everything" that transmission is. The feature mentioned is a part of utorrent and many of my student friends use utorrent because of this. I want more people to use transmission and enjoy using it as I do. That's the reason I changed the priority and severity. I apologize for doing that. I still use transmission because I LIKE IT. I have only begun studying computer science. I will contribute to this project as soon as i make myself capable.

utmost regards, anicake

comment:19 Changed 8 years ago by jordan

  • Milestone changed from None Set to Sometime

comment:20 Changed 8 years ago by jordan

Ticket #3941 has been closed as a duplicate of this ticket.

comment:21 Changed 8 years ago by stepmuel

Fixing this would also solve #2721

Since I'm behind a firewall limiting the number of connections, magnatized transfers often stay on "torrent metadata needed". When I use a torrent file, the download starts immediately; but I need to delete the former transfer first. I have to do this several times a week, and it really annoys me.

I'm using the Mac client, v2.22. I don't seem to get any error telling me the transfer (or the new trackers) haven't been added (which was the expected behavior). Once the torrent had already been downloaded, and I had no idea why I couldn't add it.

Also, the settings "Start transfers when added" and "Trash original torrent files" are ignored. Those actions are expected to happen when opening a torrent file; if they are actually added, or only merged or ignored are technical details, and shouldn't matter to the user.

I really would appreciate this issue being resolved soon. For me, it's a big flaw in transmissions usability. And many users (most of them possibly unaware of the possibility of filling tickets) might just think its an annoying bug.

comment:22 Changed 8 years ago by rayfitzharris

Hi Folks,

I've been watching this thread for a while, I feel for aricake, it's a mistake I've made myself in my youth! This is something i've been wondering about too I think it's a very nice feature. With that in mind I've added a patch for transmission-remote-dotnet . I don't know if any one on here uses it to control/monitor their transmisson server but if it's of use to anyone the ticket and patch is on transmission-remote-dotnet here : http://code.google.com/p/transmission-remote-dotnet/issues/detail?id=395&colspec=ID%20Type%20Status%20Priority%20Milestone%20Summary%20Stars

Best Regards, Ray

comment:23 Changed 7 years ago by cfpp2p

I don't know if any one on here uses it to control/monitor their transmisson server but if it's of use to anyone the ticket and patch is on transmission-remote-dotnet here

for anyone who might control/monitor their transmission server via Transmission-Remote-GUI here is an up-to-date for v2.50 that I compile today

http://code.google.com/p/transmisson-remote-gui/issues/detail?id=522#c7

comment:24 Changed 7 years ago by thepapermen

  • Cc the.paper.men@… added

comment:25 Changed 3 years ago by DavidRegev

  • Cc david.regev@… added
Note: See TracTickets for help on using tickets.