Looks like a new release 0.305

SwedenXP · Post by **SwedenXP** » 2003-12-04 08:10

Like it - but what happend with the idea of creating collums for music quality (bitrate)? There is music out there - but the quality...

Big thanx for the new version.

/ SwedenXP

Post by **GargoyleMT** » 2003-12-04 14:06

Thanks, this is an oft-requested feature. It requires some protocol changes.

Please take a look before duplicating requests (though feel free to resurrect older threads to make your opinion known).

I'm moving this post, as it's really in the wrong place.

Wisp · Post by **Wisp** » 2003-12-05 19:26

I would really like this feature

But the hashing feature must go first

You could use encspot to guess the encoder and bitrate, it is also open source i believe

Wisp · Post by **Wisp** » 2003-12-05 19:28

Anyway, great version, all the bugs of the previous version seem gone, although I just had a unhandled exception

Unhandled Exception
Code: c0000005
Version: 0.305
Os: Win2003 Pro
Call stack info:
ntdll!0x77F5D61B : RtlpWaitForCriticalSection
ntdll!0x77F42044 : RtlEnterCriticalSection

joakim_tosteberg · Post by **joakim_tosteberg** » 2003-12-06 00:54

Check this http://dcplusplus.sourceforge.net/forum ... calsection.
Wonder how many times I've seen a exceptioinfo.txt Ã‚Â´that lokks exactly like this reported here?

Post by **GargoyleMT** » 2003-12-08 11:49

joakim_tosteberg wrote:I wonder how many times I've seen a exceptioninfo.txt that looks exactly like this reported here?

Cologic and sandos tried to reproduce this on demand a couple months back. Cologic could only get the crash by clobbering the memory inside (an instance of) the Critical Section (class).

Critical Sections are used all over the DC++ code, I've seen sporadic crash reports in a lot of them.

I've not heard anything about someone being able to reliably reproduce this problem...

joakim_tosteberg · Post by **joakim_tosteberg** » 2003-12-08 14:25

GargoyleMT wrote:I've not heard anything about someone being able to reliably reproduce this problem...

I didn't say that. I meant that many users have reported this, not that single users have got this several times.

Post by **GargoyleMT** » 2003-12-08 14:30

joakim_tosteberg wrote:
GargoyleMT wrote:I've not heard anything about someone being able to reliably reproduce this problem...
I didn't say that. I meant that many users have reported this, not that single users have got this several times.

And I said it so that users who browse our forums don't get the idea that DC++ programmers are intentionally ignoring bugs/problems.

mai9 · Post by **mai9** » 2003-12-10 09:01

SwedenXP wrote:music quality (bitrate)

Just a small reminder that bitrate does not show the quality of mp3 files.

Of course a 192kbps file sounds better than 112kbps whatever the encoder, but you already can guess that from the file size, isn't it?

off-topic, please join hi-quality mp3 hubs.

Wisp · Post by **Wisp** » 2003-12-10 11:25

I would like a column "Info" where things like bitrate or resolution could be displayed..

I made a screenshot of the way it should be

Twink · Post by **Twink** » 2003-12-10 17:40

hmm not a bad idea, and since hashes seem to be transfered somehow between bcdc clients I'm sure its possible to transfer info string, hmmm now if only we could find someone who could actually be bothered.

Post by **GargoyleMT** » 2003-12-11 12:12

Wisp wrote:I would like a column "Info" where things like bitrate or resolution could be displayed..
I made a screenshot of the way it should be

Take a look at Shareaza, it handles meta-information in a very nice way.

Anyhow, it really does require a protocol change... or spamming other clients with Extended Search Results (which have to be made in a nice extendable form to carry a lot of potentially different types of meta-info).

Post by **GargoyleMT** » 2003-12-11 12:16

Twink wrote:hmm not a bad idea, and since hashes seem to be transfered somehow between bcdc clients I'm sure its possible to transfer info string, hmmm now if only we could find someone who could actually be bothered.

Well, they use the Hub field to send TTH in the search field, so all clients see it. The full hash is transmitted in a C2C tcp session, if I've listened in well to the conversations about it.

JT's MP3 mod (search the archives) used another dc++ specific hack to transmit some of this in normal $SRs too.

The problem is you cannot modify $SR because you don't know if the remote machine has the ability to interpret it correctly, and if you send a new command, you're duplicating effort in the code, and also spamming users with information they cannot use...

Wisp · Post by **Wisp** » 2003-12-11 19:49

GargoyleMT wrote: Take a look at Shareaza, it handles meta-information in a very nice way.

Isn't that a Kazaa clone? I hate those clients

Anyhow, it really does require a protocol change...

If the search results, file lists, etc are in XML it won't be a big change.

The search results could be in a format like this

<result>
<hash>42A9F22F</hash>
<filename>justafile.mp3</filename>
<size>5322432</size>
<user>[NL]Wisp</user>
<path>c:\music</path>
<slots>3/4</slots>
<info>128 kbps lame</info>
<result>

similar for file lists etc

This way the client only extract the data they are able to interpretate, this way everything stays compatible.

(edit: fixed quote tag -gmt)

TheParanoidOne · Post by **TheParanoidOne** » 2003-12-11 19:59

Wisp wrote:
Anyhow, it really does require a protocol change...
If the search results, file lists, etc are in XML it won't be a big change.

But they aren't, so the original statement stands.

Xan1977 · Post by **Xan1977** » 2003-12-11 20:15

Search results (for a file anyway as apposed to a directory) are in this format.

Code: Select all

$SR fromuser path\to\file.ext\0x5filesize freeslots/openslots\0x5hubname (hubaddress[:port])\0x5touser|

You can't just stick another field in there. It won't parse correctly afterwards... I think.

TheParanoidOne · Post by **TheParanoidOne** » 2003-12-11 20:31

Indeed. I'm don't know the specific syntax, but that seems to be the gist of it.

It would be extremely useful (extendable!) if the messages *were* in XML, but sadly they are not.

Post by **GargoyleMT** » 2003-12-11 20:49

Wisp wrote:Isn't that a Kazaa clone? I hate those clients
If the search results, file lists, etc are in XML it won't be a big change.

No, Shareaza is a multi-network client, it covers Gnutella1/2, eDonkey2000, and BitTorrent. It shares the 'aza' with Kazaa - it is unfortunate in that it associates itself with the Fasttrack network in any way.

If results, file lists, etc. were in XML, it would not be an issue. But in order to make them into XML, it requires a change in protocol.

Wisp · Post by **Wisp** » 2003-12-12 09:36

GargoyleMT wrote: No, Shareaza is a multi-network client, it covers Gnutella1/2, eDonkey2000, and BitTorrent. It shares the 'aza' with Kazaa - it is unfortunate in that it associates itself with the Fasttrack network in any way.

I also hate the edonkey clients, i'm not a donkey

If results, file lists, etc. were in XML, it would not be an issue. But in order to make them into XML, it requires a change in protocol.

But if the protocol is updated to use XML, there won't be any other changes necessary in the future..

Edit: Better so?
//joakim_tosteberg

Post by **GargoyleMT** » 2003-12-17 11:29

Wisp wrote:I also hate the edonkey clients, i'm not a donkey

Your loss, it has good ideas in it. (hence my suggestion)

But if the protocol is updated to use XML, there won't be any other changes necessary in the future..

Yes, changing the protocol to allow xml would be a protocol change.
Yes, metadata will be allowed somehow in the next protocol.
No, the next protocol will not be XML.

Looks like a new release 0.305

Looks like a new release 0.305

Re: Looks like a new release 0.305