[Some Support]

Let's hope for no later than the end of the year.

[Enig123]

Just need to make sure, should we hold our breath for the new stable version before the end of the year?

[Some Support]

I'm pretty sure it will happen around the holiday time, the only question is how much will be changed compared to the Beta. Given that there are no serious bugs this version is basically fine as an update but of course not everything which has been reported and noted by other coders is in yet.

[guknos]

Some Support, on 28 November 2015 - 09:10 AM, said:

I'm pretty sure it will happen around the holiday time, the only question is how much will be changed compared to the Beta. Given that there are no serious bugs this version is basically fine as an update but of course not everything which has been reported and noted by other coders is in yet.

dear SomeSupport,
eMule 0.50a is very stable, but a 0.50b with updated UPnP libs for support more router would be great. A sort of "maintenance release".

This post has been edited by guknos: 28 November 2015 - 09:55 AM

[xilolee]

Hi! I sent a dump.

I forgot to write some basic info: now I'm using Win10 home/std x64, DEP enabled (alwaysOn), DPI 150% (custom scaling) - Res:1920x1080, eMuleConfig: C:\ProgramData\eMule\config, eMuleInstFolder: C:\Program Files (x86)\eMule.

[Some Support]

xilolee, on 15 December 2015 - 08:32 PM, said:

Hi! I sent a dump.

I forgot to write some basic info: now I'm using Win10 home/std x64, DEP enabled (alwaysOn), DPI 150% (custom scaling) - Res:1920x1080, eMuleConfig: C:\ProgramData\eMule\config, eMuleInstFolder: C:\Program Files (x86)\eMule.

Did you use overlapping sockets?

[xilolee]

Is it anything to eat?
Honestly I don't know.
I didn't enable or disable anything about sockets in emule preferences.ini, if this is possible, nor I had modified emule sources about that (I don't know how to do it for very simple code).

[babberiastar]

Grazie

[fox88]

Some Support, on 28 November 2015 - 12:10 PM, said:

I'm pretty sure it will happen around the holiday time

Happy New Year to everyone.

Can we hope to see that new version soon?
There is no indication of progress in repository; even repository itself was down for a short time due to sourceforge maintenance.

[guknos]

fox88, on 01 January 2016 - 08:46 AM, said:

Some Support, on 28 November 2015 - 12:10 PM, said:

I'm pretty sure it will happen around the holiday time

Happy New Year to everyone.

Can we hope to see that new version soon?
There is no indication of progress in repository; even repository itself was down for a short time due to sourceforge maintenance.

Happy New Year to You, Fox (and to everyone, of course)
let's hope for a 0.50b soon.

[eMuleVeteran]

I have been waiting for so long that eMule would support faster KAD, it would make sharing more files possible.

So what if emule would support multiple KAD instances, so that in one eMule executable running, there would be
multiple KAD addresses registered, everyone with different port number. And in eMule itself would direct results
and shared files so that it would everything seems like KAD would just be much faster.

Im using now multiple instances of emule, so that I can share enough files at the same time. But spreading
downloads with multiple running emules is almost impossible in practice. Having multiple KADs running in one
emule would be 100% compatible with other KAD clients.

I really hope emule would evolve to faster and more shareable version, because we really need P2P that is able
to share whatever individual files you might have in your hard drive, without publishing it like torrents and
without servers like Soulseek and we need it to be fast enough so that people would use it and not discard it
as outdated crap. I have script that runs 30 emules with my 100mb connection, so that I can share all the files
in my collection at the same time. Those 30 emules use little to none of RAM and CPU, and there are still room
for much more IP packets traveling in and out.

Im waiting for the day that I can change in my emule settings the port range from 60000 to 60500 and run 500
KADs in one eMule and make good use of my hardware and internet connection, that has been running emules 24/7
for the past 12 years.

If you support this idea, please let your voice to be heard.

[bERTUZ]

Waiting for the new version, yeah!!! Thank you very much

[RejZoR]

eMuleVeteran, on 04 February 2016 - 02:23 AM, said:

I have been waiting for so long that eMule would support faster KAD, it would make sharing more files possible.

So what if emule would support multiple KAD instances, so that in one eMule executable running, there would be
multiple KAD addresses registered, everyone with different port number. And in eMule itself would direct results
and shared files so that it would everything seems like KAD would just be much faster.

Im using now multiple instances of emule, so that I can share enough files at the same time. But spreading
downloads with multiple running emules is almost impossible in practice. Having multiple KADs running in one
emule would be 100% compatible with other KAD clients.

I really hope emule would evolve to faster and more shareable version, because we really need P2P that is able
to share whatever individual files you might have in your hard drive, without publishing it like torrents and
without servers like Soulseek and we need it to be fast enough so that people would use it and not discard it
as outdated crap. I have script that runs 30 emules with my 100mb connection, so that I can share all the files
in my collection at the same time. Those 30 emules use little to none of RAM and CPU, and there are still room
for much more IP packets traveling in and out.

Im waiting for the day that I can change in my emule settings the port range from 60000 to 60500 and run 500
KADs in one eMule and make good use of my hardware and internet connection, that has been running emules 24/7
for the past 12 years.

If you support this idea, please let your voice to be heard.

So, you're interconnecting your own KAD nodes if I understand it correctly, sort of creating a local swarm of clients that all share the same files. They all come from the same IP, but from different ports. That's actually pretty clever. It's not really benefiting you when it comes to downloads, but you can maximize the upload for sure in terms of exposure. Hm.

[xSTHNSx]

Now the biggest problem with KAD is just waste of time since it takes too damn long to propagate the files and by the time its published user maybe unavailable. As you know those of us who shares we all stick to ED2K as primary and KAD as secondary. Even with its biggest flaw with ED2K (2G-P2P) is also its greatest strength when it comes to sharing since faster indexing. Where in KAD to publish single file it has to first search for 10 others nodes to publish it on. As it can take 2mins to fully complete the process with limit of 3 files during that interval with 5hours duration until it propagated file expires from the node. Now this scheme is bad for sharing large amount of files since eventually all files does get published long as client is up and running just not at same times. Also under this type of setup rare files suffers where popular files excels due to multiple sources thus increasing its visible availability.

@RejZoR
What he is saying is due to our 3G-P2P mockup of DHT known as KAD unable to fully publish large amount of files to propagate in acceptable manner. He has taken upon himself to tweak it by deploying more than multiple instances in terms of sharing as he does not care about downloading. He just cares about his files being published thus others able to download it.

@eMuleVeteran
My hats off to you man. I personally wouldn't do that since its waste of resource overall. But i'm guessing you allocated the client on container thus not deploying on multiple users as its all unified under single virtualization, correct? As it maybe but the drag will still be on the network to due large overhead since endless callbacks of KAD. Thus your gateway will suffer regardless unless you built custom switch by hand. Which would be advisable to operate it on bridge setup and let another unit handle it and route all traffic. I built custom router few years back which operated on P4 3GHZ with 2GB DDR2-PC2700 with eth0 as incoming while eth1/2 on dual nic connected to 2 FServ's. In theory it could handle 7GBPS even with 168bit OSF native even when physical infrastructure didn't support it by the ISP.

[RejZoR]

Well, my primary concern is upload as well. And with that you indirectly also gain download resources through passive exchange. I've already asked tHeWiZaRdOfDoS about it for kMule, maybe he could test it on a larger scale within a single client with multiple KAD instances within it. Besides, his kMule is perfect for such test since it's KAD only client to begin with. If this really works, we'd push KAD quite a lot further without actually modifying anything about the protocol itself.

[tront]

Even if it's beta, why not announce on the homepage?

[Some Support]

tront, on 08 March 2016 - 04:11 PM, said:

Even if it's beta, why not announce on the homepage?

There is a link in the top right corner

[tront]

Oh. Right. I think the dark color made me not notice it.

[holysmoker]

Some Support, on 09 March 2016 - 08:43 AM, said:

tront, on 08 March 2016 - 04:11 PM, said:

Even if it's beta, why not announce on the homepage?

There is a link in the top right corner

It's almost one year and still beta1...

[beleaguered]

Is there even a changelog for this?