[BUG] - Tempus crashes when switched to.

[Mihara]

Describe the bug

Tempus repeatably crashes when switched to, while playing a queue with scrobbling enabled. For quite a while, this rendered it effectively unusable for me, until I decided to check through the settings and see if I can isolate any specific cause. I believe that the problem existed back in Tempo, too.

It should be said that there are no significant playback problems or issues with controlling it through the media interface. But specifically bringing it to foreground kills it.

Expected behavior

No crashes, obviously.

To Reproduce

1. Start Tempus. Enable scrobbling.
2. Start a queue to play, e.g. an album.
3. Switch away from Tempus, e.g., to a browser.
4. Switch back in any way.

Observe Tempus immediately dying with no error messages.

Environment

• Android device: One Plus Nord 4
• Android OS version: 16. (Problem also existed in Android 15)
• App version: 4.5.0 (Problem persists for at least two versions of Tempus)
• App variant: F-Droid with IzzyOnDroid repo, i.e. Github release.
• Other relevant details: The server is Navidrome 0.59 and is configured to scrobble to ListenBrainz.

Logs or Screenshots

No logs are readily available, though if you tell me what to filter for, I could perhaps sic LogFox on them.

[eddyizm]

Hi @Mihara,
I have seen this from navidrome users in the past when scrobbling is turned on and the server is not configured correctly (when it was just last.fm for example)

I am assuming your scrobbling is working in navidrome, would you be able to switch to last.fm to see if you have the same issue?

I've been scrobbling to listenbrainz with LMS on the backend for a long time (years?) without any issue.

It would be good to see if anyone else has this issue. If possible, I would need access to a test account to recreate and capture the crash log. I'm not 100% sure how to capture it yourself, or if you would need a debug apk. We could look into that as well since being able to recreate the crash is required to be able to track down and fix it.

[Mihara]

I am assuming your scrobbling is working in navidrome, would you be able to switch to last.fm to see if you have the same issue?

I'd need a Last.FM account for that, I think...

Upon further investigation, my Navidrome installation can't actually reach listenbrainz, it reports "connection reset by peer" now, because musicbrainz.org has been blocked nationwide. I'm not sure attempting workarounds, like routing Navidrome's connections through proxies, is worth the effort, so I've disabled scrobbling serverside.

This should make it easy to set up a replication: A dummy navidrome server with at least one album in it and a hosts entry for listenbrainz.org that always returns a "connection reset by peer".

I'm not 100% sure how to capture it yourself, or if you would need a debug apk. We could look into that as well since being able to recreate the crash is required to be able to track down and fix it.

Well, as long as the app ID does not interfere with existing installation, I don't have any problems installing a debug APK.

[felixconsulting]

I just had an issue where switching from the browser caused the app to severely lag for about 10 seconds, after the lag it would return to normal functionality. There is a possibility that OxygenOS is stricter than GrapheneOS with resources and killed your app, but GrapheneOS kept mine going at a snails pace. The fix for me was force quit and clear cache, but if this happens again I will be sure to save a log.

[eddyizm]

@Mihara here is a debug apk, the app id is different from the release version

Capturing the log output from the app with adb and getting the corresponding server logs would be very helpful.

[girlmaya]

I just ran into this after updating to 4.6.0 - I may have been a few versions behind before updating. I was also using the downloads feature for the first time and my guess is that this is the more likely cause. I never ran into this issue on Tempus, maybe many months ago on an old Tempo release. I have had scrobbling enabled for a long time.

BTW it shouldn't matter which service you scrobble to from Navidrome, nor if it fails to scrobble to external services. As far as I know, it only matters if the scrobble is successful in Navidrome.

[Mihara]

...Funnily enough, now I can't replicate it in the debug build linked above or the 4.6.0 release. Which sugggests something a lot more obscure is going on. Unlike @girlmaya I never actually used the download feature.

It's definitely not the battery killer: OxygenOS has been very well-behaved for me ever since 14.0, provided I set the applications I don't want to be killed to "allow background processing", and Tempus has always been on that particular list. More importantly, the crash I describe only happens when the application is brought into foreground, between 0 and ~100ms after it is, and battery killer never touches foreground processes.

[eddyizm]

@Mihara Should we close this issue for now? I have not experienced it on my end but we do need to be able to isolate and replicate it. As mentioned by @girlmaya the scrobbling failing should not matter however i need to see what wacky responses the server sends back in order to handle it correctly.

@felixconsulting I am beginning to suspect the cache is the culprit of a lot of issues. I tracked it down as the root cause for another bug for airsonic.

[Mihara]

I suppose we should, though I suggest you look deeper into what is happening when the app is brought into foreground while playing...

Because here's a hypothesis: Scrobbling introduced a delay that triggered a race condition somewhere while rendering a "now playing" screen. With 4.6.0, this delay, for whatever reason, became shorter and the condition no longer triggers, but that doesn't mean it can't resurface.

[girlmaya]

Sorry, but is it really reason enough to close an issue just because the cause is unclear? This is still a bug, even if no one has the time to properly triage it, isn't it better left open for visibility and to avoid duplicates being opened in future?

I have not had this bug at home with Navidrome on my LAN, only remotely on the secondary address. Perhaps this is a common denominator?

[pr0927]

I've been having this issue and concur that it doesn't make sense to close the issue due tk the culprit being unknown. The app works perfectly unless i unlock my screen or switch from another app to it. Then it just crashes. Clearing cache has done nothing. Scrobbling has been working fine for months to Last.FM and ListenBrainz.