I assume this is an issue on the Tempo app's part, so I filed an issue there. However, since I cannot be 100% sure if the issue is on his side (alone), or the Astiga server is part of the cause I wanted to give a heads-up here too.
Thanks - do you mind if I query the database to replicate the API response for that album (it might contain some additional metadata). I can run it past you first if you like. I can then post it to the issue which would probably help Antonio.
No problem! There shouldn't be anything odd in the metadata of those tracks. If you just anonymise any personal/account data if those exist it's ok.
Hmmm, interestingly I tried to replicate but it works for me on that exact album. Have you recently changed the art?
Do you know how to use adb and logcat to get logs?
I haven't changed a thing. This one was uploaded as-is.
I know how to use ADB, altrough I haven't used it much. Haven't used logcat before. If you got some documentation, I'm sure I could grab stuff.
If you connect your phone with USB, enable debugging/developer options and so on (I'm being purposefully vague because I'm not sure if it's worth setting this all up if you haven't already) then you can do something like:
adb logcat -t '09-20 09:48:00.0000'
... to output all the logs since that time. This might produce a lot of output, and includes stuff unrelated to Tempo - but you should be able to search for tempo to find it. You might find reference to
This is the call for cover art. You might find some more logs around this which indicate a problem.
Feel free to email what you find if you're concerned about privacy.
I have packages installed for ADB, I use it sometimes, just not much so I'm not that deep into ADB command. But it's a good way to remove all the bloatware that's unremovable by normal means 😉 .
Does the stuff related to Tempo have "tempo" in the name? In that case I should be able to filter easy with grep using something like:
./adb logcat | grep --line-buffered tempo > log.txt
If you're sure about the /rest/getCoverArt I could grep on that too of course. But by the use of might, it sounds like you're not 100% certain on that one.
I'll see if I can give it a run this afternoon.
Yes, although grep works on a line by line basis and stack traces are multi line, so they will be missed. The main thing is to find the time in the log file that the issue occurred and look around that.
I will try to get to you later today with a log, I've been ridiculously busy at work.
Either way, I noticed that none of the podcast images load in Tempo either. What do you think? Same issue of different?
Not really much use speculating... Might be better to ask the Tempo author.
Regarding the podcast images, I got the following answer:
[...] could you make sure that the server responds correctly to you using this endpoint?
all other covers, I do nothing other than query this API to receive the information I need, I do not distinguish between the various covers of the various objects (tracks, albums, artists, podcast episodes, channels, etc.).
Great! It's fixed on podcasts channels now, but he requested some more logs for episode images. I @'ed you but just in case I let you know here too.
Sounds like it's sorted... 👍️