Resume.dat

[artie11]

I'm trying to work out the formatting of your resume.dat file, i'd like to create a web interface for utorrent as an external sort of add on.

I'm understanding most of it just from a quick look at it, however the upload speed and download speed fields are confusin me a bit here, i'm happy to use the the downloaded and uploaded and divide over the time field, but it's so inaccurate,

i've got listed a few different things here

upspeedi0e5

downspeedi0e4

they don't seem to have any relevance to the data provided by utorrent, are they just place holders, the other fields it seems i'd need to ignore the e7 or whatever the last two fields are to get the correct value for the field,

i've got utorrent running on multiple machines i use, however i'd like to place a permanant box i can connect to via http so that i don't use all the tcp connections on my local machine, i'd also like to use utorrent because it is the cleanest torrent program i've seen to date, there is existing php based interface, torrentflux, however it's still quite messy, and if i can access the utorrent data it couldn't be too hard.

[Firon]

We're already making a web interface. Right now it's an AJAX interface, but I do believe Directrix is gonna make a "normal" HTML interface too.

[artie11]

well if you need any help, it's what i do for my living, databases and php frontends, with ajax ( i love ajax )

[Firon]

You can speak with Directrix on the IRC channel about that. I'm sure he wouldn't mind some help.

[Animorc]

artie11: I made a half-working script to read the active downloads:

$down_filter="downloadedi";

$up_filter="uploadedi";

$resume_file="PATH_TO_RESUME.DAT";

$file_open=@fopen($resume_file,r);

$file=@fread($file_open,@filesize($resume_file));

preg_match_all("#:PATH_TO_.TORRENT_FILES(.*?\.torrent)d\d#i",$file,$info);

preg_match_all("#$down_filter(\d+)#i",$file,$down);

preg_match_all("#$up_filter(\d+)#i",$file,$up);

for($i=0;$i<count($info[1]);$i++){

for($j=0;$j<count($down[1]);$j++){

$down_unit=0;

$downloaded=$down[1][$i];

while($downloaded>1024){

$downloaded=round($downloaded/1024,3);

$down_unit++;

}

}

for($k=0;$k<count($up[1]);$k++){

$up_unit=0;

$uploaded=$up[1][$i];

while($uploaded>1024){

$uploaded=round($uploaded/1024,3);

$up_unit++;

}

}

$down_unit=($down_unit==0?"Bytes": ($down_unit==1?"kiB": ($down_unit==2?"MiB": ($down_unit==3?"GiB":"TiB"))));

$up_unit=($up_unit==0?"Bytes": ($up_unit==1?"kiB": ($up_unit==2?"MiB": ($up_unit==3?"GiB":"TiB"))));

echo "[ <span style=\"color: #d00;\">".substr(strrchr($info[1][$i],"\\"),1)."</span> ] Downloaded: [ <span style=\"color: #d00;\">".$downloaded." $down_unit</span> ] Uploaded: [ <span style=\"color: #d00;\">".$uploaded." $up_unit</span> ]<br />";

}

Note that the backslashes (\) in PATH_TO_.TORRENT_FILES needs to be written in threes (\\\) for it to work.

I'm sure there are better ways of getting this to work, but it reads the torrent name, downloaded and uploaded values in resume.dat. It might not even work after the updates, but it did for version 1.2 or so.

Well, that's the best I could do, and I'm eagerly waiting for the web-monitor.

Edit: Damn smilies. Remove some spaces in the $down_unit=($down_unit... and $up_unit=($up_unit... lines

[Directrix]

As you probably don't (maybe you do) know resume.dat has been bencoded. I wrote this code last week (or something) that opens resume.dat to get info and also opens each individual torrent file to get other info that you might want.

<?php

$content = file_get_contents('C:\Documents and Settings\_username_\Application Data\utorrent\resume.dat');

include('./BDecode.php');

$info = BDecode($content);
unset($content);

foreach($info as $key => $value)
{
    $size = 0;
    $content = file_get_contents($key);
    $tinfo = BDecode($content);
    unset($content);
    $name = addslashes($tinfo["info"]["name"]);
    if (isset($tinfo["info"]["files"]))
    {
        foreach ($tinfo["info"]["files"] as $file)
        {
            $size += $file['length'];
        }
    } else
    {
        $size = $tinfo["info"]["length"];
    }
    $hash       = unpack("h*", $info[$key]['info']);
    $hash       = $hash[1];
    $started    = $info[$key]['started'];
    $downloaded = $info[$key]['downloaded'];
    $uploaded   = $info[$key]['uploaded'];
    $added      = $info[$key]['added_on'];
    $runtime    = $info[$key]['runtime'];
    $time       = $info[$key]['time'];
    $peers      = strlen($info[$key]['peers']) / 6; //6 bytes per ip + port
    //echo...
}

?>

You can get the average download and upload speeds by dividing $(down/up)loaded by $runtime. To see all the info you can get just var_dump $info or $tinfo.

All you need is BDecode.php from here. Download the latest version of TorrentParse. From observations, I've found out that resume.dat gets updated every minute (or so). Happy programming then!

[TwoD]

I've written a parser for resume.dat in JScript for Samurize (www.samurize.com for those who haven't discovered it yet) and it works great. The script is called uTorrent Monitor 1.0, version 1.1 is done but I have not released it yet when writing this.

Anyway, to the point:

Would the autor(s) of uTorrent be generous enough to post the details about the serlialized object in resume.dat?

I've got most of it sorted out, but some things are still unclear. Such as, is "blocksize" related to the blocksize in the torrents?Doesn't seem to be related since it appears to always be 16384=128^2, which is why I'm thinking it only has to do with the download progress on each individual block in the blocks list. (they're listed as having a size of 128)

What I have so far:

Encoding is by default ASCII since that's what BEncoding supports. If a byte value above 127 is encountered UTF-8 encoding is assumed.

info - the hash.

added_on - UNIX timestamp in seconds.

peers - A list of IPs and ports (6bytes each).

dht - unsure, dht mode?

blocks - a list of the partially downloaded blocks, bit-maps?

blocksize - the size of the partially downloaded blocks?

downloaded - Total dl amount in bytes

uploaded - Total ul amount in bytes

downspeed - max allowed down speed (bytes/s?, not tested)

upspeed - max allowed up speed...

have - a bit map of the downloaded blocks. Each block is represented by a bit, padded to next full byte.

moved - [0/1] has been moved after download complete

order - downloading prioriority. -1 if seeding.

override_seedsettings - [0/1] overriding settings...

path - string with the full path to the downloaded file/folder.

prio - a byte-mask for file priority. Each file is represented by a byte. The byte values are: 12=high, 8=normal, 4=low, 0=don't download.

prio2 - not sure, only noticed the value 1.

seedtime - how long the torrent has been seeding in seconds

runtime - how long the torrent has been running in seconds

superseed - [0/1] superseed on/off

label - the label

trackermode - the values I've seen are: 0=no contact made yet, 1=downloading, 3=seeding, what's 2?

started - 0="not started", 1="forced start" and 2="started"

ulslots - the number of upload slots

trackers - a list of the trackers..

wanted_seedtime - the time limit at which to stop seeding

wanted_ratio - divide by 100 to get the ratio at which to stop seeding

valid - [0/1] has passed validation

Could anyone confirm this for me and maybe fill in some blanks?

[TwoD]

Version 1.1 of uTorrent Monitor has been out for some time, and version 1.2 is soon to be released.

Meanwhile I found out a few more things about this file...

additions in µTorrent 1.6:

caption - the original name of the torrent.

hashfails - a counter for the total number of hashfails

completed_on - UNIX timestamp for the completion date

waste - number of downloaded waste bytes.

I still need info about the blocks and blocksize keys...

Can they be used to calculate the size of the blocks in the have list?

[leChameleon]

Objective:

Initially all torrent files input into uTorrent were stored by uTorrent on C:\Documents and Settings\<user>\Application Data\uTorrent\ and added to the resume.dat file hard coded to this path.

I would like to relocate the torrent information to D:\... for example however I have thousands of torrent files and I don't want to have to manually input every one of them again.

Comment:

I've reviewed most of the posts regarding the resume.dat topic and haven't found anything of this sort posted so far. If I've overlooked something or have mis posted this message please forgive me as this is my first time posting a message to this forum.

Methodology(s):

1. RELOCATE FILES AND HACK RESUME.DAT

I'm not sure of the best methodology to approach this task other than to figure out some sort of input script to parse C:\Documents and Settings\<user>\Application Data\uTorrent\resume.dat and replace string A with string B.

I don't know why uTorrent was setup to collect all torrent files in a given location then hard coded their path in a binary file. I find this makes it difficult to span several disk drives in several locations and keep things updated in uTorrent when we need to make hardware/system changes.

2. SCRIPT TO INPUT ALL TORRENTS (FRESH START)

Perhaps the best way is to write a script to automate the input all torrent files again into uTorrent and associate them to their respective folders/directory's and other settings.

Any assistance on this is greatly appreciated.

[Ultima]

http://www.utorrent.com/faq.php#How_can_I_use_.C2.B5Torrent_on_a_USB_key_or_other_removable_drive.3F

The only place µTorrent will look for resume.dat is where settings.dat is located, and the only twp places µTorrent will look for settings.dat are the directory its executable is currently located in, or %appdata%\uTorrent (in that order too). If you need to place it somewhere else, then take the latter path and place utorrent.exe with settings.dat and resume.dat wherever you need it to be. Otherwise, I suppose you can try using some kind of junction point.

[leChameleon]

Hi Ultima,

Thank you for replying to my question. I'm familiar with uTorrents current restrictions as we've tested this to ensure our understanding.

The complexity that we're faced with is mounting for example 10TB of data thus you can expect to have multiple 500GB drives. The original torrent and its corresponding folder resides on one various hot-swap drives. Today uTorrent stores the copied torrent files in either "%appdata%\uTorrent" and/or some other single specified location.

As we started our project we defaulted to use "%appdata%\uTorrent" the standard. As you can imagine that folder now contains quite a bit of data and the resume.dat file is quite large. If I were to swap out drive X for example and plug it back into drive-bay Y for example the way uTorrent is configured today I would have to remove (in uTorrent) all corresponding defined torrents pointing to "X" and manually enter them again to "Y".

Example:

Original mount:

X:\myData_001\

myTorrent.torrent (original torrent for data, not the one copied by uTorrent).

myData_001_rev194

Re mounted:

Y:\myData_001\

myTorrent.torrent

myData_001_rev194

Since uTorrent had codes the path in a binary file there is no way to edit it. If it were ASCII I could manage this myself. I don't quite follow the reasoning that uTorrent has to make a duplicate copy of the original torrent other than for faster referencing since the other mounted disks could be located in different geographical regions (i.e. France, India, Brazil, China, Japan...).

If there was some way to re-input the data into uTorrent again via some script one could remove the bad torrent definitions pointing to X manually then run a script to re-input the data again pointing them to Y.

From my current understanding of how uTorrent was designed it would take some rearchitecting to accommodate the more elaborate setup that we've setup for our project. I don't expect uTorrent to change at least right away if it had plans to so I'm seeking an alternative workaround. If I knew how to write the resume.dat file in binary format I could try that as well.

At this point I don't know how to rectify my unique problem other than to manually enter each torrent (one at a time) to correct any "unresolved" path locations.

Thank you,

leChameleon

[DreadWingKnight]

The resume.dat and other configuration files are bencoded (which isn't quite binary).

A proper bencode editor could mass-change the targets.

[leChameleon]

Hi DreadWingKnight,

Can you recommend a proper bencode editor that I might use to make these global substitutions? I'm not at all familiar with this type of file format so please excuse my ignorance.

Regards,

leChameleon

[crashnburn]

LC, DWK - Did you guys ever resolve this and find a good Bencode Editor?

LC - You described really well, the scenario I have to face as well.

[linj]

For me, I just went into C:\users\***\appdata\roaming\utorrent and pulled out the old resume.dat, opened it up with notepad, and replaced all the wrong drive letters with the right ones. (Actually, notepad++ for what I did, but I believe notepad'll work fine.)

I've got it seeding as normal on my new Vista installation.

Godspeed.

[CodeRed]

I assume you didn't simply edit a resume.dat from 1.7? It will detect this as corruption. If you need to do this there is a special entry called ".guard". If you edit the file in a text editor you need to remove this as well or 1.7 will think the file is corrupted and move it to resume.dat.bad, then reload the .old backup and resave it.

[krist0v]

I've developed a JAVA class to export resume.dat as an XML file for content editing (mainly text fields, like paths, comments etc) and to recreate .DAT file from the modified XML ... It works pretty fine, though I need to figure out how to recreate the .fileguard HASH value according to the changed content !

I've tried it on my own resume.dat file, and apart from uT detecting "corrupted" resume.dat (but recreating it correctly), it seems to be working

Chris

[CodeRed]

Remove any existing .fileguard from the dict. Serialize the dict as a bencoded string. Take the sha1 of the string. Add a .fileguard entry with the sha1 hash as a 40-char string. Reencode and write the resulting string to a file. You can of course optimize this in many ways, if you care, so you don't have to bencode more than once or make more than one trip to the memory allocator.

[krist0v]

Thanks for explaining, I'll try to implement it in my class ...