View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0013326 | MMW 5 | Playback | public | 2016-06-02 15:57 | 2016-06-12 12:17 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | minor | Reproducibility | always |
| Status | feedback | Resolution | open | ||
| Summary | 0013326: Skip count not updated as expected | ||||
| Description | When skipping a track (even after playing 3m17s of a 4m17s track--Missy Higgins-Where I Stood), the skip count is not updated (as verified by syncing the track), nor is the Play Count increased. As pointed out by a user, this doesn't seem to make sense since if the track is tagged with a Last Played date/time andSkipped, then either the Play Count or Skip Count should go up (one would not necessarily expect this on Pause--since the track's status is still in progress). Tested on a Huawei Y6 / Android 5, MMA 1.2.0, MMW 4.1.12. Strangely, MMW seems to be exhibiting the same behavior!? | ||||
| Additional Information | Reported at http://www.mediamonkey.com/forum/viewtopic.php?f=21&t=85027 | ||||
| Tags | No tags attached. | ||||
| Fixed in build | |||||
|
|
Some notes how this currently works in MMW: 'Skipped#' increases on the next [>>] button pressing while playback is in area "from 2 seconds to 3/10 of length of the track" as originally suggested by Jiri here 0006246:0019951 'Last Time Played' is updated after 5 minutes of playback (even if file isn't played fully) -- details in 0011183 'Played#' is increased (and bookmark reset) once either a) or b) happens: a) Track end is reached and condition [COND] is true b) Previous button [<<] was pressed while seek bar was > 90% and the condition [COND] is true (More details in 0011183) [COND] = (Time played in session + Bookmark > 1 min.) or (Track Length < 3 min.) So it is true that if a track is skipped in 2/3 of song length then: - Played# isn't increased - Skipped# isn't increased too But it seems that some users would like to see this configurable: http://www.mediamonkey.com/forum/viewtopic.php?f=21&t=85027#p423974 |
|
|
It seems that there are a couple of problems with the current implementation: a) it's hard for users to understand how it works b) it's counter-intuitive in some cases when a track is played but neither the Play Count nor Skip count go up c) different users have different expectations of how this should work d) Last time played can be updated even if a track hasn't played resulting in undesired sync rules (e.g. sync tracks that haven't been played in the last month removes tracks even though they haven't actually been played) With the above in mind I would propose that: a/b/c: Simplify things to the following model: |--Skip--|x%|-------|y%|Played| With default values of x%=30 and y%=80 and x="",y="" In the case of a non-bookmarked track: Skip + 1 if PlayPosition < x% or PlayPosition < x s Play + 1 if PlayPosition > y% or PlayPosition > y s -PlayPosition for Skips is calculated upon pressing Next, Stop. -PlayPosition for Plays is calculated upon termination, pressing Next, Previous, or Stop. In the case of content Type that's Bookmarkable: Skip + 1: If Playposition < x% or PlayPosition < x s. Play + 1: If Playposition > y% or PlayPosition > y s. -PlayPosition for Skips is calculated upon pressing Next, Stop. -PlayPosition for Plays is calculated upon termination, pressing Next, Previous, or Stop. Configuration: For bookmarkable content, the values are slightly different, therefore I propose 2 sets of configurations: Counters Skip +1 if < _30_% or < ___ s played Play +1 if > _70_% or > ___ s played Play +1 if > _90_% played or < ___ s remaining (bookmarked content) -Question: How to prevent uncontrolled stoppages from affecting skip counts? e.g. what happens when playback stops due to bluetooth connection termination (car turns off)--is that considered a 'Pause' in which case no calculation takes place? Or a 'Stop' in which case it impacts skips inadvertently? d) 'Last time played' is updated after Play +1 Note: I think that % is preferable to absolute values in seconds since it can apply to any kind of track (short or long), but I've retained absolute values since it might be preferred by some users. e) The same settings can be used in MMA and MMW. |
|
|
ok, so if I understand it correctly you are suggesting to make this configurable somewhere in Options, right? I think that the most accurate place for this is 'Options' > 'Player' > 'Playback Rules' where we already have various settings per track type so user can set up this individually for Audiobook and differently for Podcast (despite the fact whether bookmarking is enabled or not) Re the Skip+1 rules. Currently the skip is increased only when user performs the 'Next' action, because the 'Stop' doesn't necessarily mean that user is unliking the track. With this in mind (+ the above noted by you) -- I think that the current implementation (to perform this only on [Next] action) makes more sense. What about the current [COND] condition, are you suggesting to eliminate this condition? If yes, then it doesn't cover some unwanted situations like: Bookmark is 0.75 , user skips to 0.85 and let it finish => Played# is not increased!! So I guess it is worse than the current implementation (when Played# is increased on track end -- details 0011183:0037551 ). RE: d) 'Last time played' is updated after Play +1 I would be careful about this change, this was wanted change and discussed a lot in the past, see 0011183:0037318 and the Jiri's argue: "I play a long movie, but due to its length stop it in the half and finish it only few days later - when should the timestamp be updated? I'd prefer it being updated _both_ days, since I've seen a significant portion of the movie and it helps resuming the playback later, since I'll see the movie e.g. in 'recently played' playlist." |
|
|
Yes--the idea would be to make it configurable (and relatively simple). Putting the config in the playback rules could make sense--the only reason I didn't was because then it means that users have to configure this 8 times rather than once. Re. Skip+1 rules: I agree--it makes more sense for it only to skip on 'Next'. Re. the [COND], as long as the implementation matches what the UI indicates. i.e. if the UI indicates that Play +1 occurs when playback > 90%, then the user expects that as long as playback for the track in question has played for a certain duration and has crossed the 90% threshhold, then the counter should increase. As to what that duration should be, would it make sense if it was a percentage of the overall track duration? e.g. 5% of the track's duration up to a maximum of 3min. Let me know what you think. |
|
|
OK, despite the fact whether we would make it configurable per track type or not I guess that the config still belongs to 'Options' > 'Player' > 'Playback Rules', just in case of general config it would be placed below the "track type" configs, right? I guess that in the first iteration (and to simplify syncing this treshold with MMA) we could make it a general config (despite the fact whether track is bookmarked or not) with default value of 80%. Re. the [COND] : OK, we can probably try to eliminate this condition entirely and whenever the treshold is crossed, then increase playcount. This would be more compatible with UPnP/DLNA playcount increases (0007086, 0007837, 0010454), we just probably will need to prevent from situations when user likes a short scene of a film that matches the treshold and each watching of the scene would increase the playcount. Probably the played# shouldn't be increased for the same track for the time that equals the length of the track? |
|
|
Re. the [COND], I wasn't clear in my comment at 0013326:0044862: I'm not suggesting eliminating logic to ensure that watching/listening to a track in split sessions will still result in Play +1 without having a possibility of multiple Play+1 for each split session. I'm just suggesting that the logic used can be improved. More concretely, what I was trying to say is that we could use logic similar to what we already use, but tweaked a bit e.g.: If the user configured: Play +1 > _y%_ or > y s has played MM should only consider this to be true if: SessionDuration > 5% of TrackTime or SessionDuration > 3m Note: the condition doesn't really make sense if y is an absolute value in seconds (it only really makes sense for y%), so I wonder if perhaps we should get rid of y(s) altogether. i.e. Skip +1 if < _30_% played (for Next) Play +1 if > _70_% played (for Next, Prev, Stop) Play +1 if > _90_% played (bookmarked content)(for Next, Prev, Stop--on Pause it shows the % complete). |
|
|
a) I don't understand this: "Play + 1 if > _70_% played (for Next, Prev, Stop)" namely "for Next, Prev, Stop", how these actions could have an impact on it?? The increase happens once 70% is crossed (despite the action performed after that). Can you elaborate? b) yes, value in seconds doesn't make much sense, percentage seems better c) do we really need to differentiate between bookmarked and non-bookmarked content? I guess that default value about 80% would work good for all content types? If you prefer to differentiate then I guess we should make it rather per "track type" config like the other values (enable bookmark, crossfade etc.) d) I guess that "Skip +1 if < _30_% played (for Next)" wasn't an UI suggestion, right? Could you suggest the exact wording or mockup that should be used for these configurations? |
