You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In this case we can check if the number of tracks given for this release is the same as the number of tracks on the disc.
The real screw-up happens, when we have a true multi-disc release where the number of discIDs is greater than the number of actual discs.
We don't do anything wrong with first-disc/last-disc guessing, but the user can do something wrong when he gives the offset. Additionally there might be cases where we could guess, but don't do that, because it is the second discID of the first real disc, i.e.
When the number of tracks reported on the disc and the number of tracks
given on the release match, we do not need to check the list of discIds.
This just means we have multiple discIds for a single disc.
There is only a problem when there is another "real" disc, but then the
track counts would not match.
79494b6 uses release events to distinguish releases.
We could do something similar: When the release events are different, then the corresponding discIds belong to different releases (in NGS) and are not both part of the same multi-disc-release.
On the other hand we can only get this release event information when we issue one release search per discId in the curren release. Doubling or tripling the impact on the server (and might get throttled).
It would be easier if we
a) fetch some direct XML from the webservice (possibly also from ws 2)