Jump to content

uTorrentPartFile growing


ady4um

Recommended Posts

I am using ut 1.7.7 stable, Vista SP1, Windows Firewall, cable modem, no router.

Trying to solve some problems, I run beta 10524 encapsulated (/recover). I copied the .torrent file to another location (from the folder the 1.7.7 version is reading it from) and add it to the ut beta 10524. I set the download location of the data of this .torrent file to be the same location as before, when using the stable version. I skipped all the files while adding it to the beta. After that, I selected all the files I already have downloaded and changed them to normal. Forcing re-check, ut gave me a first surprise. Several first and last pieces were not shown as completed, even all those "missing pieces" were part of subsequent (*both* downloaded) files. I was not sure if this was having anything to do with my original problems, so I let ut beta downloading this "missing" pieces (again). After that was done, I "unskipped" 1 more file and download it. Since my speed-problem situation was not improving, after finishing downloading this file I stopped and quit the beta. BTW, I did not erase the torrent job from it, nor any other file from its encapsulated folder.

I returned to the (also encapsulated, but in another folder) stable ut 1.7.7 version, force re-check, and all files were ok, including the file I downloaded using the beta. No "missing" pieces this time. But then I noticed the uTorrentPartFile in the download location was about 48 MB. Since then, I've been unskiping subsequent files in this torrent and the uTorrentPartFile is still growing, now to 59 MB. Sorting the files by the "First Piece" column, the skipped files are altogether in the middle. I have downloaded the first ones (about 60 of them), and the last ones (about 30). So the currently skipped files are altogether, in the middle of the torrent as I said before. When unskiping a file, I choose a file next to the ones I have already downloaded (the first file of the skipped files, or the last one of them).

It's like:

1st group dl file 1

1st group dl file 2

...

1st group dl file 60

first skipped file

...

skipped files

...

last skipped file

2nd group dl file 1

...

2nd group dl file 30

The pieces of this torrent are each 4 MB. If I understand correctly, in my situation the max amount of pieces I downloaded which are not being used by a file, are just 2. 1 piece is the last piece of the "1st group dl file 60", which is also part of the "first skipped file". The other 4 MB piece is the one sheared by the "last skipped file" and the "2nd group dl file 1". This should be max 8 MB, not 48 MB.

So why is the uTorrentPartFile so much bigger than those 8 MB?

And why is this uTorrentPartFile getting bigger while I'm actually downloading subsequent pieces?

Thank you in advance.

Link to comment
Share on other sites

Well, I have forced re-check several times, so I suppose they are being saved properly. ut 1.7.7 say nothing about the saved files and id them as ok, but as I said before, when the same location was checked using beta 10524, ut wanted to dl several limit-pieces. I let ut 10524 to dl again, quit after that, went back to ut 1.7.7, re-check, still all ok. Is there anything else I can do to check the files? I sthere any bug in 10524? I'm using 1.7.7, and just wanted to try the beta to check if I can get better steady ul speed, so I can improve the dl speed. The uTorrentPartFile gets bigger just after downloading a new unskipped subsequent file in the torrent and quiting ut. During the dl, the uTorrentPartFile is not growing, and its modofied date is still the date of the previous finish-dl-and-quit-ut event. Any ideas? Did I understand correctly how the uTorrentPartFile SHOULD work (as I described in the first post of the thread)?

Link to comment
Share on other sites

Well, if the partfile is growing but your files are still being saved normally, then it's just a bunch of skipped pieces being saved to it.

The reason your partfile is large is that you probably had several in-progress pieces from the files that you skipped, so they all went to the partfile (as ut does not cancel in-progress pieces from skipped files). The only way to avoid that is to skip all files before ever starting the torrent.

Link to comment
Share on other sites

So you are saying ut is downloading pieces I'm not interested right now (maybe later), instead of focusing on the pieces I really want, and using my not-so-great-and-throttled bandwith.

And what about the beta behaviour? Why ut 10524 didn't recognize several pieces? Maybe I was supposed to use a different download location? I just wanted to try it, not to replace the stable version completely. I also wanted to take advantage of the downloaded pieces using the beta, and I don't have enough HD space to *copy* the whole torrent to a new location just to try the beta. That's why I used a different encapsulated folder for ut, but the same download location for that torrent. Can you tell me if this was an acceptable choice? Should I have used any other method to test the beta? Was this beta behaving as expected when trying to dl pieces again that already were there? If I want to check a new beta build - just to try it and go back to the stable version -, which is the right procedure (in case the procedure I used wasn't the right one)? Should I expect ut beta to dl pieces like that? Is there any way to avoid this beta behaviour?

Sorry if these are too many questions. I just want to improve my throttled-speed situation, and lern something for future reference (and maybe I just found a bug in ut beta?). Thank you all for help me understand, improve and lern.

Link to comment
Share on other sites

Ok, so I understand correctly and there *is* a bug in the 10524 beta. Because, as I said before, I used 1.7.7 to dl. Then, *after* I finished downloading the unskipped files and the pieces tab was empty, I paused and then stopped the torrent and forced re-check. Then I quit ut stable. I copied the .torrent file to another folder, where I also put the beta. I ran the beta encapsulated in its own folder with /recover /noinstall. At no time the stable version was running while the beta was on. I added to the beta the copied .torrent file, and I chose for the download location the *same* location where the already unskipped files were saved. While adding the .torrent file to the beta, I also chose to skipped all the files (I don't remember if I did this when I originally added the torrent to the stable version). In the beta, I unskipped 1 or 2 files to see what happens when I re-check. Since everything was fine, I unskipped all the files I already knew were there in that location, saved and checked completely by the stable version. I was expecting ut to show me - in the worst case - just 2 pieces not be downloaded completely (according to the scheme I presented above in a previous post of this same thread). Also, was *hoping* that ut could be smart enought to look for that pieces in the uTorrentPartFile, since the donload location was the same, and the stable version was off. Well, the "hope-situation" was just a hope. But instead of seeing the expected, just 2 pieces to redownload, I saw several. I thought maybe this pieces were not ok as the stable ut said, so I let the redownload. When this was over, I unskipped 1 more file, let it finish, pause, stop, force re-check. Everything was fine. but I wanted to return to the stable version, specially since the beta was not helping me with my very poor speed problem. So I quit the beta. Back to the stable version, I force again a re-check, and everthing was fine, including those redownloaded pieces and the new unskipped file.

Now that I detailed what I did and how I did it with the beta, maybe you can see why maybe there is some bug there, either at the beta or at the stable version. Is a bug, or I did not understand Firon's last answer.

Link to comment
Share on other sites

You're describing something completely different than what is happening... or something.

When files complete their data is removed from the partfile... your large partfile usage is either due to alot of alternating skipped and downloading files or you're using compact allocation + skipped files (explicitly disallowed in 1.8).

Rechecking no in-progress pieces doesn't lose anything. You don't run /RECOVER when only running one client. Files are still checked when skipped. You will get at minimum 2 pieces in the partfile (being RED) between each skipped file. On a large piecesize this can lead to ALOT of data... so don't skip lots of ranges of files. ... And your last statment is neither detailed nor clear.

"I wanted to return to the stable version, especially since the beta was not helping me with my poor speed problem. So I quit the beta. Back to the stable version, I force again a recheck, and everything was fine, including those redownloaded pieces and the new unskipped file" ... Speed problems are usually not solved by client version switches. Places where 1.8 improves speeds includes some network shaping practices... or if you're using UPnP. Forcing a recheck with no in-progress data doesn't lose or gain anything.... unless you have incompatible software somehow corrupting the read/save to/from disk.

Picture of your files tab would be more useful than your descriptions tbqh.

Link to comment
Share on other sites

Ok, I thought my description in the first post of this topic was clear. I apologise for that.

I have a picture of the current status of the file tab in ut 1.7.7. I've seen people pasting images/pictures directly in the forum. The picture is 15 kb jpg, 96 dpi x 96 dpi, 24 bit colors. Is this adequate? How can I paste it directly into the forum?

BTW, I think you are saying the same I am. If you can tell me how to paste my screens I think you could see that.

Thank you.

Link to comment
Share on other sites

I hope you can see the following images of the files tab in ut 1.7.7. Note the file tab is ordered by the *first piece* column. Even if the resolution is not good enough to read, the "Pieces" column in the files tab is what you need.

As I said before, first I have subsequent unskipped files, then subsequent skipped files, then again subsequent unskipped files till the end. So no skipped files "everywhere", but just several groupped together subsequent unskipped files (when ordered by *first piece* column). Also, as I said before, compact allocation is disabled.

Fist, subsequent unskipped files, then:

9f1d66b9430d53f176e16ab63fa121971g.jpg

then subsequent skipped files, and then:

520c3581d4ed9a5b13108f1b0e4ca2a11g.jpg

then subsequent unskipped files till the end.

The ut beta 10524 did *not* check all the skipped files, just the ones I selected as unskipped. Of those, ut 10524 showed first and last pieces of several *subsequent* unskipped files (not all of them) as not downloaded. I let ut download those again. Moreover, neither the beta nor the stable version seems to take advantage of the pieces already downloaded inside uTorrentPartFile. Not once I saw pieces of a just unskipped file automatically copied from the uTorrentPartFile to the actual file. I should have seen this happening, by ut making pieces directly blue when just unskipping a file, instead of downloading everything (pieces in green). Of course, in such a case I would be talking about the first and/or the last pieces of a just-unskipped file. I am unskipping 1 file at a time (skip -> high), when the file is finally complete, after quiting ut the uTorrentPartFile should be *smaller*, not bigger which is the current situation. It has grown up to 61560 KB now.

I wish I could show you a picture of the files tab of ut beta 10524, but I did't take any screenshot of that. I hope now I was clear enough, but don't hesitate to request more info. I really want and need your help, from all of you. And hopefully maybe we can get to also solve a bug.

[EDIT]

According to the date and time of the uTorrentPartFile file, the file is refreshed not every time I close utorrent, but every time I open it. I suppose actually it is saved every time I open ut and the torrent is active. In the meantime, anyone can help me solve this problem? It keeps growing every day (63 MB now), and my dl speed is less than 4 kB/s, so every MB saved in this file is serious waste.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...