Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Chadda]

I have a dual-boot set with windows and linux, and thus I share the same temp directories with amule and emule. When switching from one to another, I find amule or emule re-hashing all of my files again (emule even stats they could be 'possibly corrupted'. Anyways I think its the default rehash files at application launch or server connect. The problem is, I use amuled, and thus I launch it when I boot my system, and the hashing threads starts when my system is still loading, resulting in a overall slow system boot. I did a workaround for starting amuled only after my system has loaded completely, but what I was going to suggest is an option, like Azureus bittorrent client has, for a not 'cpu hungry' way of hashing files. It sure takes longer, but doesn't get in our way, and fits well for a background daemon.

[Vollstrecker]

I think the rehashing occurs, because you don't have the same config dirs. IIRC there is a file, that cataloges all your downloads, and when something changed, it starts the rehash for that file. If you use emule, and don't have the same config dir, it has to rehash all files the have been chamged.

[Chadda]

Thats what I thought. But I didn't know that is possible to share the same configs with emule and amule. Are they _really_ compatible? I don't want to mess with my working emule app  :rolleyes:
Anyways, how can I achieve that? I guess if its just only one file, symlinks will just do the job...

But I still find a nice idea to have a not cpu intensive _option_ for hashing files, not only on startup, but also everytime it has to. If I'm not wrong, I think it does when the download completes as well (at least I feel moments were my system gets slower and amule is eating 100% cpu for a little while when completing a download)

Well but this is just a suggestion!

[Vollstrecker]

Make a copy, symlink it to you home dir and test it.

[thedude0001]

About the CPU usage: That's exactly what "nice" was invented for. Just start your amuled with 'nice -n 15 amuled' and it shouldn't be too hard on your CPU / take only the CPU time that wasn't used by other processes. 'man nice' for more information.

[Chadda]

Thats true dude, thanks

And Vollstrecker, the relevant config files you said, were them suposed to be known.met and known2.met?
I symlinked them and started amule, which leaded to a crash  

cesar@Debian:~/.aMule$ amule
Initialising aMule
Checking if there is an instance already running...
Loading temp files from /mnt/data/Incoming/Temp.
Loading PartFile 40 of 40
All PartFiles Loaded.
ListenSocket: Ok.

*** TCP socket (ECServer) listening on 0.0.0.0:4712
*** Server UDP socket (TCP+3) at 0.0.0.0:7665
*** TCP socket (TCP) listening on 0.0.0.0:7662
*** Client UDP socket (extended eMule) at 0.0.0.0:7672
Adding file /mnt/data/Incoming/Temp/035.part.met to shares
Adding file /mnt/data/Incoming/Temp/034.part.met to shares
Adding file /mnt/data/Incoming/Temp/015.part.met to shares
Adding file /mnt/data/Incoming/Temp/084.part.met to shares
Adding file /mnt/data/Incoming/Temp/086.part.met to shares
Adding file /mnt/data/Incoming/Temp/088.part.met to shares
Adding file /mnt/data/Incoming/Temp/089.part.met to shares
aMule terminated after throwing an instance of 'CInvalidStateEx'
        Version: aMule CVS using wxGTK2 v2.6.1 (Unicoded) (Snapshot: Fri Jul 29 07:02:04 CEST 2005)
        what(): CRunTimeException::CInvalidStateException: Value passed to already completed string.
Aborted

Restoring everything fixed it. So, at least, it didn't worked for me, but renice'ing it might really do the job..

[Kry]

Wait, wait, wait. That's completely wrong. Please Vollstrecker ask someone that knows how the app works before giving this kind of advise.

Rehashing happens because eMule/aMule run in different O.S. and they behave differently. The modification date of the .part.met file is stored on the .met of the part file, and rechecked on reload. For some reason, the modification time is changed on OS change. Why? I dunno. Might take a look other day

[Vollstrecker]

My fault. I knew it was something like this :]

[Xaignar]

Check that the clocks in both OSs are synchronized, since it would certainly cause rehashing it they weren't.

[thedude0001]

Originally posted by Xaignar
Check that the clocks in both OSs are synchronized, since it would certainly cause rehashing it they weren't.

Hmm, I'm not quite sure if I am wrapping my mind around this in the right direction, but: Linux usually sets the system clock to UTC while Windows sets it to local time. Could this have any influence?

[Xaignar]

I don't know, that depends on whenever or not system clock is used to timestamp the files.