Long Press Functionality Borked in Builds Past 933

[technica348]

Hello,

I was wondering if a toggle could be added to revert the fast forward and reverse functionality to the way it was before build 933. I have a Hyundai Sonata that supports holding down to fast forward and reverse, but every time I attempt to do this on any build past 933, it skips the track without waiting for the command to fast forward or reverse. The way it worked before was that it would wait and then fast forward or reverse without skipping ahead a track. Single flick would skip the track. Now it does both because I hold it down and it skips the track and then fast forwards when it should only be performing one command at a time (single press for skip track, hold to fast forward). Same goes for reverse. Holding back will go back a track and then begin reversing. I know something got changed for compatibility reasons but is there any chance that there could be a toggle to restore the old functionality for devices that rely on this? Thanks again for all of the hard work that is put into this app.

[andrewilley]

Please could you paste in a copy of the Last Processed Commands log (in PA Settings=>Headset/Bluetooth) for just the period of holding that button down and releasing it (you can clear the log before testing if that helps). Thanks.

Andre

[technica348]

Sorry for the late response, here is what I am getting. One is the old one (file name starts with OldPW) and the new one (NewPW) which is the latest build of whatever is on the play store.

Let me know if you need anything else.

[andrewilley]

That log shows the 'Next' button (often indicated as '+' on car systems) being held for a brief period (during which PA went into Fast Forward) and then released just under two seconds later - timecode 20.959 seconds for the start, then  21.344 saying still pressed, and finally 22.640 seconds when the button was released. How long did you keep the button pressed for? There is also a BT disconnect/reconnect occurring first, which seems a little odd unless you didn't clear the log first.

Andre

[technica348]

7 hours ago, andrewilley said:

That log shows the 'Next' button (often indicated as '+' on car systems) being held for a brief period (during which PA went into Fast Forward) and then released just under two seconds later - timecode 20.959 seconds for the start, then  21.344 saying still pressed, and finally 22.640 seconds when the button was released. How long did you keep the button pressed for? There is also a BT disconnect/reconnect occurring first, which seems a little odd unless you didn't clear the log first.

Andre

The log was cleared, I am starting to think this has to do with a change that was made after 933 where the delay for the fast forward/reverse action to occur was changed. I forgot where I read this but this was definitely on the changelog at some point. I can film a video of the function before and after since the logs don't show anything different.

[technica348]

Hello again,

I made two videos showcasing the bug in more detail. One is on build 933 without any updating and the last video is after updating to the latest google play build.

Hopefully this provides more clarity to this bug in question.

Before updating: 

 

 

After Updating:

 

 

[technica348]

bump

[andrewilley]

I have the basically same Hyundai head-unit and steering-wheel controls as you, and it works fine to trigger Fast-Forward and Rewind in the latest builds of Poweramp via Android Auto, by holding down the steering-wheel ˄ and ˅ buttons. 

What do you see in the Last Processed Commands log for each of the two tests?

Andre

[technica348]

On 11/2/2022 at 7:16 PM, andrewilley said:

I have the basically same Hyundai head-unit and steering-wheel controls as you, and it works fine to trigger Fast-Forward and Rewind in the latest builds of Poweramp via Android Auto, by holding down the steering-wheel ˄ and ˅ buttons. 

What do you see in the Last Processed Commands log for each of the two tests?

Andre

I am sorry for the late reply. I just updated to build 945 and the issue is fixed. I guess it was a fluke with some build in-between build 933 and 945.