Play count of tracks is not being updated

[zicoian]

I emailed from the app back in May about this bug but it doesn't appear to have been picked up properly.  Since then counts are not being incremented for any tracks played as an album or in a queue EXCEPT the final track in a queue.  I have set the Count As Played property to 100%.  Is this a MIUI problem?

The current version info is:

Version Info ======================
Build: Poweramp build-911-arm64-play full verified cached
Store: Play
Unlocker: build-302
Arch: 64
Skin: ActivityTheme_Black
Device: Xiaomi Redmi Note 8T willow willow willow_eea [arm64-v8a, armeabi-v7a, armeabi]
Installer: com.android.vending (26.7.16-21 [0] [PR] 390726529)
Android: 10 xiaomi/willow_eea/willow:10/QKQ1.200114.002/V12.0.4.0.QCXEUXM:user/release-keys en_GB

I had the same problem for the following version as well:

Version Info ======================
Build: Poweramp build-905-arm64-play full verified cached
Store: Play
Unlocker: build-302
Arch: 64
Skin: ActivityTheme_Black
Device: Xiaomi Redmi Note 8T willow willow willow_eea [arm64-v8a, armeabi-v7a, armeabi]
Installer: com.android.vending (25.3.17-21 [0] [PR] 372634721)
Android: 10 xiaomi/willow_eea/willow:10/QKQ1.200114.002/V12.0.3.0.QCXEUXM:user/release-keys en_GB

 

[andrewilley]

Why set the threshold to 100%? Try a smaller figure, in case crossfade/etc is not triggering the count (the counter is incremented when a track-change occurs while the current playback cursor is bigger than the threshold value).

Andre

[zicoian]

I could do that but why allow 100% to be chosen if it causes problems like this.  I'm not using crossfade (as far as I can tell!).

[andrewilley]

Give it a try anyway, see if it makes a difference, might help to work out what's going on for you.  The default is 50% by the way.

Andre

[zicoian]

Sorry it's taken so long to get back to you but I tried what you suggested and it MOSTLY works...

I found reducing the threshold to 90% (or 80%) does make the play count increase by one EXCEPT for the last track on an album (if I'm only playing that album) or on a playlist.  Initially in both cases the play count is increased but the last play time is not.  When any other track is played after that by any means, the play count on the track without a last play time reverts to zero.  The exception is the last track in a queue (if the queue is started from scratch) and that is probably only because Poweramp then re-plays the last track played before the queue was started.

If the track threshold is set to 100%, I still get the same result as previously (only the last track has its play count incremented) but I hadn't noticed that the last play time is not amended so I'm guessing that the count will be reset to zero when another track is subsequently played.

As in the other bug I reported (lock screen notification info not being updated), my MIUI version is now V12.0.2.0.RCXEUXM Android 11 RKQ1.201004.002.

For what it's worth, I think there are two problems here now:

1) Setting the count threshold to 100% doesn't work as it should and maybe shouldn't be allowed to be selected.

2) The last track played before Poweramp stops playing does not have its last play time updated and the play count is reverted to its previous value once another track is selected for play (if count threshold is less than 100%).

[andrewilley]

The Play Counter only increments at the point when PA moves onto the next track, as long as the counter position is greater than your defined threshold (e.g. more than 50% of the total track duration).

The problem that you are encountering occurs on the final track of a category, but only if you allow it to STOP at the end. This sets the counter back to zero, so it doesn't meet the threshold requirement.

Set Repeat mode to Advance Category to get around this.

Andre

 

 

 

[zicoian]

I have got the play count to work now by setting the Repeat mode to Advance Category as you suggested.  However, the problem with all this is that the Play Count facility doesn't work "out of the box" as it were.  I should be allowed to set the count threshold to 100% if I wish and for the track to be counted and I shouldn't need to fiddle with the Repeat mode to get the final track to be counted.  Play counts work in all other players I have used without jumping through hoops - maybe a rethink is required for Poweramp and a bug report raised for this?

[andrewilley]

'Advance Category' is the default out-of-the-box mode, you don't need to set it specially.

But I agree it's an issue that the Play Count only gets incremented using the logic that the counter needs to be over the threshold level when the track changes. I think it might make more sense if the counter was incremented when the track ends (stops and does not advance) too.

Andre

[andrewilley]

@maxmp The bug where the Play Count and Last Played Time values for a fully-played-and-advanced song aren't incremented if the user has set the threshold to 100% still seems to be present.

Andre

[BoringName]

This issue of play counts not updating unless the player moves to another track caused me a bit of grief this week. In my case it was updating the last played time but not the play count when I was test playing one track at a time while troubleshooting an issue with a different app.

I found this thread so I know what the issue is now but I'm having trouble understanding why it hasn't been fixed in over 3 years. Surely the solution is moving the process that updates the play count to the same trigger that updates the last played time? The player moving to another track shouldn't be a requirement for the play count to update.

The "Advance Category" option is a poor workaround not a solution.

[andrewilley]

The "100% threshold" bug seems to now be OK - unless you have crossfade enabled. When crossfade is enabled, and a 100% threshold is set, the play counter does not get incremented when a song auto-advances to the next track - presumably as the first song never reaches its 100% duration threshold as the second song has already started before then. The solution is to set the threshold level to 90%-95%, which works in almost all cases.

The other issue, the logic of the play count only being incremented when the counter is above the threshold level at the point of advancing to the next track is more of a design decision than a bug. And it does have the undesirable effect of not counting a final fully played track in an album or folder if you have Repeat set to 'Off' (as it never advances) which I agree is not what a user would expect.

My own suggestion was to change the counting logic so to be considered as one 'play', a song needs to have been listened to contiguously for at least the amount of time defined in the threshold setting. So using a 5-minute song and a threshold setting of 50% as an example, the Play Count would be incremented if the user listens from 0:00 to 2:40, or from 1:00 to 4:00, etc - regardless of whether they then move on to a new song afterwards or not.

If would not however trigger for a situation where the users listens to only the last minute of a track (such as 4:00 to 5:00), nor if the cursor is bounced around during playback. For example if would not be trigged by listening from 0:00 to 1:00, then skipping to 2:00 to 3:00, then finishing with 4:00 to 5:00, as each contiguous portion would only be a minute long.

Once a Play Count has been triggered during listening to the current song, it should not be counted again based on just moving the cursor around, UNLESS the user starts back at 0:00 again. So listening from 1:00 to 4:00 five times would still count as just one 'play', but repeat listening from 0:00 to 4:00 five times would count as five plays. That also covers the 'Repeat One Song' counting inconsistency.

I agree that the same logic ought to be used for the 'Last Played Time' value too, with the stamp only being updated if the same criteria as used for Play Count are met. 

Andre