SmotheredHope wrote:

Nik/Teo or anyone else that might know - are removed release numbers re-used for new submissions? There's a lot of confusion in the pending removal requests when it comes to duplicates, because the release number says one thing and the history another thing. An example up right now is:

http://www.discogs.com/history?release=818528#latest

http://www.discogs.com/history?release=1123309#latest

Same release is up for removal twice, everyone disagrees as to which is the duplicate.

Please clarify if the numbers are re-used or if the history is incorrect, or what the cause of this might be.

And while we're at it, please address the issue of wheter or not first come stays is to be applied when it comes to duplicates, and also why messages are sometimes posted 2-3 times at the same time in the history (see links).

Thanks

[edit] - another example here: http://www.discogs.com/history?release=927852#latest

housefly88 wrote:

I agree with SmotheredHope, If the submission already exists in the database, then make the changes to the one already submitted. Do not think because your submission is "better" or has more information you can ask for a removal.. append the pre existing submission... hell there is even an idiot warning box when you submit telling you the your sub is a duplicate.

JTWolfe wrote:

100% Right on. Better eligible, and "the release number proves..." is just not a viable argument based on released information (yet is used so frequently in arguments). An exacting method to determine what was submitted first needs to be explained/defined.

nik wrote:

AFAIAA, the release numbers are not reused - the latest release number is around 1400000, the number of releases on the site is around 1130000, so there is a discrepancy of about 270000 releases where the release number is used, but it is not in the database.

However, it is not strictly sequential at all, as the release gets a number as soon as it is drafted, not when it is submitted.

If the sub is already in the database, it must be updated. Apart from anything else, the earlier database entry is more likely to have users who have it in their collection.

SmotheredHope wrote:

Thanks for the reply and input Nik.




Meaning you're not 100% certain? Is it more of a question for Teo? I'd like a conclusive answer to this one so there is no doubt.




True. As for the examples above I couldn't imagine it was because one was from draft since it's roughly a 300,000 id difference between them which must mean it's been in draft for a year or something - if the numbers are not re-used that is.




Yes, this is also my opinion, but some pull "the better one stays" card and votes the other way. Is this outlined or taken up somewhere in regards to relese removal requests (guidelines?) If so, please point me to it so a link can be included when these situations occur, because as you see people seem to think that "the better one stays" is applicible which doesn't make sense - JTWolfe hit the spot on why in the comments in these examples, plus there's the collection/wantlist factor as well as you mention.


Response to this still needed also:




Is the history 100% successfully retrieved now post v3? It certainly doesn't seem so in many cases.




This above is very annoying - needs to be sorted out.

Thanks

julesparis wrote:

what's really annoying is having to use the very flawed removal feature to deal with duplicates when there used to be a merge feature that was working pretty damn well until it was wiped out 5 months ago without any valid reason given by the people in charge of this site and its programming.

TomKay wrote:

What's the deal with http://www.discogs.com/history?release=1081884#latest then? Mine was submitted most recently AND has more information. As far as I can see, all that needs to be done is adding an ANV for Tina Karol...

SmotheredHope wrote:

Yes, of course, just trying to sort the mess out to the best possible extent as it is now... I agree completely.

SmotheredHope wrote:

No logic behind that, I have no-voted plus put the other one up for removal.

[edit] - since he didn't put a dash in the cat# he didn't get a warning of a possible duplicate...

TomKay wrote:

Thanks. I realise I was missing the ANV but i'm not that great with Cyrillic...

SmotheredHope wrote:

*bump*

Nik/Teo - If you could answer my questions that would be great.

auto-converted long url

nik wrote:

The release numbers are never reused.




Well, I think this should be part of the merge release guidelines, it wasn't meant to be part of the remove release guidelines, and removing releases wasn't supposed to be the de-facto method. In any case, for the moment, keep the oldest release.




The history is recovered apart from less than 20000 releases which we have a note of, and will try to reinstate. If you have a specific release in mind where you are sure the history is not complete, please let me know and I'll check it for you.

SmotheredHope wrote:

Thanks for clarifying, so those come from draft then (if the number is lower but submitted later than another one).




Well, since there is no merge function, I don't see anything wrong with clarifying this somewhere in connection to removals or in guidelines. It would save some time not having to argue about wheter or not the oldest stays or not.




I see such examples all the time, I must be digging through those 1% then? Hmm. :) But ok, I'll let you know of those I come across then...