Transmission unMenu package

[DonRaid]

Is there any documented problems with using the cache disk for incomplete downloads, or folders that start with a dot in the path? I have Transmission set to Full preallocation and I've added a torrent but I can not get it to actually preallocate nor does it download anything at all so far (had the torrent active for a couple hours now).

 

The only setting I have not touched so far is "/mnt/cache/.incomplete".

[BRiT]

No. There are no such issues. I use /.downloads/ as the root of my download hierarchy that's not touched by the mover script, specifically .downloads/cache/, .downloads/extracted/, .downloads/import/, .downloads/imported/, .downloads/incomplete/, .downloads/logs/. They are shared between Transmission and SABnzbd for torrents and usenet.

 

If you're having issues with a particular torrent, have you tried a different one? Also, do you have the directory and file permissions properly configured so the process can write to them?

[DonRaid]

I have 3 torrents running all of them working just fine on the other computer which makes me believe there is nothing wrong with the files. I've shutdown the process and started it and it's running as root so it should have no problem what so ever writing.

 

I'll go get ubuntus torrent and test with that as well

[theone]

From what I see transmission write to the "stats.json" file and "resume" folder about once every 2 minutes (changes in the modified date of the file).

 

I get about 250 write to the flash drive every 30 minutes --> 12000 every day if it keeps going like that.

 

I haven't found out yet what is doing all the writes though...

 

 

To continue...

 

the count has increased by ~8000 write in 17 hours which gives a rate of ~12000 in 1 day (as stated before).

 

To test if this is transmission, I paused the only torrent I have currently running (transmission is still running though) and indeed the write count has stopped (not increased) at all in the last 50 minutes (should have increased by about 400 at the regulate rate.

 

In my case I conclude that it is transmission.

 

How can this be solved?

 

[prostuff1]

To continue...

 

the count has increased by ~8000 write in 17 hours which gives a rate of ~12000 in 1 day (as stated before).

 

To test if this is transmission, I paused the only torrent I have currently running (transmission is still running though) and indeed the write count has stopped (not increased) at all in the last 50 minutes (should have increased by about 400 at the regulate rate.

 

In my case I conclude that it is transmission.

 

How can this be solved?

 

Thanks for doing some testing, I will look into this as soon as I get a chance (probably this weekend) and provide a new .conf file to JoeL for inclusion into unMenu.

 

I am not quite sure how I am going to solve this at the moment, but will take suggestions.  My first thought is to move the file to RAM (/tmp for example) and then link to it from the flash drive (not sure if this will work since the flash drive is FAT32 fs and not resier).  Then when transmission is shut down (via the script included to start, stop, and kill it) I will copy it back to the flash drive to preserve any updates that were done.

 

The other thing I am thinking about is seeing if there is a way to disable the stats tracking all together... I will look into it when I get a chance, and if anyone ones to do the research for me that would be spectacular!!

[funbubba]

Thanks for doing some testing, I will look into this as soon as I get a chance (probably this weekend) and provide a new .conf file to JoeL for inclusion into unMenu.

 

I am not quite sure how I am going to solve this at the moment, but will take suggestions.  My first thought is to move the file to RAM (/tmp for example) and then link to it from the flash drive (not sure if this will work since the flash drive is FAT32 fs and not resier).  Then when transmission is shut down (via the script included to start, stop, and kill it) I will copy it back to the flash drive to preserve any updates that were done.

 

The other thing I am thinking about is seeing if there is a way to disable the stats tracking all together... I will look into it when I get a chance, and if anyone ones to do the research for me that would be spectacular!!

 

zheka_ppp posted his workaround in the previous page.  Which sounds to me like creating a custom transctl elsewhere, then stop transmission and then start it back up using the edited transctl.  I, on the other hand, edited transctl and replaced the file in the package itself. 

 

Would it be possible to create another variable in the unmenu package, then have the auto_install build transctl using the new variable?  That might be a bit drastic though.

[Joe L.]

Thanks for doing some testing, I will look into this as soon as I get a chance (probably this weekend) and provide a new .conf file to JoeL for inclusion into unMenu.

 

I am not quite sure how I am going to solve this at the moment, but will take suggestions.  My first thought is to move the file to RAM (/tmp for example) and then link to it from the flash drive (not sure if this will work since the flash drive is FAT32 fs and not resier).  Then when transmission is shut down (via the script included to start, stop, and kill it) I will copy it back to the flash drive to preserve any updates that were done.

 

The other thing I am thinking about is seeing if there is a way to disable the stats tracking all together... I will look into it when I get a chance, and if anyone ones to do the research for me that would be spectacular!!

 

zheka_ppp posted his workaround in the previous page.  Which sounds to me like creating a custom transctl elsewhere, then stop transmission and then start it back up using the edited transctl.  I, on the other hand, edited transctl and replaced the file in the package itself. 

 

Would it be possible to create another variable in the unmenu package, then have the auto_install build transctl using the new variable?  That might be a bit drastic though.

I don't use transmission, but if you tell me what needs to be changed, it can be put in the version distributed by unMENU.

[prostuff1]

I don't use transmission, but if you tell me what needs to be changed, it can be put in the version distributed by unMENU.

 

I don't know the exact changes but essentially what needs to happen is that the transmission.conf folder needs to be copied up into ram (or to a disk), the TRANS_CONF variable in the transctl script needs to be edited, before stop it needs to be copied back to the flash drive, and before start it needs to be copied up RAM.

 

I may have missed something but I am not around my server right now to do a full vetting of the steps.

 

zheka_ppp a page back is doing essentially the above.

[theone]

The other thing I am thinking about is seeing if there is a way to disable the stats tracking all together... I will look into it when I get a chance, and if anyone ones to do the research for me that would be spectacular!!

 

I opened a question thread on the transmission forum regarding this:

https://forum.transmissionbt.com/viewtopic.php?f=1&t=11183&p=52013#p52013

 

It seems there is no way to disable the stats file and the ".resume" seem to be important.

 

[funbubba]

It sounds to me like writing to RAM vs disk would produce two drastically different procedures. 

 

Where writing to RAM would require transmission.conf copied from flash to tmp on start, then back to flash when stopped or killed. 

 

On the other hand, when writing to disk, it could just stay there.  No other changes to stop/start.

 

When written to RAM, I'd be cautious about what happens when the server shuts down un-gracefully.  That could be disastrous (relatively speaking) if you're actively seeding +100 torrents.  Unless you've got a cron job that regularly writes the resume files back to flash to mitigate that scenario.

 

Actually, speaking of which, how does powerdown handle shutting down Transmission?  I remember bad things happened and I had to re-verify more than a few torrents.  It could be an isolated incident though but I've been stopping Transmission manually prior to shutting down just in case.

[prostuff1]

It sounds to me like writing to RAM vs disk would produce two drastically different procedures.  

 

Where writing to RAM would require transmission.conf copied from flash to tmp on start, then back to flash when stopped or killed.  

 

On the other hand, when writing to disk, it could just stay there.  No other changes to stop/start.

 

When written to RAM, I'd be cautious about what happens when the server shuts down un-gracefully.  That could be disastrous (relatively speaking) if you're actively seeding +100 torrents.  Unless you've got a cron job that regularly writes the resume files back to flash to mitigate that scenario.

You are correct, it is not a great solution to put this in RAM, but I prefer to keep this kind of stuff off my data drives... It is a toss up really.

 

Actually, speaking of which, how does powerdown handle shutting down Transmission?  I remember bad things happened and I had to re-verify more than a few torrents.  It could be an isolated incident though but I've been stopping Transmission manually prior to shutting down just in case.

The Powerdown package will kill anything that will not stop gracefully.  You can edit the powerdown script to stop/kill transmission gracefully.

[theone]

You are correct, it is not a great solution to put this in RAM, but I prefer to keep this kind of stuff off my data drives... It is a toss up really.

 

How about placing it in the cache drive or other out of array drive (I have one for downloading torrents) or make it configurable.

 

[prostuff1]

You are correct, it is not a great solution to put this in RAM, but I prefer to keep this kind of stuff off my data drives... It is a toss up really.

 

How about placing it in the cache drive or other out of array drive (I have one for downloading torrents) or make it configurable.

 

 

I will make it configurable on where the user will want it to be saved, it is just a matter of figuring out the best way to do it.

[theone]

You are correct, it is not a great solution to put this in RAM, but I prefer to keep this kind of stuff off my data drives... It is a toss up really.

 

How about placing it in the cache drive or other out of array drive (I have one for downloading torrents) or make it configurable.

 

 

I will make it configurable on where the user will want it to be saved, it is just a matter of figuring out the best way to do it.

 

If it is saved on data/cache drive then it doesn't even have to be moved back to flash.

 

 

from transmission forum:

What version are you using? Latest release is 2.13 and beta is 2.20.b2. Resume and stats are only written to every 6 min. (at least with 2.13+ so, if you can, please try 2.20.b2).

[theone]

You are correct, it is not a great solution to put this in RAM, but I prefer to keep this kind of stuff off my data drives... It is a toss up really.

 

How about placing it in the cache drive or other out of array drive (I have one for downloading torrents) or make it configurable.

 

 

I will make it configurable on where the user will want it to be saved, it is just a matter of figuring out the best way to do it.

 

Any updates on this issue? I am refraining from using transmission until this is solved - I would rather have my flash not die on me along with the unRAID license.

 

 

[prostuff1]

You are correct, it is not a great solution to put this in RAM, but I prefer to keep this kind of stuff off my data drives... It is a toss up really.

 

How about placing it in the cache drive or other out of array drive (I have one for downloading torrents) or make it configurable.

 

 

I will make it configurable on where the user will want it to be saved, it is just a matter of figuring out the best way to do it.

 

Any updates on this issue? I am refraining from using transmission until this is solved - I would rather have my flash not die on me along with the unRAID license.

 

 

 

I will be looking into this today and tomorrow.  Hopefully will have something up in the next 3 days or so once I get testing done.

[nia]

I will be looking into this today and tomorrow.  Hopefully will have something up in the next 3 days or so once I get testing done.

Great - I've had it with uTorrent - the last version is completely unuseable crashing, hogging ressources and whatnot, so I'll be trying to go for whatever you come up with.  

[theone]

I will be looking into this today and tomorrow.  Hopefully will have something up in the next 3 days or so once I get testing done.

 

If you need help testing I don't mind helping if I can.

 

[prostuff1]

I will be looking into this today and tomorrow.  Hopefully will have something up in the next 3 days or so once I get testing done.

 

If you need help testing I don't mind helping if I can.

 

 

OK, I will let you know.  I did get to work on this a little over the weekend but since I was away from my servers did not have a chance to test it.  I should be able to do that in the next couple of days and see how it goes.

[Beardo]

Hi,

 

Was there any progress in regards to the write-to-usb-stick issue?

 

And thanks by the way for looking in to it....

 

 

 

[prostuff1]

Hi,

 

Was there any progress in regards to the write-to-usb-stick issue?

 

And thanks by the way for looking in to it....

 

 

 

 

I got some of it done, though it is not complete.  I have been incredibly busy with work this week and my other programming on the side. I should have a free night tonight so will look at it further and hopefully get something put together. Once that is done I will test it and push it off to JoeL for him to test and include in the next unMenu release.

[theone]

Not to be too pushy, but have you got around to implementing the write-to-flash solution?

 

As I said before I wouldn't mind testing it.

 

[prostuff1]

Not to be too pushy, but have you got around to implementing the write-to-flash solution?

 

As I said before I wouldn't mind testing it.

 

 

Yeah, I am working on it.  I have been under the weather since Saturday (fever and the whole 9 yards) so have not been able to concentrate on anything for any extended period of time.

 

I am finally getting better (plus I have Monday off next week) so should be able to get something out there.

 

If I did my initial testing correctly there are a few edge cases that I need to take care of.

[theone]

Yeah, I am working on it.  I have been under the weather since Saturday (fever and the whole 9 yards) so have not been able to concentrate on anything for any extended period of time.

 

I am finally getting better (plus I have Monday off next week) so should be able to get something out there.

 

If I did my initial testing correctly there are a few edge cases that I need to take care of.

Get well soon.

 

[Fred]

Is there a way to change where transmission writes resume data?  I am getting what I believe to be a large number of writes coming from transmission, 10s of thousands of writes a day and they all seem to be the same directory, flash/custom/transmission/transmission.conf/resume.  If I could somehow put the resume data (or even the whole transmission install if needed) on my cache drive that would be great.

 

I have checked and if I stop transmission I have almost no writes to my flash drive after initial boot up.  If I start transmission again I end up with thousands of writes again in only a few hours.  This is all with only a single torrent running (my torrent usage is fairly low, I download only one motorcycle race a week that I cannot find anywhere else).  I would guess the writes would be much higher for people that use transmission more heavily, are others seeing this behavior or is it something unique to my setup?

 

I noticed this too.

My first solution was just to copy directory to hard drive, somehow like this:

cp -r /boot/custom/transmission/transmission.conf /mnt/disk2/share/torrents/

 

and then simply edit script /boot/custom/transmission/transctl, variable TRANSCONF to point to the new location

(remember to use CR-LF safe editor)

 

This worked, but I was not satisfied becuase 90% time my NAS is only seeding and this writes keep my parity drive spun up.

So I made additional transctl script: added copying transmission.conf to /tmp before start and copy back to hard driver on transmission stop. And new TRANSCONF value point to /tmp/transmission.conf.

 

Good luck !

 

 

I used the first step only since I am using my cache disk for torrents and it worked perfectly.  When I noticed this thread and checked my Flash drive status in MyMain it already had hundreds of thousands writes  for 4 days uptime, and I've been using this package for a long time so it definatly got millions hits from this.  At least now it's fixed!  Thanks for the tip.