Calls to getCoverArt (and possibly other API methods) don't URL-encode the username about tempo HOT 19 CLOSED

Actually the fact that the signed app didn't work, while the unsigned app worked was a big hint.

I admit that I don't often try both versions because it is in continuous development, so the app I use is the debug one built by Android Studio.

Another issue that threw me off track is the fact that for you the app first worked and then didn't (without having changed anything about the networking part). And this is still a mystery to be figured out.

In short, I solved it by excluding Retrofit (the library that manages the network part) from the obfuscation of ProGuard. At this moment the exclusion is total, it could be further refined.

-keep class retrofit2.** { *; }

What I'm saying with this rule is "keep everything as it is, don't obfuscate anything" pretty much.

from tempo.

Hi @gravelld, thanks for reporting.

Apparently Retrofit, the library to manage the network, applied a manual encode before making each request, hence the correct operation of the navigation. On the contrary, Glide (image loader) and Media3 (trivially the media player), use the original uri. Good to know!

I'm about to post a pre-release build. From my local tests everything still works, but it's always better to test in more users.

from tempo.

New version released, waiting for your test results.
If the problem is solved you can close this issue.

from tempo.

I tried the new build, but when I add a new server and press it to view the library the app seems to crash. Restarting Tempo seems to crash too.

from tempo.

Well, that's very strange. Can you pass me the crash log or give me a chance to try it myself?

from tempo.

I'm not sure how else to get you that other than logcat, let me know if there's a better way.

Here's what I found that reference the Tempo pid.

fwiw the user that originally reported this issue experiences a crash on startup too.

from tempo.

Does Astiga have a demo instance to replicate the problem with?

from tempo.

It does; can you get in touch via email?

I don't think it's even getting that far though...

from tempo.

This is my junk mail: email

Not being able to reproduce the crash with navidrome, gonic and now airsonic-advanced, I'd like to try with Astiga.

from tempo.

Oh, I assumed the app was just crashing on startup and not even making a HTTP call. I've sent the email.

from tempo.

Hi @gravelld, even with the demo user on the Astiga instance I can't reproduce the error. Unfortunately, the logcat you sent me is unreadable as the app is signed with the release keys.

Could you try this apk and take another logcat? This is the version published on F-Droid (but not signed), it is the same but without Google services. This way I don't overwrite the already installed version of the app.

app-notquitemy-debug.zip

In the last step, I would like you to clear the data of the current app and start from scratch.

from tempo.

Well I'm sure this will surprise you (or maybe not) but the above APK works fine for me. Also, the original bug is fixed.

Not sure what was up with the APK previous. I was installing it by downloading it from Github with my device and then installing it on the same device by launching the APK.

from tempo.

Well, yes... The code of the two versions hasn't changed much.
Could you try, if it's not a problem, to download the latest version (v3.5.2) which I will upload shortly, delete the old data and try to access again?

from tempo.

I'm afraid the same thing happens - it crashes as soon as I press the Subsonic server I configured. I tried installing both on the phone and via adb.

from tempo.

Okay, I guess I just don't know what to think anymore.
The last alternative is to proceed with the unsigned app installation and grab another logcat at the time of the crash.

app-tempo-debug.zip

from tempo.

That one starts fine... I've attached the log anyway.

tempo-startup.log

Looks like you can see some decipherable stack traces which might map to the original ones in the version that crashed.

Could it be an Android version issue?

from tempo.

Okay, maybe you gave me an idea

from tempo.

I'm so sure (almost) and hopeful that I've fixed the problem, that I'm releasing a new release without waiting for the test results (please test it and give me good news).

from tempo.

Yes, that works! And the original bug is solved too! I'll mark this closed, but as a novice Android developer myself (trying to maintain the Astiga Android app) I'd like to know what the issue was for my own learning...

from tempo.