New Transmission add-on thread

I'm using the NasMonitor add-on to monitor the resource usage of my nas.

Using Transmission 2.42 (13013), UDP trackers are still failing to connect for me. Is this the expected behavior, and if so, does anyone know if there's a fix available?

With the beta, the transmission client shut it self of during the night. I tried restarting it from frontview, which gave a fail message, but shortly after the dot turned green. Using the transmission web interface leads to a connection failed message, and transmission remote dot net says : "The underlaying connection was closed: An unexpected error occurred on receive" after which, the green dot in Frontview goes away.
It worked last night... Needles to say, at this point i'm throwing it out, and am going back to 2.42 and hope it behaves.
B!

I had been running Transmission (up to 2.42) on my NV+ for several years without issue.

I recently upgraded the RAM from 256 to 1024 and now have had a failed HDD and issues with Transmission (now that I have restored to factory defaults with a new RAID array).

The HDDs are WD EARS 2TB with 4k sectors so unsupported on 4.1.8 without a factory restore and I knew the drive already had bad sectors so that has been RMAed.

The two remaining drives are running fine under 4.1.8 with 1024 RAM and multiple memory tests report no issues.

My issues with Transmission are that if I try to edit settings.json at all (as I have done many times in the past) Transmission will not restart correctly.

Disabling and enabling in Frontview takes much longer than before and after editing settings.json, 'Transmission service failed to start'.

I have tried rolling back to 2.31, same issues.

Frontview also often shows checkbox checked but no green light, or green light lit and checkbox unchecked. Strange.

Also, transtop.sh works using SSH but transport.sh does not.

Anybody else experiencing this? Should I re-install my firmware again?? If so, what's the best way to do that without losing my data?

Cheers all

:)

Just noticed something. I didn't have this issue to start with, then one of my drives failed, and i started seeing this behavior. I blamed it on the NAS, seeing as it was one drive short, and no longer redundant. An automatic security measure, disable stuff that isn't really needed, so to speak. Anyway, what it started doing was no longer start Transmission after the NAS is restarted. Got a new drive, stuck it in, got redundancy back, and the issue persisted. Didn't think so much about it since i was upgrading to the beta anyway. How that went, we know. I'm now back to 2.42 and can report that it still does this. I've removed the old transmission version every-time i switched to a different version.

In the addons-config directory, the settings.json is protected writing and reading is not allowed even when the NAS say Transmission isn't running, on boot. After ticking the box in settings, and removing the tick again i can save the setting, and it gets read/write-able. When i tell the NAS to start the Transmission service, i get a "Transmission service failed to start" message, the dot turns green, and it works. If i untick, and tick it again, and tell it to save settings, i get the same message, and guess what, every tracker thinks i'm seeding everything twize.
No check is made to see if Transmission is already running, perhaps this is unintentional?

The main issue tho. Trying to shut down transmission isn't working. It says it stopped the service, and you can access the settings.json, but transmission is still up and running, doing transfers, and letting you manage it through the web interface, or a remote client. Seams the only way to shut down transmission is to reboot the NAS. And if the first thing you do when you start the NAS is to turn of, and save the transmission thingy, even tho it's said to be of already, it makes you able to read/write the settings.json, and trackers seam to actually think your offline. (as do they when you first start the NAS)
However, even now, after starting it, just once, you get the "Transmission service failed to start" message, and a green dot indicating it's running. It also will not shut off from this point on. Something that is slightly painfull when you try to tweak settings.
Needless to say, i gave up. It's running, i hit 3MB/s up, it's going to have to do for now.

Not sure if these bugs are a part of the packaging for ReadyNAS, or if it's a part of the Transmission thingy it self. But short of whiping the NAS, and restarting from scratch, i don't know quite how to get it to behave as intended again.
B!

I have a strange performance problem that I can't make heads and tails of. Maybe anybody have any ideas,?

What I see is that shortly after I start Transmission I get decent DL speed and UL speeds, approx 1Mb+ cs 80-90 kb/sec. After a few hours or after the first files have completed to DL the DL speed drops to 20-50 kb/s and the UL speed drops to 2-6 kbits/s. Stopping Transmission and restarting it usually but not always brings the speed up again.

Som facts:
- I've got a NV+ with 1Gb RAM, RAIDiator 4.1.8 and Transmission 2.42. I've got plenty of space available on the NAS, even on the hdc1.
- My Internet connection is a 24/1 Mbit xDSL line and I've checked so I know I get at least 13/1 which would allow me to DL with roughly 1.3-1.4 Mb/sec but atleast 1Mb/sec.
- I do not have any speedlimitations set
- The NAS is connected to a WNDR3800 thru a 1Gbit/s Netgear switch so I have plenty of speed avaialble there
- I've even done tests with only the NAS and my laptop connected (ie. disconnected the AppleTV 2:nd Gen, the PS3, the AirportExpress, my Server, our TV, the HD-box, my wifes laptop and my daughters laptop).
- I've gone thru the motions with changing the settings.json parameters for cache, peers, not using the default BT ports, etc. so I'm quite sure this is not the problem, although if someone can share their settings I'm interested.
- I have tried different versions of Transmission but either they have the same problem or they have other worse issues, like crashing.
- I've tried the built in BT client which provides much better speed but much less functionality so I'm pretty sure it's not my ISP or the NAS that is the limitation and I'd rather run Transmission if I can since it is more feature rich.

Does anybody have any ideas?

To offload this thread I have started a separate thread for this problem and I would appreciate any comments in this thread instead:
http://www.readynas.com/forum/viewtopic.php?t=60628

Mr_B wrote:

When i tell the NAS to start the Transmission service, i get a "Transmission service failed to start" message, the dot turns green, and it works.... The main issue tho. Trying to shut down transmission isn't working. It says it stopped the service, and you can access the settings.json, but transmission is still up and running, doing transfers, and letting you manage it through the web interface, or a remote client. Seams the only way to shut down transmission is to reboot the NAS... B!

Same issues here (Duo);
- indeed starting it provides 'failed' message, but actually didn't fail, will run... :shock:
- w.r.t. stopping it, same issue as well, but if you wait few minutes, transmission is in the end stopped (takes somehow some time).
You can check that by checking if web interface is loaded.

Two other 'inconveniences', I hope somebody has some hints?
1. My NAS is automatically shutting down during midnights / starts up in the mornings.
Somehow the Transmission add-on has to be started manually each day; can that not be started automatically when NAS is starting up as well?
2. My iPhone (safari browser) can not load the web interface providing "error 409: Conflict", about invalid session-id header. Error relates to preventing CSRF attacks, no clue? Yes, iPhone is in RPC whitelist (same local LAN).

Might be interesting to share;
- I had the issue of 'permission denied' w.r.t. storing downloads on my share. This has been solved by deleting 'Downloads' folder and by the web interface creating that folder itself. Also, first I was using a certain username in settings.json being known as well on the NAS, but not being the share-owner. Once I changed settings.json back to username 'admin' it worked, but with different password. Either it is accidentally or a prerequisite to align share-owner username with settings.json username, I don't know but works now :o

i think your first point is related to the failed to start message in FrontView. FrontView doesn't save Transmission as being a running service and thus does not try to start it again at startup. I've got this problem as well and I've got no idea how to solve it besides not turning my NAS off.

I've got no idea about your second point, but you might want to check the forum on the site of Transmission since it might just be a general Transmission problem which has nothing to do with it running on your nas.

The username I am using for Transmission (in settings.json) is different from that of the share-owner and it is working for me. The username used by Transmission is only used to log in on Transmission, nothing else. Transmission itself runs under the username "nobody" of the group "nogroup" and has the permissions of that user.

I have a Pro Pioneer and I have been using Transmission for a while and today I upgraded RAIDiator to 4.2.19. Once the upgrade completed and I rebooted, Transmission no longer starts. Frontview shows it as running, but I can not access the web UI. Is the Transmission add on not compatible with 4.2.19?

I tried reverting back to 4.2.17 and Transmission still won't start. The only other thing that has changed is that I changed some users and permissions on some of my shares, Could that have caused Transmission to stop working?