As a test I have subscribed to a podcast that I was not previously synced with on Gpoddersync and it also did not contain album artwork, so it may be that something for me it just broken with album art in general.

It sounds like a problem with the network connection on the Arch machine(?).  The album art gets fetched directly from the internet; it doesn't go through gpodder at all.

Could it be that your connection is considered to be metered?  If so, you need to enable downloads on metered connection through the network settings.  (Due to the bug you filed yesterday, you would have to click on the text, rather than the checkbox itself).

If the problem persists, you could try running "QT_LOGGING_RULES=org.kde.kasts.fetcher=true kasts" and posting the output here (after censoring potential sensitive data, although I don't think it should contain any).

The Arch machine has unmetered internet access and can successfully stream and download podcasts through Kasts. Additionally I have every feature allowed on metered internet. Posting log now.

Created attachment 156644 [details]
Stderr Log of Kasts

Results of running `QT_LOGGING_RULES=org.kde.kasts.fetcher=true org.kde.kasts &> kasts.log`

The log shows nothing strange.  I assume that you can open image links that it found in the feeds through your webbrowser without any problem?  E.g. https://i1.sndcdn.com/artworks-000272565842-6j5rii-t3000x3000.jpg (I picked an example from the log file).
Do the images appear on the windows machine?

You could try going into Settings > Storage and check that the storage path is on default.  Then check the size of the image cache (to see if it downloaded anything) and then try to empty the image cache to see if that retriggers a proper download of all the images.

Could you maybe share a screenshot of what it looks like?  (There are several states of "no image" in Kasts; that might be a hint to find the root cause).

Otherwise, I'm a bit at a loss about what might be going on.  The image retrieval and episode download methods are actually sharing most of the same code, so I'm trying to imagine where it could go wrong.

Created attachment 156645 [details]
screenshot of missing album artwork

Storage is using the default path 

`$HOME/.var/app/org.kde.kasts/data/KDE/kasts/`

Image cache is using 168.6 MiB. `/home/ben/.var/app/org.kde.kasts/data/KDE/kasts/` is full of correct images of album artwork, but they do not display from within Kasts. 

I went ahead and cleared this cache and it redownloaded 4 images on the next sync, but they still do not display from within the app.

This may be a separate issue, but I also have "Always show podcast titles in the subscription view" selected but they do not display.

Well, that's definitely related.

I was looking at that screenshot, and it looks very strange.  There should always be at least a title and a "three dot" menu on each of the podcast delegates.  So there's nothing wrong with the image downloads (as you've just confirmed yourself).  This seems to be caused by an underlying rendering problem that seems to be affecting more than just images.

Since I'm not seeing any errors being reported in the log file, and since QtQuick makes use of OpenGL for the rendering, I'm beginning to suspect some graphics-related problem(?!).  Especially since it shows up in the AUR and flatpak version which are not sharing anything in the software stack except the hardware drivers and graphics settings.
(Sorry, these kinds of things are also a bit outside of my expertise.)

It is very well possible. I've found an issue with Nextcloud that had another image rendering issue:  https://github.com/nextcloud/desktop/issues/5443

I am using nvidia propritary drivers with. 
07:00.0 VGA compatible controller: NVIDIA Corporation GP106 [GeForce GTX 1060 6GB] (rev a1)

I'm also keeping Arch up to date.

I've been able to reproduce your issue.  I can get something that looks exactly like your screenshot by forcing Qt to use software rendering (which seems to skip all the graphical elements that need more complex rendering).

I was running "QT_OPENGL=software QT_QUICK_BACKEND=software QML_SCENE_DEVICE=softwarecontext kasts &"
So my hunch is that QML apps are opening in software rendering mode on your machine.

That nextcloud thing seems very much related.  To be honest, my bet would be on the NVIDIA drivers rather than anything in the archlinux software stack and libraries.

I'm running archlinux as well.  I have a machine with an older NVIDIA graphics card in it.  I'll try later today to update that machine and see if I can reproduce.  Otherwise, I'm afraid there's nothing more that I can do to help.

Interesting! 

I followed the Archwiki suggestions for testing hardware acceleration: https://wiki.archlinux.org/title/Hardware_video_acceleration

mpv --hwdec=auto video.mp4

And the video functioned correctly. 

Do you know a method to force QML apps to use hardware rendering?

Hardware rendering in general seems to work on your machine since the Kasts window in your screenshot has a shadow border effect (which similarly must be rendered by the GPU).  But for some reason the qml app itself seems to fall back.

You can probably try forcing it through some of the env variables I used to force software rendering.  But I don't know the settings by heart.  And there's a large chance that it won't work: otherwise the qml lib wouldn't be falling back to software rendering since that's the last option it tries.  Sorry, this is not my field of expertise.

Opened a forum topic on QT. 

https://forum.qt.io/topic/143206/qml-apps-fall-back-to-software-rendering-and-produce-visual-bugs

I am really at a loss for how to begin troubleshooting this (I am not a developer) I have Kasts open in kdevelop and I am looking around and trying to read QT documentation but I can't even find documentation on the syntax of the environment variables.

I found a work around.

Within FeedListDelegrate.qml, line 212

        // Rounded edges
        layer.enabled: false //test ben
        layer.effect: OpacityMask {
            maskSource: Item {
                width: img.width
                height: img.height
                Rectangle {
                    anchors.centerIn: parent
                    width: img.adapt ? img.width : Math.min(img.width, img.height)
                    height: img.adapt ? img.height : width
                    radius: Kirigami.Units.smallSpacing - borderWidth
                }
            }
        }
    }

Changing the line commented //test ben caused images to work again in Kasts. Screenshot coming shortly.

Created attachment 156661 [details]
workaround result

> Changing the line commented //test ben caused images to work again in Kasts.
> Screenshot coming shortly.

Well, yes, those layers using shading operations are the things requiring (GPU) rendering.  There are several of those in the source code.

But that's just a very short term workaround for an underlying problem in your particular hardware/software setup.  If you don't tackle that problem then it will probably keep popping up in different forms with strange symptoms across apps and UI frameworks.

It seems like it must be software related because the Nextcloud AppImage does not have this problem. This makes me think it must be something with my libraries, but reinstalling qt5-declarative has not done anything. I am currently trying the qt5-declarative-git from AUR.

The AUR package did not work. I just cannot believe this is a hardware or driver problem if the Nextcloud AppImage works.

This appears to be a bug in KDE plasma-integration which I have reported here: https://bugs.kde.org/show_bug.cgi?id=466804

(In reply to benmordecai from comment #22)
> This appears to be a bug in KDE plasma-integration which I have reported
> here: https://bugs.kde.org/show_bug.cgi?id=466804

Thanks for the update.  Then I'll close the bug report here.  There's nothing that can be done from Kasts.

*** This bug has been marked as a duplicate of bug 466804 ***