DC++

dieselmachine wrote:I coded this.

What is "this", exactly?

Not to mention defeating part of the purpose of the feature, by making it so you need a slot *before* you can decide whether to queue up a file - since you'll need one to do these partial downloads to get the metadata?

Well, I'll tell you that it's got a high fun factor for me... I may support only MP3 bitrates when (if?) I first implement it, but I'll still wrap it in whatever appears to be the best or most thought-out metadata system... Which is to say, I'll probably put it in XML and introduce a client option ...

It's an impossible line to walk, isn't it, for those of us who code on DC++? I will not code a half-assed feature, and if I code it, only my client will have that feature; arnetheduck will not put an ugly hack into DC++. Please get the "it's not a big change, just do a quick hack now" idea out of y...

Disadvantage of metadata thingy: Probability of feature being designed to cope with all things approaches one. If something is designed to cope with all things the time needed to code/design said thing approaches infinity. Thus, what is needed is (in my own, very humble opinion) : 1. A way to get a...

sorry, but this is obviously nonsense. No, it's not. :P using only hubs with the high-bitrate-only requirement means having access only to whatever is on those hubs. using those hubs *and* other hubs means having access to what's on both, necessarily more. It's non-sense when you look at this from ...

Well, do as you please. I just tried to help you with the crappy mp3 problem. But don't judge what you haven't seen. maybe a few people will be satisfied with the reduced range of stuff that mai9's strategy gives them access to, but far from everyone will. the take-home message is, it *will* reduce...

this thread is a good argument for allowing post-editing

sorry to keep this duplicate thread going, but i think this point needs to be emphasized. one of the best features of directconnect is specialized hubs. however, hubs that specialize both on the content (eg style of music) and the form (eg bitrate and encoding) of files will likely end up with a ver...

maybe it's a good idea to make an 'info' column for each file, and put there info about the file depending what file type it is. ... i don't know about other file formats but there are plenty of usefull things you can put there, similar to kazaa Maybe it would be nice, but personally I'm not too in...

sam, the idea isn't that the issue shouldn't be discussed; the idea is to revive old threads rather than to start new ones so the same points don't have to be repeated over again. when you post to an old thread it goes to the top of the list, so people will have a reason to look at it, and especiall...

The hypothetical issue of people on super-fast connections not being able to share as much because they can't download as much, and consequently somehow making things worse for everybody, I find relatively ridiculous. Sure, it might be a problem for you if you can't DL as much on your super-fast co...

I have seen another soulseek suggest this, and it does have merit. Can you describe in depth how it needs to work (not technically)? Basically, the idea is to create a list of searches, with standard search parameters, that will be carried out at some regular interval on all the hubs a user is conn...

Okay, so this topic got to be about some other stuff, but just a quick note about mai9's comments on my comments. The simple truth is that the vast majority of DC++ users - say, 97%, but it's probably higher than that - will have already picked up files from other p2p services, or from DC++ hubs wit...

What about joining a high quality mp3 hub? It couldn't be easier Ohhhhhh yes it could. 1) Barring users with a mix of bitrates will exclude the vast majority of users. Along with them will go most of the music out there. 2) If you want to run a specialized hub, you're already limiting the potential...