[potshot]

Can someone tell me how to recover a corrupted part file with MorphTX. I tried using SF-IOM mod with the instructions here http://forum.emule-p...ver%20part&st=0 but all the SF-IOM mods are out of date and it won't work. Someone suggested using MorphTX to recover the files and I followed the instructions the same way but it doesn't work. After I add the link for the corrupted .part file and close MorphTX, then change the corrupted .part number to the new number and reopen MorphTX the file has disappeared from the list.

Can MorphTX be used to recover corrupted .part files from the original emule version?

[Andu]

First of all it's MorphXT not MorphTX.

But now to your description.

1) Add the file you downloaded to the download list (Either by using an ed2k link or through the search)

2) Right click on the newly added file and chose 'Import parts to file...'.

3) Find the corrupted file in the opening dialog and press open.

I think that should be it. Maybe there is a warning after that that you have to confirm. Btw you have to be certain that the file you add is the same as the one you downloaded before. Otherwise the hashes won't match and you won't be able to keep any of the content of the corrupted file.

This post has been edited by Andu: 23 June 2006 - 07:59 AM

[potshot]

Oops sry about the name. Yes I tried this also. I did exactly as you said. The file starts importing but then the program crashes with the message "a problem has occurred...blah blah blah" I'm positive it's the right link. Do I need the .part.met and .part.met.bak file from the corrupted .part file for it to work?

[Andu]

I don't think you need the .part.met files since it should work with any file no matter what format it's in. You might want to try the latest MorphXT 8.13 Beta 7. I think something around the import feature was fixed in there but I don't remember entirely.

[potshot]

Where is the beta version? I've looked in the download section of the website but I can't find it

[white lightning]

http://prdownloads.s...rc.zip?download

[potshot]

Thx I'll give it a try

Update: It worked pretty well. It didn't import the entire file but more than half which is good enough. The whole file was 774 MB and I had d/l about 660 MB and the importing stopped at 450 MB so good enough I guess. It just kind of froze up when it got to 450.

Oh ya the link you gave was for the source file, not the bin but I was able to find it. Thanks.

This post has been edited by potshot: 24 June 2006 - 02:38 AM

[Zebiwe]

Hi...I'm very curious to test new MorphXT..when the 8.13 beta9 will be release as stable? (I found that 3d closed..)

PS I'm sorry for my poor english..

[Syst3m Crash3r 480]

Zebiwe, on Jul 15 2006, 10:36 AM, said:

Hi...I'm very curious to test new MorphXT..when the 8.13 beta9 will be release as stable? (I found that 3d closed..)

You're not the only one...

[Andu]

I have an interesting question. If I have a file and all remaining chunks are currently being downloaded and the speeds with which the chunks are downloaded are different then why is the 'Remaining' time lower than the time estimated to finish the last chunk? Shouldn't the 'Remaining' time of the file equal that of the chunk that will be last completed?

If it's a problem of the official client I'm willing to repost this in support or bug reports forum.

This post has been edited by Andu: 16 July 2006 - 12:20 AM

[poutnik]

AFAIK remaining time with active downloads is calculated from current DL speed ( not very clever I think ), what is related to avg chunk speed. This speed is obviously higher then lowest one.
This is IMHO more suboptimal feature than a bug.

IMHO it could be good estimation to evaluate "DL time * ( ( Size - Dlded size ) / DLded size )" as for waiting files and use extrapolation of time dependency of such expression.

[Devil Doll]

Andu, on Jul 16 2006, 01:18 AM, said:

I have an interesting question. If I have a file and all remaining chunks are currently being downloaded and the speeds with which the chunks are downloaded are different then why is the 'Remaining' time lower than the time estimated to finish the last chunk? Shouldn't the 'Remaining' time of the file equal that of the chunk that will be last completed?

A chunk isn't an "atom" in respect to being downloaded (or else WebCache wouldn't be possible). After completing their chunks some of your faster sources may well help sending parts of the chunk that is currently being sent by your slowest source, e. g. if your two fastest sources happen to send parts of the same chunk they'll both complete that task and continue uploading parts of other chunks as they haven't uploaded 9.28 MB to you yet. (MorphXT's display of relative chunk position for upload slots allows the observation of this effect very nicely.)
Only when a number of atomar units so small that this "change of upload chunk within a slot" is no longer feasible would have to be downloaded as remaining part of this file (some small number of 180 kB chunklets IIRC) your reasoning would be valid IMHO.

[Andu]

Devil Doll, on Jul 16 2006, 05:10 PM, said:

Andu, on Jul 16 2006, 01:18 AM, said:

I have an interesting question. If I have a file and all remaining chunks are currently being downloaded and the speeds with which the chunks are downloaded are different then why is the 'Remaining' time lower than the time estimated to finish the last chunk? Shouldn't the 'Remaining' time of the file equal that of the chunk that will be last completed?

A chunk isn't an "atom" in respect to being downloaded (or else WebCache wouldn't be possible). After completing their chunks some of your faster sources may well help sending parts of the chunk that is currently being sent by your slowest source, e. g. if your two fastest sources happen to send parts of the same chunk they'll both complete that task and continue uploading parts of other chunks as they haven't uploaded 9.28 MB to you yet. (MorphXT's display of relative chunk position for upload slots allows the observation of this effect very nicely.)
Only when a number of atomar units so small that this "change of upload chunk within a slot" is no longer feasible would have to be downloaded as remaining part of this file (some small number of 180 kB chunklets IIRC) your reasoning would be valid IMHO.

You have a point there but it's only valid under special circumstances. If everything works according to plan which you have to expect when you start estimating the time of arrival then I'm right. You have to expect that every client will be sending you a chunk and then stop uploading. If these facts change and one of the client continues uploading another chunk after finishing one then you can update the calculation. But you cannot start out anticipating something to happen which is more than likely not to happen.

[Devil Doll]

Andu, on Jul 16 2006, 06:42 PM, said:

If everything works according to plan which you have to expect when you start estimating the time of arrival then I'm right.

When taking the slowest uploader as reference for your expected completion time you assume that every of your chunks started from scratch with the current uploader, i. e. the worst case, so that no uploader can switch chunks and add upload to your expected performance; eMule would know whether that's true and whether additional upload could be expected (although that's a non-trivial calculation). The most likely additional upload will be the one of the fastest source as this one is the one to finish its chunk first with the highest probability, almost definitely before the slowest source has completed its chunk.

You also assume that no current uploader will give you another slot until the slowest one has completed his chunk but that's of minor importance; you also assume that none of the other sources (in whose queues you're currently waiting) will give you another slot until the slowest source has completed his chunk, and that's the more unlikely the slower this slowest source transfers data.
Doing an 'exact' calculation seems impossible to me as that would require some simulation and queue theory; using the worst case scenario might be a worse guess than the current solution (depending mostly on the number of sources for that file: The more sources, the more potential support will the slowest uploader get for its chunk).

Even when no help from any other source steps in the trivial calculation still assumes that every one of the current uploaders will deliver a full chunk - how likely is that? (Depending on the number of chunks still incomplete.) Remember that a slot wouldn't last longer than 60 minutes - so slow transfers are likely to not even deliver a full chunk, right? Using the slowest uploader as reference for completion time might even turn out to be too optimistic in the end... then again, the slow uploader might give up and a faster uploader might take over for that chunk...

The longer the total transfer duration of that file (since the start of the download request), the more likely I would consider an average speed for future transfers to equal the average speed already observed. I'm not betting on some upload starting in ten seconds, I'm betting on the average being relevant after a significantly long time. That's what I would use as "expectation", and nothing else.

[Liz81]

Ok none of those apply to the emule software I got which is the eMule v0.47a. So which one of those am I supposed to download from that site?

[niclights]

What? Did you mean to post that here?

[Liz81]

niclights, on Jul 17 2006, 08:18 PM, said:

What?  Did you mean to post that here?

when somoene posted the link long time ago, i had three choices, meaning three programs I had to choose form to download but I don't know what program I need to download. I really need to save the corrupted files.