Jump to content

Discogs Music Fetcher


Recommended Posts

Posted
2 minutes ago, Bigmack3000 said:

example:

621761224_ScreenShot2022-11-21at6_46_53PM.png.37654ce1dfb4bb3d1468365ac9449d99.png

What artist image fetchers do you have enabled?

Bigmack3000
Posted

A few, with discogs up top.

1023758279_ScreenShot2022-11-21at6_52_38PM.png.422e04e542b5e7fb476f1adab607eb8d.png

Posted
3 minutes ago, Bigmack3000 said:

A few, with discogs up top.

1023758279_ScreenShot2022-11-21at6_52_38PM.png.422e04e542b5e7fb476f1adab607eb8d.png

Was that on before, or after the scan? (notice the help text at the top of the dialog). When you install it will not be checked by default.

Bigmack3000
Posted

It was on before I ran the scan.  

Posted
Just now, Bigmack3000 said:

It was on before I ran the scan.  

Ok well I can see lots of too many request errors in your log coming from discogs, so that could be the reason. I haven't had a chance to circle back to this yet but we're going to have to look at how to manage that.

Bigmack3000
Posted

Ah ok.  Could that be a problem for large libraries?  If I ran it again, do you think it would add images since it's already linked?  Or still have too many requests?

Bigmack3000
Posted

Separately, it's having trouble bringing over text that is hyperlinked:

Discogs:

884330310_ScreenShot2022-11-21at10_54_29PM.png.bbb858f8d8b8ae30b1582b4218acc949.png

 

Emby:

903785963_ScreenShot2022-11-21at10_54_21PM.png.43fe7912c3f2c1232f9ccb18b9171bd1.png

Posted
Just now, Bigmack3000 said:

Separately, it's having trouble bringing over text that is hyperlinked:

Discogs:

884330310_ScreenShot2022-11-21at10_54_29PM.png.bbb858f8d8b8ae30b1582b4218acc949.png

 

Emby:

903785963_ScreenShot2022-11-21at10_54_21PM.png.43fe7912c3f2c1232f9ccb18b9171bd1.png

Right well that's just going to have to be stripped out.

  • Like 1
  • 1 year later...
Posted (edited)
On 21/11/2022 at 17:00, Luke said:

Ok well I can see lots of too many request errors in your log coming from discogs, so that could be the reason. I haven't had a chance to circle back to this yet but we're going to have to look at how to manage that.

This is still a major issue.

According to the discogs API docs, it is limited to 60 requests per minute.

My logs are filled with hours upon hours of discogs errors and Musicbrainz errors. So many that it affects the ability to do any other scans. Can we get a timeout when processes begin to endlessly error out and a good API call timing.

I know there have been requests to revamp the order in which music files are scanned for info; preferably so that the embedded info is first before going to the online meta.

The online info being stripped out of Discogs is a bit too aggressive now. Previously there were the  html/markup tags remaining, now the actual info is being removed if it is a a hyperlink. Still creating a situation where the meta that is imported requires manual editing. Except that instead of just having a few errant markup tags, now there are entire words and parts missing.

Compare attached pic with the description here

Screenshot 2024-03-22 131508.jpg

Edited by jiggity
added image
  • Like 1
  • Agree 1
Posted

More info about how this is not working properly

Spent a while this afternoon retagging some stuff, and Emby goes and adds the wrong discogs tags to albums that have discogs release id tags
Somehow the right info didn't even get imported 😕


 

Screenshot 2024-03-25 161831.jpg

Happy2Play
Posted
15 minutes ago, jiggity said:

More info about how this is not working properly

Spent a while this afternoon retagging some stuff, and Emby goes and adds the wrong discogs tags to albums that have discogs release id tags
Somehow the right info didn't even get imported 😕


 

Screenshot 2024-03-25 161831.jpg

Dev will have to comment but I don't believe the embedded DiscogReleaseID tag is being read and ends up getting from musicbrainz.

MusicBrainz api result

musicbrainz.emby.tv/ws/2/release/9d087a31-4788-41e4-8f0e-0f5c83994faf?inc=url-rels

<metadata xmlns="http://musicbrainz.org/ns/mmd-2.0#">
<release id="9d087a31-4788-41e4-8f0e-0f5c83994faf">
<title>The Aeroplane Flies High</title>
<status id="4e304316-386d-3409-af2e-78857eec5cfe">Official</status>
<quality>normal</quality>
<packaging id="815b7785-8284-3926-8f04-e48bc6c4d102">Other</packaging>
<text-representation>
<language>eng</language>
<script>Latn</script>
</text-representation>
<date>1996-11-26</date>
<country>US</country>
<release-event-list count="1">
<release-event>
<date>1996-11-26</date>
<area id="489ce91b-6658-3307-9877-795b68554c98">
<name>United States</name>
<sort-name>United States</sort-name>
<iso-3166-1-code-list>
<iso-3166-1-code>US</iso-3166-1-code>
</iso-3166-1-code-list>
</area>
</release-event>
</release-event-list>
<barcode>724383858323</barcode>
<asin>B000000W3G</asin>
<cover-art-archive>
<artwork>true</artwork>
<count>10</count>
<front>true</front>
<back>false</back>
</cover-art-archive>
<relation-list target-type="url">
<relation type="amazon asin" type-id="4f2e710d-166c-480c-a293-2e2c8d658d87">
<target id="f4402a2f-2796-4a45-a863-fdc61ce9bc02">https://www.amazon.com/gp/product/B000000W3G</target>
<direction>forward</direction>
</relation>
<relation type="discogs" type-id="4a78823c-1c53-4176-a5f3-58026c76f2bc">
<target id="a2b8819f-78f7-4b6d-b059-023ae019de6a">https://www.discogs.com/release/2038075</target>
<direction>forward</direction>
</relation>
<relation type="discogs" type-id="4a78823c-1c53-4176-a5f3-58026c76f2bc">
<target id="689dc432-1c98-4a19-8171-ba98203fceae">https://www.discogs.com/release/2515432</target>
<direction>forward</direction>
<ended>true</ended>
</relation>
</relation-list>
</release>
</metadata>

As you can see that is where your mis-match comes from tagged vs provider adding.

So the question becomes why is MBZ superseding tagged DiscogReleaseID?

Happy2Play
Posted

Not sure how much of an issue mixing and matching release information per provider is though.  As they are just links to their perspective site and are not used to query against each other that I know of.

Posted
20 hours ago, Happy2Play said:

Not sure how much of an issue mixing and matching release information per provider is though.  As they are just links to their perspective site and are not used to query against each other that I know of.

It is a big issue as in this case the imported MBZ discogs ID is for a Drum and Bass 12" and the actual Discogs ID is for The Smashing Pumpkins limited edition box set Pisces Iscariot

Happy2Play
Posted

True and you can find just as many complaints for wrong info in MBZ and Discogs as they are both user input making neither completely correct.

Do agree Tagged info should supersede provider info. 

But to me currently the DISCOGS_RELEASE_ID is not read from media.

Unless something has changed but In my test, it appears to be ignored.

Posted
On 3/26/2024 at 4:38 PM, Happy2Play said:

True and you can find just as many complaints for wrong info in MBZ and Discogs as they are both user input making neither completely correct.

Do agree Tagged info should supersede provider info. 

But to me currently the DISCOGS_RELEASE_ID is not read from media.

Unless something has changed but In my test, it appears to be ignored.

We can look at importing that.

  • Like 1
  • Agree 1
  • 1 year later...
Posted

Hello, 

Just posting here to mention I am also getting a lot of rate limiting from Discogs.

My Emby logs are full of these 429 errors after importing songs and scanning library files.

Could possibly improve the issue by implementing authentication. That would allow up to 60 requests per minute, compared to 25 a minute for unauthenticated requests.

 

2026-02-19 20:19:13.541 Info HttpClient: Http response 429 from https://api.discogs.com/database/search?q=Peter Skrabak&type=artist after 123ms
2026-02-19 20:19:13.541 Error App: Error in Discogs
    *** Error Report ***
    Version: 4.9.3.0
    Command line: C:\Users\RUM\AppData\Roaming\Emby-Server\system\EmbyServer.dll -service
    Operating system: Microsoft Windows 10.0.26200
    OS/Process: x64/x64
    Framework: .NET 8.0.22
    Runtime: C:/Users/RUM/AppData/Roaming/Emby-Server/system/System.Private.CoreLib.dll
    Processor count: 12
    Data path: C:\Users\RUM\AppData\Roaming\Emby-Server\programdata
    Application path: C:\Users\RUM\AppData\Roaming\Emby-Server\system
    MediaBrowser.Model.Net.HttpException: MediaBrowser.Model.Net.HttpException: TooManyRequests
       at Emby.Server.Implementations.HttpClientManager.CoreHttpClientManager.SendAsyncInternal(HttpRequestOptions options, String httpMethod)
       at Emby.Server.Implementations.HttpClientManager.CoreHttpClientManager.SendAsync(HttpRequestOptions options, String httpMethod)
       at Discogs.Plugin.GetResponse(HttpRequestOptions request, String method)
       at Discogs.Plugin.GetDeserializedResponse[T](HttpRequestOptions request, String method)
       at Discogs.DiscogsArtistProvider.GetSearchResults(ArtistInfo searchInfo, CancellationToken cancellationToken)
       at Discogs.DiscogsArtistProvider.GetMetadataResponse(ArtistInfo id, CancellationToken cancellationToken)
       at Discogs.DiscogsArtistProvider.GetMetadata(ArtistInfo id, CancellationToken cancellationToken)
       at Emby.Providers.Manager.MetadataService`2.ExecuteRemoteProviders(MetadataResult`1 temp, LibraryOptions libraryOptions, String logName, TIdType id, IRemoteMetadataProvider`2[] providers, MetadataRefreshOptions options, CancellationToken cancellationToken)
    Source: Emby.Server.Implementations
    TargetSite: Void MoveNext()

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...