View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0016977 | MMW 5 | Playback | public | 2020-09-30 20:24 | 2021-12-08 14:34 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | feature | Reproducibility | always |
| Status | closed | Resolution | reopened | ||
| Product Version | 5.0 | ||||
| Target Version | 5.0.2 | Fixed in Version | 5.0.2 | ||
| Summary | 0016977: Play status improvements | ||||
| Description | As 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 | https://www.mediamonkey.com/forum/viewtopic.php?f=33&t=99743 https://www.mediamonkey.com/forum/viewtopic.php?f=33&t=100136 | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 2525 | ||||
| related to | 0011183 | closed | Ludek | MMW v4 | Video isn't tagged as played if the last 2 minutes aren't watched |
| related to | 0011286 | closed | Ludek | MMW v4 | Advanced search for Played# works only for integer values |
| related to | 0016713 | closed | michal | MMW 5 | Play to devices other than the internal player fails to scrobble |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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 |
|
|
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. |
|
|
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. |
|
|
Another problem is described here: https://www.ventismedia.com/mantis/view.php?id=11183#c37312 |
|
|
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. |
|
|
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. |
|
|
Help documentation updated: https://www.mediamonkey.com/wiki/WebHelp:Playing_Audio_Tracks/5.0#The_Play_.26_Skip_Counter |
|
|
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. |
|
|
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. |
|
|
I agree with LowLander that the additional constraints should be removed. |
|
|
I am not author of the conditions, assigned Rusty to decide. |
|
|
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. |
|
|
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. |
|
|
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!). |
|
|
I am pretty sure that the current approach _is_ a bug. Imagine situation when user set it to 90%, seeks nearly to 90% to test whether it works => it does not work because he hasn't played the file for 1 minute !? Users are seeing this as a bug for sure (related to ticket # 3106) If we want this not to be a bug then we will need to add further config, e.g.: Increase play counter at: [ 90] % [x] Only when file was played at least for [60] seconds |
|
|
OK. Let's take the approach suggested by LL at 0016977:0064852 Aside: we may want to consider modifying the skip counter behavior so that it's based on the 'Increase play counter at' value as well (for the future). |
|
|
Fixed in 2519 |
|
|
Can you please clarify if Implementation is based on your suggestion 0016977:0065853 or as rusty pointed 0016977:0064852 as for me it behaves like you pointed at 0016977:0065853 which I prefer at over @lowlander suggestion at 0016977:0064852 as your UI makes more sense, NOTE Verified functionality in 2519 and it works no regression locted and bug can be closed after your review, while new bug should be opened to cover 0016977:0065853 and skip counter algorithm if you agree? |
|
|
The play counter is increased only when it cross the percentage value. i.e. with default setting to 90%: - seeking to 88% and let it play to 92% does increase the playcount - seeking to 92% and let it play to 100% doesn't increase the playcount And there is no longer the need to play the track for at least 1 minute to increase it. |
|
|
Re-openning, it now results in double-counting for tracks played over DLNA to an external player (on some specific DLNA clients) Ticket # 3137 , forum: https://www.mediamonkey.com/forum/viewtopic.php?f=30&t=100618 => Fixed in 2520 |
|
|
Verified 2520 My previous test case was wrong it works OK like pointed in 0016977:0065931 As I can't replicate user case it needs to be closed only after user confirms. |
|
|
Re-opened: Played# may fail to increase for songs shorter than 15 seconds with the default to set to 90% (Options > Playback Rules) Reported at https://www.mediamonkey.com/forum/viewtopic.php?p=490661#p490661 |
|
|
Fixed in 2522 |
|
|
Verified 2522 Tested both Music and video, various length and also going to sleep/hibernate. |
|
|
Based on [Ticket # 3208] there are still some examples of '7 seconds' tracks that may fail to increase playcount -- especially when the actual/real length is less than 7 seconds (e.g. due to crossfade settings etc.). Fixed in 2524 |
|
|
Verified 2525 Test note: to replicat eon 2524 Tracks must be 7s or less and have silence at start/end so that actual track is <7s |
