Fails to pause/resume correctly

MrAndrewMrAndrew Member

Hi,

Pixel 8 pro, Pixel buds 2 and Android Auto.

If I am listening to a track using my earbuds or via Android Auto, and I pause playing, it will only resume correctly if I unpause within a short period of time. Otherwise, hitting play on my earbuds or Android Auto does not cause the track to play. This may only occur if Astiga is not the top app; not sure. Anyway, the only way to resume playback is to go to the phone and hit play within Astiga.

Comments

  • gravelldgravelld Administrator

    Does it happen without the earbuds? Just trying to isolate what might be the cause...

  • Hi,

    Thanks for following up. I dont think it is possible to perform that test (or at least, I dont know how I would.) When it fails to un-pause from my earbuds or car screen, the "fix" is to use the phone interface to hit play in Astiga. If I start a track in Astiga then hit pause, I dont know how I could then tell it to play without hitting "play" in Astiga.

    Andrew

  • gravelldgravelld Administrator
    edited October 3

    I just mean using the car interface - pausing and unpausing. Not the buds. I'm just wondering if the extra Bluetooth device and hop is causing an issue.

    Sounds a bit like https://github.com/daneren2005/Subsonic/issues/1039 ? (It's the same underlying source code as the Astiga app). Have you tried playing with Persistent notification?

  • Hi, I was not able to reproduce this in my 2020 Corvette because of the user interface in that car. I was able to make it happen in my 2013 Porsche Cayenne.

    Using both Google Maps and Astiga on my phone, Astiga shows up as a set of controls at the bottom of the screen below the map. If I hit the off button on the entertainment center, after a while (not sure how long - seems inconsistent; a minute?) the controls disappear from the bottom of the phone's screen. If I turn the entertainment center back on, it shows "no information", nothing is playing, and entertainment center controls dont do anything (forward, back, play, pause.) The same thing happens if I change the music source (the phone plays through ALT BT). If I change from ALT BT input to iPod, radio, etc., for a while then when I go back to ATL BT, Astiga is no longer active. To get it to work again I have to switch to the Astiga app directly on my phone.

    That behavior is comparable to accessing it through ear buds.

  • gravelldgravelld Administrator

    Sounds like some sort of background/foreground issue. I'll try replicating with the Android Auto emulator, restarting it, to see if the same behaviour is exhibited.

  • I don´t use Astiga now. But with other players, pause/resume doesn´t works fine after last Android auto update.


    Also, if you can´t launch Astiga or other apps directly from Android Auto interface, you must be sure that app has auto start option enabled.

  • gravelldgravelld Administrator

    I just tried this with the Android Auto "Desktop Head Unit". It's a testing program that simulates a car's Android Auto implementation (I guess the same thing as your car's "entertainment center".

    Here's what I did:

    1. Opened Astiga in the DHU. Chose some music to play and played it.
    2. Closed the DHU. Music stopped.
    3. Restarted the DHU. Music started again, the controls in the DHU worked.

    I also tried disabling "Start-up mode" / "Start music automatically". This meant that when restarting the DHU it didn't start playing music immediately. However, the controls worked in the DHU and I was able to restart.

    I'm not sure how fair a test that is...

  • Hi,

    How long did you leave it off for? Turning off and right back on works, both with ear buds and auto. The issue is if it is off for some amount of time. Not sure how long, and it doesnt seem to be consistent. At least a minute.


    Andrew

  • gravelldgravelld Administrator

    Oh, sorry. Good point, will test.

  • gravelldgravelld Administrator

    I think I replicated similar behaviour. After leaving it a while and restarting the DHU, the Astiga portion of the DHU is greyed out and cannot be started:

    Before, that portion on the left showed the previously playing media and I could restart.

    Technically, I can see in Logcat (the Android logs) that Astiga is destroyed after the timeout:

    2024-10-11 10:18:48.133 11377-11410 TrafficStats           ga.asti.android                     D tagSocket(198) with statsTag=0xffffffff, statsUid=-1
    2024-10-11 10:18:48.629 11377-11377 DownloadService        ga.asti.android                     D onDestroy
    2024-10-11 10:18:48.630 11377-11377 DownloadService        ga.asti.android                     I PAUSED -> IDLE (DownloadFile (concerto pour violon no. 2 en si mineur, sz. 112))
    2024-10-11 10:18:48.637 11377-11422 DownloadSe...cleSupport ga.asti.android                     I Serialized currentPlayingIndex: 0, currentPlayingPosition: 0
    2024-10-11 10:18:48.650 11377-11377 Compatibil...geReporter ga.asti.android                     D Compat change id reported: 147600208; UID 10301; state: ENABLED
    2024-10-11 10:18:48.658 11377-11377 MediaPlayer            ga.asti.android                     V resetDrmState: mDrmInfo=null mDrmProvisioningThread=null mPrepareDrmInProgress=false mActiveDrmScheme=false
    2024-10-11 10:18:48.658 11377-11377 MediaPlayer            ga.asti.android                     V cleanDrmObj: mDrmObj=null mDrmSessionId=null
    2024-10-11 10:18:48.669 11377-11377 MediaPlayer            ga.asti.android                     V resetDrmState: mDrmInfo=null mDrmProvisioningThread=null mPrepareDrmInProgress=false mActiveDrmScheme=false
    2024-10-11 10:18:48.669 11377-11377 MediaPlayer            ga.asti.android                     V cleanDrmObj: mDrmObj=null mDrmSessionId=null
    2024-10-11 10:18:48.679 11377-11377 MediaRouter            ga.asti.android                     W Ignoring invalid provider descriptor: null
    

    ... and then the log simply ceases. On restart there's no more - the app has been stopped. We need some way of restarting it.

    So yes, I think it relates to foreground/background apps and something in Android called "notifications". One thing I noticed, I think, is that if Astiga is shown on the phone screen (which forces it into the foreground) then the restart is survived. However, having maps open with the Astiga buttons on the bottom is not enough to qualify as "foreground) I don't think.

    Pertinent is this discussion: https://github.com/androidx/media/issues/672 . We don't actually use this library (yet) but mention of Bluetooth buttons is there with the "proper way" of handling this.

  • Hi,

    I am uncertain as to whether there is an action item or workaround for me. Is there anything I can do to address this, or am I awaiting a fix from you?


    Thanks

    Andrew

  • gravelldgravelld Administrator

    Sorry - it's for us to look into and fix. It might be quite involved though. The media player the app uses is quite old and showing all signs of strain under newer Android versions which have tightened rules on foreground/background to preserve battery life. So it might be a while.

    You could try playing with settings about battery usage btw - make sure Astiga isn't "optimised". See this, for another app: https://podcastaddict.com/faq/13 . Let me know if that helps...

Sign In or Register to comment.