[Bug]Play count not always updating locally on MMA

[iain2020]

I don't know how long this has been going on, only noticed after some new music was added and my 'Unplayed Music' playlist wasn't emptying on syncing.

It seem that the play counter for tracks stored locally on MMA is only increasing 50% of the time

Example
Played 3 tracks with 0 played in full followed by starting a 4th.
1st track playcount still 0
2nd track playcount now 1
3rd track playcount still 0
Debug log: U693HXV4CD

This example was done after deleting media and wiping MMA from phone.

Edit: Spec at time
MMA v1.1.1.0411 Pro Licence (v1.1.0008) - Samsung Galaxy S5 (SM-G900F) Android 5.0
MMW v4.1.6.1736 Gold - HP Pavilion AMD A10, 8GB x64 Win8.1

[olivechicago]

I've got the same problem.

MMW 4.1.5.1719
MMA 1.1.1.0412

[iain2020]

Over the last 5 days I've been on holiday and played 202 tracks. On syncing only 71 had any updated info.
Current: MMA v1.1.1.0412

[rivorson]

This has always been an intermittent problem with MMA but it seems to be getting more frequent recently. If any of us can figure out what causes the play to not be counted then it'd help a lot. For a while I thought pausing tracks caused the problem but it also happens when tracks are played without interruption.

[iain2020]

This has always been an intermittent problem with MMA but it seems to be getting more frequent recently. If any of us can figure out what causes the play to not be counted then it'd help a lot. For a while I thought pausing tracks caused the problem but it also happens when tracks are played without interruption.

You are correct, especially about the uninterrupted playing not triggering playcount.

[Peke]

I'm not being able to replicate, any steps please?

[rivorson]

There aren't any special steps to reproduce the problem. Open MMA, play some tracks, then see which have been counted as played by either checking the track properties or by syncing with MMW. I have observed the problem with music tracks and podcasts but not with videos, though I play videos on a separate device.

To test, I created four mp3 tracks with durations ranging from 37 seconds to 67 seconds and tagged them with Artist, Album Artist, and Album all as 'Test'. Track numbers and titles were also added. Then I synced them via WiFi to MMA and played the 'Test' album via the Albums list. Once all four tracks had finished I checked the playcount of each track. The first three still had 0 plays. Only the fourth showed 1 play. Submitted debug log 6JEPICWAVZ.

Thinking it could possibly be because the screen was only on at the end of the fourth track, I set my display timeout to 10 minutes, deleted and resynced the four tracks so they would be treated as new, and played them all again. This time the first and third showed 0 plays while the second and fourth showed 1 play each. Submitted debug log LCKJX418MU.

This was done with a Nexus 5 running MMA build 412 on stock Android 5.1.

[rivorson]

The problem could be related to some factor on the device.

I just tried the same four tracks twice on my Nexus 7 running stock Android 5.0.2 and the same build of MMA. All four tracks were successfully counted as played both times. For good measure I uploaded debug log 2STR18LWHM after the first play in case it could be useful for comparison.

I wonder if it could be related to the size of the database somehow. The Nexus 7 only had these four audio tracks, several podcasts, and a few videos on the device during the test, compared to over 1,000 tracks on the Nexus 5. It doesn't seem likely, but I'll try syncing all of the same tracks to the Nexus 7 and see if it makes a difference.

Another possibility to explore is the Android version. Just anecdotally I don't think the Nexus 5 had the problem with Android 5.0 or 5.0.1. It has only been a problem (or at least noticed) since it was updated to Android 5.1, but iain2020 has the same symptoms with 5.0.

[mcow]

Is it just play count that is not updated, or is Last Played also affected?

[rivorson]

It's both the play count and the last played timestamp, as though the track was never played.

[rivorson]

Database size was predictably not the problem, but I'm gathering more evidence that Android version is at least related. My Nexus 7 received the Android 5.1 update today and now the first track played does not have its play count incremented but subsequent tracks do.

I tried playing my four test tracks and the first still showed 0 plays while the other three showed one play.
I then queued up the same four tracks to play six times. The first showed 5 plays while the other three showed correctly showed 7 plays.

I deleted the four tracks and resynced to confirm. Every time the same occurred. The first track played does not get counted as played but subsequent tracks in the Now Playing list do.

The Nexus 5 with Android 5.1 still misses play counts at random. For every run of the four test tracks only one or two will be counted as played, but it is a different one or two every time. I can't figure out why the problem is predictable on the Nexus 7 but random on the Nexus 5. Both are running Android 5.1 with MMA 415 and I'm following the same procedure with the same tracks on both.

[rivorson]

I notice that build 416 enhances MMA's logging capabilities so I have submitted fresh debug logs from both of my devices in hope that it will help diagnose the problem.

For both devices I updated to 416, ran a quick sync, played my four test tracks, checked the play counts, then submitted the logs. On both devices the first track was not incremented but the subsequent tracks were counted correctly. This is still the behaviour of the Nexus 7 every time while the Nexus 5 still increments seemingly at random.

Nexus 5 (stock Android 5.1): XOM1KD8J67
Nexus 7 (stock Android 5.1): 9N064T3KQJ

[martin.bohac]

Thanks a lot for debug logs.
Tracked at:
http://www.ventismedia.com/mantis/view.php?id=12724

It's fixed in build 1.1.2.417

Martin

[rivorson]

Thanks, Martin. I can confirm that the bug is fixed for both of my devices on build 417.

[iain2020]

Thanks a lot for debug logs.
Tracked at:
http://www.ventismedia.com/mantis/view.php?id=12724

It's fixed in build 1.1.2.417

Martin

I agree, seems to be fixed 417.