View Issue Details

IDProjectCategoryView StatusLast Update
0016977MediaMonkey 5Playbackpublic2021-10-14 17:09
Reporterrusty Assigned To 
Status assignedResolutionreopened 
Product Version5.0 
Target Version5.0.2Fixed in Version5.0.2 
Summary0016977: Play status improvements
DescriptionAs pointed out by Martin, there's no visibility in MM into:
- in what cases the play counter is increased (especially considering that it's probably different for Bookmarkable vs non-bookmarkable content)
- the play position of bookmarked tracks

Suggested changes:
1) for track types for which Bookmarking is enabled, Properties > Details should show 'Bookmark:' and display the current position. User can delete it if desired.
2) In Options > Playback rules, add a setting (above 'Play Now' action) for:
Increase play counter at: _x%_

The default %'s should be based on the current algorithm (I'm assuming that the current algorithm is based on % e.g. 60% for non-bookmarked content / 95% for bookmarked content).
Additional Information
Tagsdoc_help, todoc
Fixed in build2505


related to 0011183 closedLudek MediaMonkey 4 Video isn't tagged as played if the last 2 minutes aren't watched 
related to 0011286 closedLudek MediaMonkey 4 Advanced search for Played# works only for integer values 



2021-04-29 11:05

developer   ~0062979

Implemented in build 2401. But note, that 2) is used only in case user presses "Previous" button, otherwise we increase playcounter only when finishing whole playback, as described in 0011183 comments.


2021-04-29 11:08

developer   ~0062980

Should we change play counter behavior? It probably does not have universal solution, as somebody wants to e.g. skip end titles and still have play counted, and others want to increase it after end of playback of the whole file.


2021-05-04 17:58

administrator   ~0063047

I don't understand the logic of not advancing the play counter once IncreasePlayCounterAt% has been hit--i.e. why should it advance only if the user presses PREVIOUS?

btw, the UI doesn't give any indication that such a restriction exists.


2021-05-05 17:22

developer   ~0063062

Play counter is increased when (Time played in session + Bookmark > 1 min.) or (Track Length < 3 min.) and:
1) track end was reached
2) Prev button was pressed, track position was > 5s (seek to the beginning of the track is done in this case) and track position was > percent of track length set (90% by default)

Skip counter is increased after pressing Next button, when (track position > 2s) and (track position < 30 % of track length)

Last Time Played is set after 5 minutes of playing


2021-05-20 02:34

administrator   ~0063309

The Play Counter logic seems incredibly confusing. I think that it would be much simpler/easier to understand if the play counter would increase when the track reached <%lengthforFileType> as long as (Time played in session + Bookmark > 1 min.) or (Track Length < 3 min.).

Re. Last Time Played: what happens if a track is < 5 minutes?

Note: whichever approach is taken, documentation needs to be updated.


2021-05-20 14:32

developer   ~0063318

Last edited: 2021-05-20 14:33

View 2 revisions

rusty: your suggestion of play counter logic is problematic in case of playing end of file in more playback sessions. E.g. video has 90 minutes, percent is set to 90 %. User plays 81 minutes, playcounter is increased... later on, user plays part 81-83min, play counter is increased again... than he plays 83-85min, play counter is increased again... I think this is the reason for current logic, count it only at the end of the file (or when skipping to the beginning from the end part).

Last Time Played is set after 5 minutes of playback or/and together with increasing play counter.


2021-05-20 14:35

developer   ~0063319

Another problem is described here:


2021-05-20 14:51

administrator   ~0063321

michal: re. the problem of increasing the play count multiple times when playback is spread over multiple sessions: I was trying to suggest that it should only increase once--at the moment that it passes the configurable threshold (currently that threshold is always at the end of the file and I'm saying that if the user configures a different threshold, then it should be at the configured threshold--at least that's what I think users would expect based on the current UI).

Leaving this as 5.0.1--but only for the documentation to be fixed. We'll look at this more closely for 5.0.2.


2021-05-20 15:09

developer   ~0063322

rusty: ok, so seek over the treshold back and playing over it again would lead to increase play counter again. But we can probably do nothing with this. The Peke's problem with setting as played before end could be fixed by setting trashhold to 100% for video files, if user wants to count it only at the end of the file. This probably makes sense.


2021-05-25 21:25

developer   ~0063484

Help documentation updated:


2021-09-22 15:30

developer   ~0064823

Play counter logic changed in build 2505. Now play counter increases when the track reached <%lengthforFileType> and ((Time played in session + Bookmark > 1 min.) or (Track Length < 3 min.)).
After testing please update documentation.


2021-09-23 20:53

developer   ~0064852

Verified on 2505, that it's implemented as stated. However I don't think MM should put constraints on the user setting. Thus the arbitrary 1 minute for files over the arbitrary 3 minute length should be removed in my opinion. If a user sets 10% it should always count at 10% playback.

If Bookmarking is enabled, it would still count at user set value. If playback is resumed past this point it wouldn't count again.


2021-09-23 21:14

developer   ~0064856

I agree with LowLander that the additional constraints should be removed.


2021-09-24 07:48

developer   ~0064858

I am not author of the conditions, assigned Rusty to decide.


2021-09-24 07:59

developer   ~0064859

I think it is problematic and has not ideal solution. After removing conditions - file 10 minutes, user limit set to 70 %. User starts playing file - seeks to 7:00 - play for 3s and stops. This will be counted as whole playback, even though user played only 3s from 10 minutes.


2021-09-24 09:32

developer   ~0064860

Yes, but that's expected. If user sets 70% for increase then it should be always increased at 70% despite the fact it was not played for 1 minute. Otherwise users will see it as bug.


2021-10-11 21:49

administrator   ~0065113

Last edited: 2021-10-14 17:09

View 2 revisions

I see both points of view. i.e. some users might consider the current approach a bug, and others might consider it a bug if playback for 3 seconds at the 70% mark bumps the counter. Many more people are likely to experience the current issue than the second one though. On the other hand, one could argue that the current Skip counter logic (only count a skip when playback for 2s has exceeded 30%).

So I'm inclined to leave it as is for now, and we can look at it again in the future if needed.

LL, the help still needs to be updated (please change the target to 3.1 and assign to me once you're done-thanks!).