Cover Artwork Disappearing after App-restart

[sevachka]

I am using Windows 11 on ARM. My music-source is a smb-network-share.

Once the app scanned all my music, I can use the app without issues. It is automatically loading the artwork.

Bug:

After restarting the app (closing and reopening, also after reboot) all the cover-artwork is gone and it will not reappear until I re-scan the library.

[dosubot[bot]]

Hi @sevachka! I'm Dosu and I’m helping the Screenbox team.

This is a known limitation in the current Screenbox design: cover artwork is only kept in memory and is not cached or saved to disk, so it disappears after an app restart or reboot. The app extracts artwork from your music files on demand, but unless you re-scan the library, it doesn't reload the artwork automatically. There is no persistent artwork cache or storage mechanism implemented yet, which is why you see this behavior.

A long-term solution would involve extending the existing caching system (used for songs and videos) to also save artwork images locally and link them to your media records, so the app can reload them on startup without needing a full rescan. This would require changes to how artwork is stored and loaded in the app’s codebase, especially in the caching and media view model logic.

For now, rescanning the library is the only way to restore artwork after a restart. If you need technical details or want to discuss possible implementation approaches, let me know!
Reference

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[huynhsontung]

What @dosu said is not true. Normally you don't need to re-scan the library for the album arts to show up. Scanning the library does not load the album art. If the album art is not already available in memory, the app tries to extract the album art from the media tag every time an album art is requested.

I think there may be some weird behavior with SMB files that prevents the app from reading the album art every time.

[dosubot[bot]]

You're right—the app is designed to extract album art from the media tag on demand, not during library scans, and it doesn't persist artwork to disk. For SMB shares, the extraction relies on being able to open the file each time artwork is requested. If the SMB connection is unstable, permissions change, or the session expires, the app's attempt to read the artwork (via StorageFile.OpenStreamForReadAsync) can silently fail, resulting in missing covers after a restart. There's no SMB-specific workaround or persistent artwork cache, so this behavior is likely due to the network share not being reliably accessible when the app tries to reload the artwork after a restart. Improving this would require either more robust error handling for SMB/network files or implementing persistent artwork caching.
Reference

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[heksesang]

Should this issue be closed? This is still an issue when using network drives.