# Discogs id starting with \[m are failing

**URL:** https://community.mp3tag.de/t/discogs-id-starting-with-m-are-failing/49883
**Category:** No Bugs
**Created:** [August 11, 2020, 7:13am UTC](https://community.mp3tag.de/t/discogs-id-starting-with-m-are-failing/49883 "2020-08-11T07:13:06Z")
**Posts on this page:** 5
**Page:** 1

<div class="post-metadata">

### Author: ![WS64](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ws64/32/6075_2.png) [@WS64](https://community.mp3tag.de/u/WS64)
#### Post date: [August 11, 2020, 7:13am UTC](https://community.mp3tag.de/t/discogs-id-starting-with-m-are-failing/49883/1 "2020-08-11T07:13:06Z")

</div>

Hi, I am not 100% sure if it really is as I describe it here, but anyway.  
I noticed that whenever I try to name my files by an discogs release id starting with [m (e.h. [m54682]) I get an error rmessage:  
"Error connecting to server: [www.discogs.com](http://www.discogs.com)  
404: Not found"  
At first I thought there was really an issue with the connection at that time, but I can try to do another search directy after that and to another id (e.g. [r1057669], same album but with a different entry), and it will work. Searching for [m54682] again will result in 404 again.  
So far I am sure my description is correct, but I think this goes for EVERY discogs entry starting with [m.  
Please check, thanks!

(Win 10 1909 home, MP3Tag v3.02)

---

<div class="post-metadata">

### Author: ![poster](https://community.mp3tag.de/user_avatar/community.mp3tag.de/poster/32/4881_2.png) [@poster](https://community.mp3tag.de/u/poster)
#### Post date: [August 11, 2020, 7:52am UTC](https://community.mp3tag.de/t/discogs-id-starting-with-m-are-failing/49883/2 "2020-08-11T07:52:06Z")

</div>

Discogs IDs starting with "m" are so called master releases, as far as I understand something like a combination of different releases.

---

<div class="post-metadata">

### Author: ![WS64](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ws64/32/6075_2.png) [@WS64](https://community.mp3tag.de/u/WS64)
#### Post date: [August 11, 2020, 7:55am UTC](https://community.mp3tag.de/t/discogs-id-starting-with-m-are-failing/49883/3 "2020-08-11T07:55:02Z")

</div>

Might be, but why shouldn't they be found by MP3Tag?

---

<div class="post-metadata">

### Author: ![Nevov](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/n/b487fb/32.png) [@Nevov](https://community.mp3tag.de/u/Nevov)
#### Post date: [August 23, 2020, 6:34pm UTC](https://community.mp3tag.de/t/discogs-id-starting-with-m-are-failing/49883/4 "2020-08-23T18:34:08Z")

</div>

It's because the master release [m...] page isn't formatted the same way as a release [r...] page that's why an [m...] number is invalid to use. It's really a basic "folder" page to contain all the different versions of that particular album/single/etc issued around the world over time.

It doesn't even have tracknumbers for example so the master release pages are basically useless for Mp3tag to use as a tag source compared to a release page.

The good news is every master release page does always link through onto several release [r...] pages, so it's just a matter of opening whichever release is right for your mp3s and using its [r...] number.

Maybe Mp3tag could be given some smarter error message to announce instead of a 404/error if a user tries to use [m...] number in that option, like: "please use a valid r number" or something so users don't think it's a connection issue.

---

<div class="post-metadata">

### Author: ![system](https://community.mp3tag.de/uploads/default/original/2X/c/ce7035d426cb755a7916793326d23b465222a407.png) [@system](https://community.mp3tag.de/u/system)
#### Post date: [February 9, 2026, 12:19pm UTC](https://community.mp3tag.de/t/discogs-id-starting-with-m-are-failing/49883/5 "2026-02-09T12:19:08Z")

</div>


