trapier

Found a reliable work-around for the issue is to disable mobile data before starting casting. Automated this with Llamalab's Automate. https://llamalab.com/automate/community/flows/46799

Have regularly had the same issue noted elsewhere whereby casting makes the "start" sound on the designated speaker, but then the playback cursor loops over the same two seconds in Poweramp and no music comes out of the speaker. My phone is rooted so I checked and noted when this is happening that Poweramp is listening on an interface which is not reachable from my home network: # ss -tnlp | grep mpz LISTEN 0 50 [::ffff:192.0.0.4]:18888 *:* users:(("mpz.audioplayer",pid=7114,fd=211)) LISTEN 0 50 [::ffff:192.0.0.4]:18889 *:* users:(("mpz.audioplayer",pid=7114,fd=196)) # This 192.0.0.4 address is a /32 on the v4-rmnet_data1 interface, which seems to be associated with the mobile data network. It's inaccessible from my home wifi network. In those instances where casting does work I see that Poweramp is bound to the the address of the phone's wlan0 interface. Haven't yet figured out reliable steps to make it fail vs work. I've experimented with using iptables on the phone to nat from wlan0 to this 192.0.0.4 address, but that hasn't yet helped. This is incomplete in terms of a bug report, but figured it worth raising in the event that it sheds light on a potential improvement to the algorithm Poweramp uses to select a listening address for casting. Poweramp build number build-976-bundle-play [976004-c2601e58] Full Version 64 bit device model Pixel 4A 5G Android version 13 stock ROM steps to reproduce not yet established

Poweramp's EQ can be externally controlled through intents. Is there a similar way to turn the Tempo knob? My goal is to design exercise routines with scheduled tempo changes. Poweramp doesn't yet consume track BPM metadata, but I can query the path of the currently playing file through the content provider and read BPM tags separately. In lieu of an API for the tempo knob, the adjacent +/- buttons look like a potential target for UI automation, but it'd be more reliable and easier on my battery if I could just send an intent.

Never mind. I'm doing it wrong. It's much less typing to visit the "Recently Added" playlist category from which rescan is readily accessible.

Please consider adding a rescan item to the overflow menu on the search screen. After downloading a new audio file, I frequently find myself: 1. Hitting search to find it 2. Realizing I need to rescan* 3. Switching to the library screen to rescan 4. Going back to search * am aware of the feature to automatically rescan when there are changes to files. Usage of that feature should be considered orthogonal to this request.