Art URL being set to null, artwork cannot be updated until null line is removed

[mynnshaw]

Details

What seems to happen is that when foo_discord_rich needs to write an artwork down and there is either no source, or the uploader fails to pass something to the component, foo_discord_rich returns null. I am on foo_discord_rich 2.0.2 and use foobar2000-catbox as my URL uploader.

This seems fine on it's own, however the issue is not that. foo_discord_rich writes this null to the artwork url file and even when artwork is added later, the art url will remain as null and effectively prevent the artwork url from being reset. This could cause issues later when the artwork source is added later, or the uploader's service is up, however a null is in the place of what should be a rescan(?).

I would expect foo_discord_rich to be able to look for artwork when it's added later, however instead foo_discord_rich permanently writes null to the file and it won't try to replace this null with a valid artwork later. Perhaps it could be fixed by being given the ability to overwrite nulled entries, perhaps on a delay and with a certain amount of allowed tries?

One way this can be triggered consistently is when the process for the uploader times out. Another way to trigger this mostly consistently is if an audio file has no artwork attached to it's metadata and there is no found artwork in the same folder as the audio file, foo_discord_rich will seemingly try to read the artwork of the file and will set it's art url as "null". Even when artwork is added later, the art url will remain as null and effectively prevent the artwork url from being reset. This applies to basically all supported formats.

The only current workaround for this issue is to open art_urls.v2.0.1.json (or art-urls.json in earlier versions) and replace the null with an artwork URL in quotes, or just remove the whole line so it can scan again. This workaround only works when foobar2000 is entirely closed, the process cannot be running.

I'm mainly making this issue as I use files with missing artwork as I plan to add them later, but I find it frustrating manually replacing the artwork URLs when it's written as completely null. I would expect the program to not track the artwork URL at all until an embedded artwork is found, and as far as I know, this wasn't an issue in s0hv's fork.

This issue is exclusive to the artwork uploader and is not an issue with the MusicBrainz fetcher. I have only tested foobar2000-catbox. This has also not been tested with the MusicBrainz fetcher, which seems to work 100% intended.

Reproducing this issue

1. Create a file with artist & album field filled with anything (Can be both "test".)
2. In the Artwork tab of properties, make sure Front Cover is blank (not present).
3. Let the song file play for foo_discord_rich to add the entry to art_urls.json
4. The artist & album field will have the artwork URL in art_urls.json set as "Null"

This is only replicated when cover.jpg is not present in the folder of the audio file AND there's no cover art embedded.

[TheQwertiest]

do you mean when using uploader or musicbrainz auto fetcher?

[mynnshaw]

This seems to only occur on the uploader.

[mynnshaw]

This is something that I need to test more, but extremely large embedded images (specifically 3400x3400) seem to also trigger this behavior.

[mynnshaw]

Quick update, I have updated to the newest version of foobar2000-catbox. Large artwork seems to now work after some light testing, however the nulling behavior still persists. So it seemed the larger artwork was something on the uploader's end and not foo_discord_rich's end, but this plugin will need to handle nulling artwork URLs differently since files with no artwork still are added to artwork urls as null.

For reference, on the updated test I chose to use the album tag Test! & Test as I believed special characters were also causing this behavior, but it ended up not being the case.

[TheQwertiest]

Yea, large artwork problem is definitely not a plugin problem - it just send data as is to the uploader.
I want to limit the artwork size though, because it makes no sense to use 4000x4000 image for Rich Presense

[mynnshaw]

4000x4000 is definitely excessive for the average user, however I have artwork that's completely unedited that goes up to that size, and I prefer to add that over than just downscaling it myself.

[TheQwertiest]

What I mean by limiting is resizing artwork in component itself (so that uploader receives only appropriate sized images)

[mynnshaw]

Another update.

Following the fix for foobar2000-catbox issue 10, I can now consistently reproduce nulls during Catbox outages (such as right now). I'm still unsure what's happening but it may be something on foo_discord_rich's end, where if the uploader is timed out, foo_discord_rich nulls the artwork url if it isn't passed anything? I would prefer to not have these null lines written to the artwork URL however, because again, when these are written to artwork url, you have to manually add the url later.

Perhaps adding logic changes that allow foo_discord_rich to work with nulled entries? I don't know. I'm still entirely unsure what triggers this behavior outside of SubprocessExecutor error: process timed out and no source artwork. Perhaps this extra information may be of use.

TL;DR: Artwork url is also written as null when the uploader times out. This issue seems to be related to how foo_discord_rich handles artwork urls when no source is given.