View Issue Details

IDProjectCategoryView StatusLast Update
0016977MediaMonkey 5Playbackpublic2021-10-14 17:09
Reporterrusty Assigned To 
PriorityurgentSeverityfeatureReproducibilityalways
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 Informationhttps://www.mediamonkey.com/forum/viewtopic.php?f=33&t=99743
https://www.mediamonkey.com/forum/viewtopic.php?f=33&t=100136
Tagsdoc_help, todoc
Fixed in build2505

Relationships

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 

Activities

michal

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.

michal

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.

rusty

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.

michal

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
or
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

rusty

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.

michal

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.

michal

2021-05-20 14:35

developer   ~0063319

Another problem is described here: https://www.ventismedia.com/mantis/view.php?id=11183#c37312

rusty

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.

michal

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.

lowlander

2021-05-25 21:25

developer   ~0063484

Help documentation updated: https://www.mediamonkey.com/wiki/WebHelp:Playing_Audio_Tracks/5.0#The_Play_.26_Skip_Counter

michal

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.

lowlander

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.

Ludek

2021-09-23 21:14

developer   ~0064856

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

michal

2021-09-24 07:48

developer   ~0064858

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

michal

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.

Ludek

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.

rusty

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!).