Looks like a new release 0.305
Moderator: Moderators
Looks like a new release 0.305
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
Big thanx for the new version.
/ SwedenXP
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
-
- Forum Moderator
- Posts: 587
- Joined: 2003-05-07 02:38
- Location: Sweden, Linkoping
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?
Wonder how many times I've seen a exceptioinfo.txt ´that lokks exactly like this reported here?
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
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).joakim_tosteberg wrote:I wonder how many times I've seen a exceptioninfo.txt that looks exactly like this reported here?
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...
-
- Forum Moderator
- Posts: 587
- Joined: 2003-05-07 02:38
- Location: Sweden, Linkoping
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
And I said it so that users who browse our forums don't get the idea that DC++ programmers are intentionally ignoring bugs/problems.joakim_tosteberg wrote:I didn't say that. I meant that many users have reported this, not that single users have got this several times.GargoyleMT wrote:I've not heard anything about someone being able to reliably reproduce this problem...
Re: Looks like a new release 0.305
Just a small reminder that bitrate does not show the quality of mp3 files.SwedenXP wrote:music quality (bitrate)
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.
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
Take a look at Shareaza, it handles meta-information in a very nice way.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
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).
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
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.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.
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...
Isn't that a Kazaa clone? I hate those clientsGargoyleMT wrote: Take a look at Shareaza, it handles meta-information in a very nice way.
If the search results, file lists, etc are in XML it won't be a big change.Anyhow, it really does require a protocol 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)
-
- Forum Moderator
- Posts: 1420
- Joined: 2003-04-22 14:37
Search results (for a file anyway as apposed to a directory) are in this format.
You can't just stick another field in there. It won't parse correctly afterwards... I think.
Code: Select all
$SR fromuser path\to\file.ext\0x5filesize freeslots/openslots\0x5hubname (hubaddress[:port])\0x5touser|
-
- Forum Moderator
- Posts: 1420
- Joined: 2003-04-22 14:37
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
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.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.
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.
I also hate the edonkey clients, i'm not a donkeyGargoyleMT 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.
But if the protocol is updated to use XML, there won't be any other changes necessary in the future..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.
Edit: Better so?
//joakim_tosteberg
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
Your loss, it has good ideas in it. (hence my suggestion)Wisp wrote:I also hate the edonkey clients, i'm not a donkey
Yes, changing the protocol to allow xml would be a protocol change.But if the protocol is updated to use XML, there won't be any other changes necessary in the future..
Yes, metadata will be allowed somehow in the next protocol.
No, the next protocol will not be XML.