New Transmission add-on thread

[veehexx]

*ONGOING BUG*

S-P, thanks to charles at tranmission bug trac, there seems to be an issue the way the transmission service stops on the DUO.
i mention this has been happening to me for a while; since around 1.92/1.93. not sure if it's related, but this is possibly around the time you SSH'd into my DUO to investigate a stop/start issue.

charles recommended that i stopped the torrents, waited a few seconds (around 40sec just to be sure!) and then stopped the transmission daemon. restarting the daemon 20seconds later. i then start the paused torrents; torrents resume as normal without any checking.
so, on the face of it, this seems to be an issue with how the start/stop script works on your addon. it appears (to my untrained/uneducated mind), that the daemon is being forcefully & prematurely stopped and therefore not allowing transmission to correctly write the resume data, and so torrents are being rechecked on every daemon start.

i hope that makes sense and you have the time to look into this issue.
i do find it hard im the only one experiencing this issue from both readynas and transmission users, but theres definately something up! 🙂

if you need SSH access again, then just let me know!

[super_poussin]

veehexx wrote:

*ONGOING BUG* S-P, thanks to charles at tranmission bug trac, there seems to be an issue the way the transmission service stops on the DUO. i mention this has been happening to me for a while; since around 1.92/1.93. not sure if it's related, but this is possibly around the time you SSH'd into my DUO to investigate a stop/start issue. charles recommended that i stopped the torrents, waited a few seconds (around 40sec just to be sure!) and then stopped the transmission daemon. restarting the daemon 20seconds later. i then start the paused torrents; torrents resume as normal without any checking. so, on the face of it, this seems to be an issue with how the start/stop script works on your addon. it appears (to my untrained/uneducated mind), that the daemon is being forcefully & prematurely stopped and therefore not allowing transmission to correctly write the resume data, and so torrents are being rechecked on every daemon start. i hope that makes sense and you have the time to look into this issue. i do find it hard im the only one experiencing this issue from both readynas and transmission users, but theres definately something up! 🙂 if you need SSH access again, then just let me know!

will produce a new version today or tomorrow

[super_poussin]

can you try :

http://www.readynas.com/contributed/sup ... .01b05.bin

go in /c/addons-config/Transmission and edit the transtop.sh to add your transmission password 🙂


let me know

[veehexx]

thanks so much, S-P!
this transtop.sh script does work and stops torrents being rechecked unneedlessly.

however when you re-start the daemon, all torrents are in a paused state, and not their last status prior to when the transtop.sh runs.
this is obviously desired behaviour, but is there anything that can be done?

[super_poussin]

That' possible but will require some work ( It in my long todo list )

[veehexx]

cant say fairer than that!

i'm going to stay on 2.01beta5, since having to access webgui and click 'resume all' is far quicker than waiting for multiple torrents to re-verify every boot 🙂 (i use scheduled power on/off)

[super_poussin]

Try the 2.01b06 for Sparc Only

Please also modify the password in /c/addons-config/Transmission/transtart.sh

Hope it will feet all your needs

[veehexx]

resuming of torrents not working...
contents of each file when transmission is stopped:

idle.txt
9

seeding.txt
23

downloading.txt
3 4

it LOOKS like the numbers mean what number the torrent is. so torrent ID #23 is seeding etc

when i restart transmission again, all torrents are paused; almost like the above 3 files aren't being read.

on beta5, i noticed if the password was incorrect (in transtop.sh), then it wouldn't end the transmission service. now on beta6, the transmission service auto-started (immediately after installation) with an incorrect password in the 'transtart.sh' file.
hope thats helps track the problem... if transtop.sh and transtart.sh files act the same, it's almost as if transtart.sh isn't being called at startup to re-set the torrent status...

time for a beta7? xD

[super_poussin]

even if password is bad in transtop or transtop it will work , only the torrent will not be restarted or stopped

when transtart runs it need a little bit time to be see the change on gui

It works on my unit .

can you tru like this :

on gui start all the torrent you wants to have in seed / downloading state

then stop transmission

then start it again

please notice it will require 40 seconds minus before you see any change in the gui

[veehexx]

i might of worded one of my previous posts badly...
the 40second delay i mentioned was something *I* chose todo, rather than what charles@transmission asked me todo.
i'm pretty sure you could get it down to <3seconds, but i haven't done too much testing with that yet.
i think the idea was to stop the torrent and then close down the daemon.
aslong as it's not cached writes, then the write to the .resume file i'd expect to be miliseconds.

maybe something to play for future releases...

ok, i've done as you sugested S-P.
all the 3 .txt files have changed contents that mirror my chosen torrent status.
all torrents are being kept in the 'paused' status still.

edit: thanks for clarification on the 2 scripts. i might of just been impatient with the stopping delay in b5 release. and just to confirm, passwords are correct in the 2 .sh files...

[super_poussin]

Yep I will reduce the time 🙂

[btaroli]

I think I'm done with 2.0 for a while. The b1 version I installed still does have the file ownership behavior, and from the more recent notes it seems 2.0 isn't ready for prime time. I will be going back to 1.93 tonight. Need to let 2.0 bake a bit longer, I think.

[super_poussin]

btaroli wrote:
I think I'm done with 2.0 for a while. The b1 version I installed still does have the file ownership behavior, and from the more recent notes it seems 2.0 isn't ready for prime time. I will be going back to 1.93 tonight. Need to let 2.0 bake a bit longer, I .

Also with 2.01b06 ?

[adeptus]

Just FYI, I think there's some kind of a bug with 2.0.0 that you guys offer on the main transmission page. The blocklist process sucks up 99% of the CPU for hours at a time. The pic below shows what appears to be a CPU and memory spiral upwards. The power off/reboot physical button doesn't even respond. If this is a known bug with 2.0, then at least update the main page with a link to your beta releases

Look at this, my load average hit 15.99 and is still climbing
top - 07:54:41 up 1 day, 12:53, 0 users, load average: 15.99


PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
32640 root 20 0 2492 344 164 R 99 0.0 89:39.13 blocklist



Thanks for your efforts, I hope we get to a stable release soon 🙂
Adeptus

[super_poussin]

I did not see that on my dev unit , can you do a ps -ef when it happened ?

which version are you runing ?

[veehexx]

adeptus - do you have any torrents verifying?
if you pause all torrents, what happens to the load?

fwiw, not experiencing the issue on duo unless when verifying which is to be expected! 🙂

[adeptus]

I had to do a hard power down as I couldn't access the transmission web interface and even the frontview was extremely slow (cuz 'blocklist' process was sucking up 99% of CPU). After the hard powerdown, there's a volume resynch going on for many hours, so after that I will just upgrade to the latest beta. I could just leave 2.0 and see what happens again tomorrow morning, but let's face it, it's a cronjob that would just get initiated again at x time (5:30AM?). I only had 5 or 6 torrents downloading each with 2 to 10 files each and all the torrents added up to 4GB or less, so no recheck should suck-up 99% CPU for 2-3 hours. utorrent doesn't behave like that on a single CPU system even with 20 re-checks going on, so I attribute that to bad coding somewhere in Transmission. Sorry guys, I need this thing working, don't have a lot of time for being a beta tester, but I do appreciate your support. If I do catch it doing that again, I'll do the ps -ef somebody else requested and post it here.

Thanks,
Adeptus

[super_poussin]

curl should stop if file not accessible .

can you chheck if you can download : http://update.transmissionbt.com/level1.gz ?

a 404 or bad dns resolut stop the script quickly

a download and update of the blocklist take less than one minute on my units

[veehexx]

2.01b7 sparc feedback...

- long delay when disabling the transmission addon (felt like ~90seconds). starting the addon is fine.
- torrents not resuming when transmission starts (torrent ID's are being written to applicable .txt files on disable though). i've left it over 2minutes since transmission was started.
- i like the torrent create area you've done at http://[nasip]/transmission. good work! 🙂 not tested it yet but looks very simple!
- if the start/stoptrans.sh already exist, it should not over-write (unless theres been an update to the scripts :)). saves re-entering your passwords on every update.

[super_poussin]

start.sh and stop.sh are saved I think , let me check if I forget to replicate the change from x86 build to Sparc

[super_poussin]

will publish in a few minutes a b08 let me know if it's better

thanks

[super_poussin]

You can download it 🙂

[super_poussin]

veehexx wrote:

2.01b7 sparc feedback... - long delay when disabling the transmission addon (felt like ~90seconds). starting the addon is fine. - torrents not resuming when transmission starts (torrent ID's are being written to applicable .txt files on disable though). i've left it over 2minutes since transmission was started. - i like the torrent create area you've done at http://[nasip]/transmission. good work! 🙂 not tested it yet but looks very simple! - if the start/stoptrans.sh already exist, it should not over-write (unless theres been an update to the scripts :)). saves re-entering your passwords on every update.

if b08 is always slow for you could it be possible to have ssh access to diagnose ?

[veehexx]

i found the cause of slowness with b08...

it appears the transtop.sh script pauses each torrent after writing the torrent ID to the appropriate .txt; correct operation.
however, it appears to pause 1 torrent per 5 seconds (linked to default 5sec RDC refresh of webgui?), so 20 torrents take 5x20.. 100seconds.
i've not timed it exactly, but it seems about right!
i've tried with 5 active torrents. 5x5 = 25seconds, so my theory seems true.
transmission service is still running, so webgui is still alive; you can see each torrent changing to the pause status as the transmission service closes down.

no change with the transtart.sh either; torrents are not in their last state when starting the addon.

im shooting offline now, but i'll have SSH setup for you tomorrow morning if you still require it!

[super_poussin]

Agree with yes

Yes please, I need to diagnose