View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003805 | MMW v4 | Now Playing | public | 2007-10-22 21:26 | 2022-04-29 01:31 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | feature | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 3.0 | ||||
| Fixed in Version | 3.1 | ||||
| Summary | 0003805: Increase playcounts differently for Music and Audiobooks/Podcasts | ||||
| Description | Raised at: http://www.mediamonkey.com/forum/viewtopic.php?t=20930 I would suggest that: -Podcasts/AudioBooks: should have fractional playcounts (e.g. .1, .2, .3, ... 1), and it never increases to 1 until it has been played in it's entirety once. -Music: should have binary playcounts; increment at 66% of a track | ||||
| Additional Information | http://www.mediamonkey.com/forum/viewtopic.php?t=25904 | ||||
| Tags | todoc-help | ||||
| Fixed in build | 1208 | ||||
|
|
I'm not sure, fractional counts would probably cause problems in several areas. That said, as I suggested in the forum post, it would possibly make sense to: 1. Increase Playcount for Audiobooks and Podcasts when the whole track is played (or more exactly when the end is reached). 2. Increase Playcount for Music when x% of track is played (where x=66 as in MM 2.5?). Question is, what to do if user configures Music tracks to be bookmarkable, maybe we would split the rules that 1. would be for bookmarkable tracks and 2. for non-bookmarkable? |
|
|
In bug 0004367 Ludek suggests taking the second approach that you suggest i.e.: 1a) For Tracks that match a filter that has bookmarking enabled: Playcount should be increased by 1 only after the track has completed (i.e. the current implementation). b) I think that _some_ means of indicating a partial playcount is important--e.g. if a user is looking at her podcasts, she should be able to determine which ones she's in the middle of. 2) For Tracks that don't have bookmarking enabled: Playcount should be increased by 1 after x% (hardcoded to 66% as in MM 2.5 until it becomes configurable) has played. |
|
|
A. Question is whether it would suit all users, I guess that for many (probably including me) the current approach of MM3 seems to work fine both for bookmarkable and non-bookmarkable tracks. Since it isn't clear how complex the related configuration should be, I would suggest to leave it as is and rather add a new scripting event, something where MM would tell the interested script: "Hey, track A has been just played for 2 minutes out of 3, do you want to increase playcount?". The whole thing would have to be a little more complicated, but this is the general idea - user would be able to install a script to maintain this in case it's really needed. B. Fractional playcount - it might be useful. One option would be to store integer playcount in DB (as we currently do), but show it increased by 'bookmarktime/totaltime' in tracklist. I'm just afraid that it would cause some confusion, e.g. if I have an auto-playlist 'playcount=0', does a track that has playcount=0.35 belong there? Maybe we can use some alternative solution. Fro example in case a track has bookmarktime>0, show some small mark in playcount column (e.g. a red corner like Excel does) which would show information about % played when mouse is over it. |
|
|
1A) I have no objection to making it scriptable, but I don't think that this really solves the problem for most people (since most won't install a script specifically for this purpose. B) Re fractional playcount indicator--I think that's the best idea yet. Based on this idea, how about: Short term solution (requires no new strings): -For all tracks: increase playcount by 1 only after the track has completed 1.a) for bookmarked tracks have a fractional playcount indicator. e.g.: ... 0 - not played ... 0+ - partially played ... 1 - played once ... 1+ - played once and partially a second time Also, as you suggested, the tooltip should show eg.: 33% OR 55% OR 1 + 66% Intermediate improvement: -Add the following config entry: ..Increase playcount after track has played: 95% Long term improvement--not sure if this is really necessary: -Add a configuration entries as follows: ..Bookmarked tracks: Increase play count after track has played: 66% ..Unbookmarked tracks: Increase play count after track has played: 100% |
|
|
A. My point was that in my opinion almost no user really needs to configure this. Then, the couple of users needing this can download a script - which seems to be better than to include a configuration for all users. B. Ok, looks good. I'm just afraid that showing '+' on the right side wouldn't look good, because the numbers there are right aligned (obviously). Having it on the left would be better. However, '+0' and '+1' probably aren't too clear either. So maybe the best would be to show '+' (or another symbol, possibly graphical) completely left aligned, i.e.: '+ 0' ' 0' '+ 1' ' 1' The tooltips could be slightly enhanced to show something like: '1 + 45% (0:58 out of 2:17)' |
|
|
A. No problem. My point is just that it may turn out that fixing B. will be sufficient for almost all users. B. + x makes sense for presentation purposes. And as far as a tooltip, your suggestion sounds good: e.g. 1 + 45% (0:58 out of 2:17), however, we should try to avoid introducing any new strings so possible strings would be: 1 + %d of %d (%s) -- %d of %d (%s) is an existing string 1 + 45% (0:58 / 2:17) -- this is just as good, I think |
|
|
Assigning to Ludek to implement B. as suggested, i.e. show tooltip using a mask '%d + %d of %d (%s)' (e.g. '1 + 0:45 of 1:58 (45%)') and showing left aligned '+' mark on partially played tracks. I'm just afraid that there's a small technical problem: We shouldn't show this for all tracks, only for bookmarkable ones. However, as far as I remember, we save bookmark info for all tracks, right? If so, we probably should change it and save bookmark info only for bookmarkable tracks (using filters as specified at the moment of end of track playback). Note: In case saved bookmark is very small (like <5 seconds?), I'd consider it to not be a bookmark at all and don't show it. Note 2: Related item is - do we re-start playback at the very location bookmark is set? If so, I'd suggest to change it so that we rather start some 3 seconds earlier (so that a short part is repeated again). |
|
|
B is implemented: 1. Re: Show tooltips -> tooltips are shown in the form '1 + 45% (0:58 / 2:17)', added 1186 2. showing left aligned '+' mark on partially played tracks -> I also think that this mark doesn't look well therefore I used '1.4' instead of '+1' (for the example track), added 1186 Re: We shouldn't show this for all tracks, only for bookmarkable ones. However, as far as I remember, we save bookmark info for all tracks, right? If so, we probably we should change it and save bookmark info only for bookmarkable tracks (using filters as specified at the moment of end of track playback). -> implemented 1186, but we will probably need to reset the bookmark position in DB also (via DB update), because tracks played so far have the position stored although they haven't been bookmarkable. Re: In case saved bookmark is very small (like <5 seconds?), I'd consider it to not be a bookmark at all and don't show it. -> implemented 1186 Re: Related item is - do we re-start playback at the very location bookmark is set? If so, I'd suggest to change it so that we rather start some 3 seconds earlier (so that a short part is repeated again). -> implemented 1186 |
|
|
Added also the DB update in order to reset the bookmark position for tracks that have been played so far, but were not bookmarkable. Added in 1186 too. |
|
|
verified 1199 |
|
|
There is a bug reported here: http://www.mediamonkey.com/forum/viewtopic.php?f=6&t=35296 "For example: One track is listed as being heard 4.7 times. After I continue to play it through the counter increases to 5.0. But after the next start of Media Monkey the counter shows 5.7. And it keeps continuing from the position I stopped playing it at the time the decimal values first appeared." |
|
|
Fixed in build 1208. |
|
|
verified 1223 |
