Official eMule-Board: Current Source Code - Official eMule-Board

Quote

What's the % of successful sessions ?
I wonder is eMule's transfer more or less susceptible to disturbances at these speeds than at lower speeds ? or all the same ?

Quote

AppleJuice, on 07 June 2007 - 08:21 PM, said:

is this still true and would then statistics graph need updated/ adapted ?
The FR : http://forum.emule-p...&st=0&p=891309&

hooligan3000, on 30 July 2014 - 12:48 PM, said:

Well your average upload rate which is arround 2MB/s at least indicates that there might be a lack of requests / fast enough downloads. Although I don't think you will see the same speed as you reported for torrents (120MB/s, which equals indeed 1Gbs and would be fairly impressive) - even with the new optimizations there are probably several other bottle necks in eMule which will not allow that. But I think being ready for 100Mbs is fair enough for now.

Also you might want to try a build with Overlapped Sockets enabled to see if it makes a difference, which would be very interesing. It will crash sooner or later due to a bug, but it might show wether there is actually a speed advantage.

give me a link and i will try it.

hooligan3000, on 31 July 2014 - 06:48 PM, said:

this one if I'm not wrong http://www.emule-pro...h_bin_test2.zip

Is 5.1.12 still the current build? Figured I'd just mention it's been quite stable for me the last couple of months...

There are no recent changes.

in search tab the ordering of "Known" tab NOT order correctly the results.
if try to click on known column for more time NOT fix the order
Same problem whit all versions previus the b12

When the search is finished, the first click on the column orders the known results at the bottom of the list, the second click at top.
If the search is not finished, that doesn't work.

It was clear that I was expecting the end of the search


xilolee, please check whit more "words" in Known tab.

Could you explain better?

This is a search with global server:

This post has been edited by xilolee: 10 September 2014 - 01:49 PM

I am a frequent user of emule. What can I do to help out future development?

Report bugs, write code. Maybe donate some money.

This post has been edited by Tuxman: 13 September 2014 - 02:04 PM

eMule NOT update the ed2k link when rename a file but ONLY when close the file datail window

step to reproduce:
1 Start the download of 1 file (with any name), for example a.mkv
2 go to File Detail Window on "eD2K Links" windows and see the link ( ed2k://|file|a.mkv.........)
3 then go to "name" tab and rename the file with any other word (for example b.mkv) then push "Apply" button.
4 then return to File Detail Window on "eD2K Links" and see the link whit "old" name.

sometimes eMule NOT set the Bitrate on video files, i think isn't the problem inside the code of eMule but is a bug in mediainfo.dll because not return a numeber whit 6 digit after "," (or . like XXX,######) then eMule get "" at this check

if (!bDiffVideoBitRate && ami.video.dwBitRate)

fail the control

			else
				buffer.Format(_T("%u %s"), (ami.video.dwBitRate + 500) / 1000, GetResString(IDS_KBITSSEC));

but skip to else branchet

else
			SetDlgItemText(IDC_VBITRATE, _T(""));

Because ami.video.dwBitRate is empty or bDiffVideoBitRate is false.

if mediainfo return a value whit only 5 digits work fine.
I write a mail to developer but i never get a response from him.

This post has been edited by Riso64Bit: 13 September 2014 - 08:23 PM

Some more news/changes?

No. But there should be some progress again in the coming two months / holidays, hopefully getting it ready for beta till the end of the year.

Sounds fantastic, thank you for information.

A known id3lib bug.
The bug was even fixed in stable CVS code over 10 years ago(!), but it never got into a proper release.

line 468 in mp3_parse.cpp (id3lib) defines
const size_t VBR_HEADER_MAX_SIZE = 116; // frames, bytes, toc and scale are optional

While line 497 declares vbr_header_size, which can be even 120 if vbr_flags equals 0xf.
It would be sufficient to increase the value in line 468 at least to 120. Or upgrade to that "stable" code (I am going to try that also).

EDIT 1 It's another question if that change would not spoil things in internal structures or in .met files.
EDIT 2 0.50b still cannot load tags properly - both with and without the size constant fix, though differently.
Then I checked 0.50a and the latest devbuild 0.50b by deleting know*.met files and starting eMule.
0.50a loaded and hashed the file. 0.50b failed (known2_64.met was created, known.met wasn't).
The issue requires more efforts.

However, this trivial bug raises a number of questions.

First of all, eMule crashes without any dumps or useful log records; just an unhandled exception.
Hardly there is a way to guess the reason without debugger.
That again reminds me about exception handling, so that relatively minor issues would not crash eMule without warning. Or at least would give a clue to the cause of failure.

Second. The mp3 file was downloaded years ago, and it never caused any issues. I verified ED2K hash - the file did not change. Therefore, I guess, it was never rehashed afterwards until recently.
Does it mean that a downloaded mp3 file was not scanned for tags when it was completed?

Third. The reason for rehashing was a side-effect of time zone M$ patch. Since the system time information changed, a few GB of files suddenly got "changed". Does eMule compare local times instead of internal UTC timestamps?

This post has been edited by fox88: 15 November 2014 - 09:57 PM

Quote

I don't remember that anything changed in the tag extraction code, but I'll put checking it on my todo list.

Two warnings from cppcheck 1.67;

srchybrid\MediaInfo.h, line 146
Member variable 'SMediaInfo::bOutputFileName' is not assigned a value in 'SMediaInfo::operator='.

srchybrid\Log.cpp, line 410
va_list 'argp' was opened but not closed by va_end().