forced leeching! | LW 'deletes' finished bittorents from upload queue: how2 share?

[davidf01]

when the LM beta has finished downloading a torrent (btw: thanks for making a brutal obscure procedure into a simple painless one!), some thing happens to the finished file (& the 'dat' file created by 'loading' the torrent into LM): it is treated just like any other limewire file!

the torrent is moved form the 'incomplete' directory to the 'shared' directory.

(btw: it would be nice if these were not peer-level directories but rather parent/child ... and it would be nice if the path for the incomplete directory or an individual incomplete file could be changed _live_ ... not just for the next session but copied/moved for the current session ... sometimes the exigencies of volume management require last moment changes -- but this is actually a 'suggestion', so it is off-topic here ;-).

after the completed torrent has been moved, the remnants of the torrent are deleted from the incomplete directory (the .dat file is gone along with the parent folder, which seems to have the torrent ID embeded into its name).

the result is that sharing of the torrent stops! (uploads instantly stop).

... while it might be the case that the torrent is now shared as a _limewire_ file on a _gnutella_ network, the completed torrent stops participating in the _bittorrent_ swarm.

which is, in effect, like leeching.

i want to continue to make a completed torrent available to the b/t swarm.

how do i do this?

thanx:dlf

[zab]

The torrent should continue seeding. LimeWire suspend uploads just for a few seconds until it moves the file to the complete location, but after that it should continue.

[davidf01]

maybe it's a bug in this beta ...

but:

* no, LM permanently deletes the parent folder (which contains the finished file & its 'dat' companion) from the incomplete directory;
* yes, it does put the finished file into the shared directory;
* no, it does not continue seeding the finished file (from its new location in the completed directory: upload activity stops; and there seems to be no contact from the swarm.

so my question remains:

how do i (re)start the connection to the swarm? (whether or not something went wrong in this beta - this is a general question).

thanx.

[zab]

Is the torrent the only active upload and only active torrent at the time? LimeWire uses slightly different seeding rules than most torrent clients. You can find the details here: http://www.limewire.org/wiki/index.php?title=UploadSlotsAndBT

Basically, a seeding torrent has lower priority than a downloading torrent, and Gnutella uploads fall somewhere in between. However, if the only thing in the uploads panel is that torrent and its not doing anything, we have a bug.

[Only A Hobo]

I have never seen a complely downloaded torrent continue seeding, even with no other uploads running. I have not investigated this too much, and not on recent LW verions, but did wonder if it might be because I do not download to the default location.

[hopalong]

My experience is that LW continues seeding the file in the save(download) folder (it can be shared or not), even over 100%, but I don't see/know, how/when does LW continue seeding after a restart.

[davidf01]

I have never seen a complely downloaded torrent continue seeding, even with no other uploads running

exactly!

once the torrent is finished, ALL UPLOADS ACTIVITY STOPS - 1 minute, 10, minute, 100 minutes, 1000 minutes later!

even trying 'simulate' the pre-finished state of the torrent download does not 'trick' LM into restarting/continuing the seed.

{what i mean by simulation is this: i copy back, into the 'incomplete' folder, the same elements that existed during the download - the 'dat' file, the download file (which is pre-allocated to the full size of the DL when the torrent starts - at least for disk images), and the parent temp folder (which seems to have the torrent ID embeded in its file name). however this revivified torrent infrastructure (which i had deliberately archived because i was nervous for my first torrent in LM) is ignored by LW, judging by the timestamp info which indicates the stuff is never read/or written.

{Note: I have not deployed fseventer to actually log LM's access to these elemnts, but i am pretty sure that the datestamp never changed after simulated the download elements.

{Note: I have also not tried reinitializing LM for ground zero by 'opening' the original torrent "link" file, or whatever it is called}

but did wonder if it might be because I do not download to the default location.

Me too.

Bigger Picture: I never use the default directories for LM because i dont want my boot drive cluttered with hundreds of gigabytes of incomplete downloads that will NEVER be finished because the LM hosts for those files has decided to stop hosting LM :-( ...

so i need to put LM on another partition or volume where i have more flexibility with manual file management.

BTW: it would be nice if LM had some kind of master/merge mode where multiple LM "downloads.dat" files (from different sessions, user accounts, machines, target drives, etc) could be integrated together into a coherent session management system -- i have no idea whether i can ever use the incomplete files from all these different sessions because i did not make a copy of the LM 'download.dat' file before changing the path of a new LM session ....

LM does not make a courtesy copy of this important system file at the sam path as the actual incomplete folder itself; LM keeps the .dat directory only in the static, default, and uneditable location.

so i think that LM overwrites its previous .dat file in the hard-wired path to the data directory with a new one when the path environment changes, but i am not sure.

In any case: maybe there is a bug in LM about restarting torrents if the saved/incomplete paths are not the default value?!

On A Related Note: I am wondering how LM will support incremental backups for 'Time Machine' in Leopard? ... multiple paths, devices, machines -- and now multiple 'states'!

[zab]

What does it say in the uploads panel? Is the torrent uploading or "awaiting for requests" or similar? Does it disappear completely?

Could you get us a log at debug level of the com.limegroup.bittorrent.ManagedTorrent component just when the torrent is finishing? That will help us immensely.

[zab]

something else to try - but first update to 4.14.0 - is to add the following line to your limewire.properties file:

REPORT_BT_DISK_PROBLEMS=1.0

That will let limewire report to us every time something goes wrong with torrents.

[davidf01]

What does it say in the uploads panel? Is the torrent uploading or "awaiting for requests" or similar? Does it disappear completely?

it's been a couple of weeks now, so memory is a bit fuzzy - but i am prestty sure it does NOT disappear as an entry in the U/L panel; it just stops all U/L activity - and maybe the 'waiting' message does ring a bell ...

but i reiterate: the difference in activity is night and day: continuous, regular traffic; then ZERO traffic, FOREVER.

Could you get us a log at debug level of the com.limegroup.bittorrent.ManagedTorrent component just when the torrent is finishing? That will help us immensely.

* where is the debug log? ... it is not on any LM menu!?
* and when i do find it, how do i select for just this one component?

i am using LM 4.13.8

cheers.

[davidf01]

something else to try - but first update to 4.14.0 - is to add the following line to your limewire.properties file:

REPORT_BT_DISK_PROBLEMS=1.0

That will let limewire report to us every time something goes wrong with torrents.

this condition is avail only for 4.14.0? not the version i am using?

... i thought the beta that i am using was the latest release!? ... where is this new version?

anyways, are you asking me to repeat the whole torrent D/L? ... in this case it took nearly a month (very large multi-gigabyte file) ... i presume i could pick anything as a test file for the torrent, yes?

btw: do all torrents have the same LM structure? ...
* folder with torrent ID embeded in the folder's name
* small .dat file that has the target's name appended
* filename itself

cheers.

[zab]

Hi,

You should be able to reproduce the problem with any torrent file. The instructions how to get a log / stack trace are in this sticky http://www.limewire.org/forum/showthread.php?t=107

Were there any other uploads going on? Any other torrent downloads?

[Sam]

I tried reproducing this over the weekend with two torrents and both picked up activity again after the torrents completed (the faster one also managed to pick up while the slower one was still downloading, too). One odd thing I did notice was that after the torrent completed the upload went from "Uploading" to "Awaiting Requests", and then after a long period of time it went back to Uploading.

[hopalong]

My test downloaded 30%, uploaded 19%, now downloading/uploading with 0 KB/s . I'm waiting 20 minutes already. There were no other uploads, only some gnutella downloads. I have one upload queued. The hosts count always grows, 59 now from 20. There's no problem in Azureus with this torrent.

Edit:
After a pause and resume the download and upload continued.

Edit:
Until I had gnutella uploads - usually 3 - the torrent upload/download always broke and continued with pause & resume the download.

Edit:
After the torrent download finished, the gnutella uploads caused no problem, the torrent upload continued and now the torrent is seeding.

[davidf01]

Hi,

You should be able to reproduce the problem with any torrent file. The instructions how to get a log / stack trace are in this sticky http://www.limewire.org/forum/showthread.php?t=107

Were there any other uploads going on? Any other torrent downloads?

logs: ok, i will go look at these instructions.

activity: this was the only torrent (upload or download).

[zab]

After a pause and resume the download and upload continued.


A pause and resume forces a scrape. Otherwise the torrent will wait until the time the tracker specified before scraping again.

[hopalong]

A pause and resume forces a scrape. Otherwise the torrent will wait until the time the tracker specified before scraping again.

It is funny that I had to do this only when there was gnutella upload in progress. How big is this time ? I waited one time even 10 minutes.

[zab]

Different for every tracker. Half an hour seems to be common.

[hopalong]

Interesting. The upload stops in every 2 - 5 minutes and waits so much ? Why don't I see these stops in Azureus ? Why occurs this only when there is gnutella upload ? Time will tell.

[zab]

http://www.limewire.org/forum/showpost.php?p=6326&postcount=4

[hopalong]

Now how can you believe me ? I did gnutella <downloads> together with the "existing downloading BT upload", but I wrote in my later messages gnutella <uploads>. I'm sorry. My original message was the correct: "There were no other uploads, only some gnutella downloads. I have one upload queued" (gnutella).
In the examples I don't see any HTTP download, I had more than half of my upload bandwith free. But my ADSL is very asymmetric, and the upload speed was set to almost the max. I will try with lower upload speed.

[RickH]

My experience is that LW continues seeding the file in the save(download) folder (it can be shared or not), even over 100%, but I don't see/know, how/when does LW continue seeding after a restart.
This is what I've seen too. My completed torrent downloads do seem to seed OK, but only for the remainder of the current LimeWire session. When I eventually have to stop and restart LimeWire for whatever reason, the torrent is always gone from the upload panel (though my downloaded copy is still OK).

When this happens, the only way I've found to restart seeding is to reopen the torrent file and re-download all over again, which isn't practical for large torrents (and wastes bandwidth besides). Azureus has an "append mode" option so that when you try to re-download a file you already (partly?) have, it checks the integrity of the existing part(s) and only downloads whatever's missing or invalid (if any), which can let you quickly resume seeding a saved, finished torrent. LimeWire unfortunately only lets me do the whole download over from scratch (though at least with a choice of whether to overwrite the current copy or start a new one).

I'd like the option to continue seeding a completed torrent across multiple LimeWire sessions. Many torrents are huge and take a long time to download, and need to be seeded for an equally long time (many days, maybe even weeks) to be a good network citizen and pay back the bandwidth. If I spend 3 days downloading and then stop seeding after just a few hours due to a restart, I'm leeching. Also, sometimes I like to host a torrent for a long while, and continue seeding it long term regardless of any leeching issues.

Maybe there could be an option, "Continue seeding until canceled" or similar?

[hopalong]

"Continue seeding until canceled" or similar?
This would be especially important for everybody with very asymmetric ADSL (one day download, ten day upload)

[hopalong]

But my ADSL is very asymmetric, and the upload speed was set to almost the max. I will try with lower upload speed.

I lowered my upload speed to 25 KB/s, my max is about 40-45 KB/s.

In a new test there was no upload, neither BT, neither gnutella.
I've downloaded one torrent (8.5 MiB), with or without gnutella download.

1st third-time: no gnutella download - no problem with torrent download.

2nd third-time: there was 10-4 gnutella download; the torrent download always stopped, I had to pause/resume it to continue. Sometimes the bt download continued only for 10-30 seconds.

3rd third-time: there was only 3 gnutella download with very low speed (<10KB) - no problem with torrent download.

My speedtest is 6545/348 kb/s.

[davidf01]

This would be especially important for everybody with very asymmetric ADSL (one day download, ten day upload)

my isp (rogers) high-speed offers 6000kbps down / 800kbps up ...

* in my download experience, for some special cases, have been able to get non-p2p apps use all the 6Mbps bandwidth; but generally 1-2Mbps is the average speed when not connected to web sites that do not have well-supplied servers.

The torrent that i received in LM averaged about 20-40kbps (that is only dial-up throughput on broadband!!) when the swarm size for this torrent was 5 to 10; the peak rates for this torrent were only 200-400Kbps (these might be sustained for a few seconds or even for a few minutes).

so a 6GB torrent took nearly one month to complete .... not a day :-)

* LM uploads averaged about 10-20Kbps; i seldom saw any peak bursts.

My hunch is that the disparity between the bandwidth available p2p and the bandwidth for other apps can be explained as part of a conscious design by the isp ot use traffic shaping tools.

It is well-known that 50% of ISP bandwidth is consumed by p2p - so i can appreciate their motives to manage traffic ....

but i wonder whether this de facto form of QoS is a non-tariff price, and i also wonder how traffic shaping is permitted in the ISP's contract; and whether what the license from telecoms regulators says regarding how incumbent isp's (as opposed to branded co-located vpn ISP's) can pick & choose which bytes are delivered with what priority?!

[Aaron.Walkhouse]

The CRTC has already wimped out on that, claiming they have no say in the matter.

Rogers is definitely one of the worst ISPs out there, according to public opinion.
If you can, see if you can get DSL from Telus. It may appear slower on paper but in
actual use it is solid and not tampered with by illegal censorship.