Opened 13 years ago

Closed 13 years ago

#3309 closed Bug (worksforme)

Sometimes event stopped is not send when clossing Transmission

Reported by: howl Owned by:
Priority: Normal Milestone: None Set
Component: Transmission Version: 2.00
Severity: Normal Keywords:


With Transmission 2.00 I have seen two times that clossing it without sending the stop event for all the active torrents.

I can't reproduce it, but I think is a bug in Transmission because sometimes with a total of 143 torrents some of the torrents aren't reported as stopped but could be caused by network overload, but the two times I have said absolutely all of them lacked the stopped report.

The client in use is the GTK one from the transmission ppa on karmic.

Change History (7)

comment:1 Changed 13 years ago by charles

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

Well we're damned if we do, and damned if we don't. Transmission sends out the event=stopped announcements when it starts shutting down, and waits for quite awhile for a response from the trackers. But if a tracker is slow or not responding, we can't wait forever because then people will interpret Transmission not exiting sooner as a bug. (And have reported this issue many, many times.)

If you can reproduce behavior where Transmission isn't sending out the announces on shutdown -- such as by setting the TR_CURL_VERBOSE environment variable to watch the announces actually getting sent -- then that would be something to look further into.

comment:2 follow-up: Changed 13 years ago by howl

I'm not damning nobody, anyway is your opinion. I know what Transmission do when is closing so is not my problem what other people think, so I filed this bug thinking that could be some situations where Transmission doesn't send event stop, which is a fault if the client doesn't send them. I repeat, send, not talking about network overload looses, I'm not talking about the time it could take. The slow is my connection so I know when some closed events are miss is because overload and packets lost under many connections at the same time. But when "absolutely all" of them lacks the stopped event, doesn't seems to be overload.

Talking about the same bug you say, "the time Transmission takes at exiting" (for me is not a problem as I said) I can remember someone suggesting a progress bar or a message showing the number of reports send and the number of reports pending, what seems to be a good option for what you are saying (not the issue I filed this bug). But do what you want, it's your client and also this bug is not about the time needed by Transmission to exit.

I was here to set this to invalid because I haven't seen no torrents sending stopped at close anymore, so thanks for doing it for me.

PD Off-Bug-Report: One of reasons that makes me to use Transmission is the dedication and the good work of the devs behind it, I think the key of your type of response is "(And have reported this issue many, many times.)" and I know that the doing something, that many people uses, could have some stress effects when the feedback arrives, but is also one of the best tools that a dev have to do a great job. I would try TR_CURL_VERBOSE just in time when I read this if you had been polite replying. So I will spend my time for other things I have to do, and if I see that Transmission doesn't send stop at close under some situations it will be easier for me not to whitelist it, in the tracker I'm a staffer, than reporting it to you. Anyway, thanks for all your time and dedication.

comment:3 in reply to: ↑ 2 Changed 13 years ago by charles

Replying to howl:

So I will spend my time for other things I have to do, and if I see that Transmission doesn't send stop at close under some situations it will be easier for me not to whitelist it, in the tracker I'm a staffer, than reporting it to you. Anyway, thanks for all your time and dedication.

I do not understand what you're talking about.

  1. You filed a bug report.
  2. I asked for more information. I can think of several suspects for the behavior your first message described: (1) a bug in transmission (2) the tracker is offline (3) the network is having trouble. Logging information would tell us whether the problem is (1) or not.
  3. I flagged the ticket as incomplete.
  4. You responded back and said that you weren't even going to try logging. Instead, you asserted that the problem isn't (3).
  5. You got angry about me being "rude". I don't understand this because I wasn't rude.
  6. You threatened not whitelist Transmission in the future.

I don't see anything rude about my previous message and am honestly not sure why you're angry.

If you experience this problem again and choose to provide logging information, that would be most appreciated.

If, however, you choose to go off angrily for no apparent reason, and decide to ban Transmission on your tracker, then you should also point your users to this page so that they can judge for themselves.

comment:4 Changed 13 years ago by Lacrocivious

This is an unfortunate case of a misunderstanding caused by a figure of speech -- a common folk saying -- said across a language barrier.

The phrase 'Well we're damned if we do, and damned if we don't.' has been misunderstood. I can easily see how it could seem rude, as the words by themselves are more rude than not.

howl: What the saying means, and what charles meant, is that if the devs do things one way, they will be criticized for it. If they do things the other way, they will be criticized for that too. So either way that they choose to do it, someone will criticize. charles did not mean to be rude. Trust me on this. What he meant to do was to make a dry joke.

comment:5 Changed 13 years ago by howl

I think Lacrocivious has explained the trouble, so, I'm sorry for my bad English comprehension. Replying to the new comment of charles, no we don't ban clients without any reason, as I said if I found that Transmission doesn't report under some circumstances the close of the program it won't go to the whitelist, for now the status is with normal use on linux seems to report well, only have to check what it does when moving a completed torrent and when recheking a a torrent, and also to check the mac port. But for now it has all the chances to get whitelisted. Also in "my" (don't like this one) tracker I try to spread the use of native clients on linux, mostly users of dedicated servers, like Transmission and KTorrent, so this discussion seems to be a negative effect on what I try to do, no more or less because most of the members doesn't mind what they use.

(1) a bug in transmission, "could be" (2) the tracker is offline, "can't be" (3) the network is having trouble "could be", when I have the mood to do it I will try to determinate if it's a bug or it was network problem.

And no, I'm not criticizing no one, I'm only filled a bug with what happened, I didn't gave my opinion. But if you want my opinion I think Transmission is the best client for people in linux and mac who doesn't want or need a full featured client, opinion that I have been talking about in the tracker since I'm there.

Sorry for the misunderstood again, but I can't see how just a bug fill made you to tell me about what the users do, when I didn't do anything you said.

comment:6 Changed 13 years ago by howl

  • Resolution invalid deleted
  • Status changed from closed to reopened

Confirmed, sometimes Transmission doesn't report stopped event , I have been Transmission running non stop since this 2/3 days and I have to close it now, the result has been Transmission closing immediately. The interface with the button to leave immediately has been less than a second, and there are 129 torrents to report about so it's impossible and also the tracker didn't receive stopped from any of the torrents. No network failure, no tracker down, just Transmission leaving like if I had pressed the button to leave immediately but without pressing it, I haven't pressed either accidentally enter key.

During this execution I have only added some torrents, I remember 5, and also deleted 18 torrents (only the torrents, no data). I had the filterbar in Active when leaving. I can't remember anything else.

Last edited 13 years ago by howl (previous) (diff)

comment:7 Changed 13 years ago by howl

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

I can't find a way to reproduce it always, simply sometimes Transmission closes without reporting stopped event. I close this until I find what exactly makes this to happen.

Note: See TracTickets for help on using tickets.