Quoting JJZolx <[EMAIL PROTECTED]>:

I said it "seems" trivial.  And it still does, as you've offered no
reason why it's not.

I don't see how I'm obliged to do so. I see no point in wasting both our times spelling out every line of code affected, when neither of us have any plan to do anything about it after that.


Now, if you tell me that the architecture of
SlimServer makes this much more difficult than it should be, I'd
believe you.

Replaygain looks like it is fed at start of playback (I believe this is alre. There is the affect of album/track mode detection between tracks, then the firmware interraction at rate changes. Plain and simple: you mess with this and you'd better be sure you haven't f*d up anything else or people will scream. Frankly, I would exect that you could have already figured that out for yourself.

Nothing to indicate that it's some sort of impossible task.

and you are the only one so far to mention the word 'impossible'.

There are many bugs like this in the database that get little
attention.

sure, well, until there is one delevoper per bug there will always be bugs that have to wait. A greater number have been given attention and fixed, all in their time. I think you'd find that there is a lot more attention given than is immediately visible just by spectating on the bug list. I see no point in adding a comment myself that just says "looked at this for an hour, don't see an answer yet". Bugzilla is hardly a means for developer accountablility, though I can certainly see how it could be interpreted that way. Just about every bug is examined first off, to gather details, see if it IS a large or small problem, then it is placed in the queue. I would be hesitant to call that a poor response.

-k

_______________________________________________
beta mailing list
[email protected]
http://lists.slimdevices.com/lists/listinfo/beta

Reply via email to