I'm seeing cases out in the wild where calls to Media.setAlbumArt are crashing the app with a System Error. Unfortunately, due to the nature of this crash, I can't provide a reproducible test case, but I do have a some clues that could help track this down.
- Clue #1: The crash seems to affect only a few users, but when it does, the crashes are repeated. In other words, a few unfortunate users are getting into a corrupted state that's causing
setAlbumArtto crash repeatedly. - Clue #2: The app's
Communications.onResponsehandler for theCommunications.makeImageRequestcall ensures that only album art images where theresponseCodewas 200 are persisted. In other words, the makeImageRequest call must have believed it succeeded by the time we callsetAlbumArt(otherwise the code would have just set an empty image).
My initial thought was: what if the image is being corrupted during transport? I'm assuming the TCP stack is reliable, so checksums at the link and transport layer should protect the stream-of-bytes in the pipe. But what if the corruption is occurring at the OSI application layer, e.g. what if the application is emitting a HTTP 200 response line and then corrupting the data as it's being streamed. For example, timing out and closing the connection without transmitting all of the bytes (?) Could the watch see a 200 OK but not get a valid image?
If the watch is doing additional checksumming after receiving the payload, then that would protect against this kind of corruption, I'd think.
But it might not be a transport issue at all. It also could be a problem with the image payload itself. I believe the original image at the origin server is valid because when I try to reproduce the issue on any given album art, it always works. So the corruption is very transient.
I have the vague memory that Garmin does some server-side re-encoding of images to optimize them for delivery to the watch. If that's right, perhaps there are some failure modes within that app that can cause a corrupted image to be sent undetected.
