Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#2448 closed Bug (invalid)

Transmission-remote -st reports total duration incorrectly after a crash

Reported by: krx Owned by:
Priority: Low Milestone: None Set
Component: Transmission Version: 1.75
Severity: Minor Keywords:
Cc:

Description

If trasmission daemon crashes, and it crashes for me often, perhaps because of low RAM on router, it's report with transmission-remote -st, section TOTAL Durantion goes bezerk and show hudge numbers. For this moment it is "14513" days, yet I have reinstalled Transmission some months ago, and have delete stats.json serveral times already due to this issue (daemon was not running during deletion).

Change History (5)

comment:1 follow-up: Changed 12 years ago by charles

What does your ~/.config/transmission/stats.json file look like?

comment:2 in reply to: ↑ 1 Changed 12 years ago by krx

Replying to charles:

What does your ~/.config/transmission/stats.json file look like?

Like this:

{
    "downloaded-bytes": 2084556162,
    "files-added": 0,
    "seconds-active": 1253931685,
    "session-count": 7,
    "uploaded-bytes": 504066033
}

14513 days? I am not that old ;-)

comment:3 Changed 12 years ago by charles

  • Summary changed from Transmission-remote -st report activy total duration incorrectly after crash to Transmission-remote -st reports total duration incorrectly after a crash

comment:4 follow-up: Changed 12 years ago by charles

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

Yep,

"seconds-active": 1253931685

is a lot of time :)

You can edit it to a smaller number of seconds to resolve the stats problem.

If you have more information on how transmission-daemon was crashing, please file a ticket for that. "and it crashes for me often" is something that bears investigating.

comment:5 in reply to: ↑ 4 Changed 12 years ago by krx

Replying to charles:

Yep,

"seconds-active": 1253931685

is a lot of time :)

You can edit it to a smaller number of seconds to resolve the stats problem.

Frankly, I do not care about this one ;-)

If you have more information on how transmission-daemon was crashing, please file a ticket for that. "and it crashes for me often" is something that bears investigating.

I am running Transmission on DD-WRT, got it through Optware. I have already had some small discussion with you ~half year ago, and the outcome was that I do not posses any tools or skills to debug crashes under this platform, and generic crash info, from dmesg/SYSLOG does not give you the required symbols/hints, in what routine/module crash has happened. If you have any "walk-through"/FAQ/etc. how I should do it under this platform, I would gladly try to do my best. If the topic is too wide, I am not sure, I will be of any help here, as my speciality is integration/system analysis, not programming directly.

From my POV, transmission crashes when under heavy stress for I/O, either directly, or because of swapping (running it under quite low RAM conditions). E.g. when verifying, heavy download with torrents with many pieces, many upload slots, etc. If there are a few torrents with mild load, tranmission is stable for weeks (DD-WRT autoreboots to upgrade optware once a week).

Yet, there is one specific behaviour before crash - just before crashing, transmision process does not respond to RPC/web/command line often, but the process has not crashed yet.

Note: See TracTickets for help on using tickets.