View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0007837 | MMW v4 | DLNA/UPnP | public | 2011-05-17 21:13 | 2019-07-29 11:08 |
Reporter | peke | Assigned To | |||
Priority | urgent | Severity | major | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Product Version | 4.0 | ||||
Target Version | 4.0.1 | Fixed in Version | 4.0.1 | ||
Summary | 0007837: DLNA/UPnP: Play counter increases after a few seconds of playback | ||||
Description | Using WMP12 and you initiate playback using MM DLNA/uPnP Played counter is increased as soon as WMP starts to play track. The issue also occurs with PlugPlayer. Tested with 1376 and last.fm plugin 1.0.2.25 which detect Played counter increase as soon as WMP start playback. Mote: If WMP is on same PC as MM and withing few first seconds in case WMP playback is started from different PC. | ||||
Additional Information | http://www.mediamonkey.com/forum/viewtopic.php?f=6&t=61512 | ||||
Tags | No tags attached. | ||||
Fixed in build | 1460 | ||||
related to | 0008615 | closed | Ludek | MMW v4 | Option to disable DLNA playcounts |
related to | 0009335 | closed | Ludek | MMW v4 | DLNA/UPnP Playback can cause double play counts |
related to | 0010454 | closed | Ludek | MMW v4 | Playcount is not increased for auto-converted tracks sometimes |
related to | 0015842 | closed | rusty | MMW 5 | Plays from DLNA Server not scrobbled |
child of | 0007086 | closed | Ludek | MMW v4 | MM4: Played # increase When tracks are pplayed over DLNA/uPNP |
|
2. It looks that using WMP12 over DLNA there is no way to detect Skip Counter due the original issue explained above. |
|
This mucks up play counts significantly. Is an easy fix possible? |
|
The only way I can think of is to make internal delay timer that will recheck if WMP is still playing track and than increase counter allowing user to skip playback. |
|
The reasons are explained here: http://www.ventismedia.com/mantis/view.php?id=7086#c22182 Some clients pre-buffers the file, it means that 90% of the file can be buffered although user could abort the playback -> we cannot know what happens on the client side when the file is buffered (client can stop playback, pause playback, plays buffered file twice). We cannot do anything about it. |
|
As talked on IM Adding SKIP counter Detection Formula will fix False Play counter increase in most cases and add correct skip counter with exception where Client that buffers whole track stops/pauses playback of buffered track, due the fact that we can't know client playback state, but only track buffering requests for track playback start and measure time till next request. Example Formulated mathematically (Add "else if" if more combinations can happen). Buffer started X = 20:23:15 Buffered 90% B = True New Buffer requested Y = 20:28:16 Track length L = 300Sec ----- If (B and (Y - (10% of L) >= X)) Or ((X + (10% of L)) < = NOW) then Inc Play Else Inc Skip ----- EDIT: With adding 0008615 and fixing this we will cover 99% Playback cases |
|
Note that this is a partial "solution". It doesn't cover cases when: a) user pauses playback on the client side b) user stops playback on the client side c) when next track is not from MM server d) when WMP 'Play to' feature plays tracks from one MM server to multiple clients etc. i.e. this is rather a hack that I would rather defer or not implement at all |
|
As talked on IM I completely agree that this is hack. All apps observe same issue and whatever we decide we should try to limit false positives to minimum. Note: in a,b,c,d cases and after Last Requested Track length is passed and no new track is requested from MM Server two possibilities could be done e.g. Ignore Track (No Play/Skip Change I would prefer that one), Inc Play (Current behavior) Resetting Status to New for post 4.0 review. |
|
In addition the 10% isn't enough, user can skip a track in half of playback. To be consistent with current increase PlayCount approach in MediaMonkey, I would suggest to increase the playcount when there wasn't a request for another file in 1 minute from the same client (supposing the track is longer than 1 minute). But still the cases described above will not be covered. |
|
You are right that is even better, as it will be consistent with current increase PlayCount approach in MediaMonkey. |
|
After analzing the LowLander's logs there is really another problem, for one song (Id=252314) the Playcounter is increased 4 times in 4 seconds! I found this issue, it happens only for auto-converted tracks. They are auto converted on-the-fly and therefore the 90% of file (offset/size) is reached more times, because file size is growing. It is an easy and low risk fix. |
|
Fixed in build 1458. |
|
It seems that 1458 is much improved, but on occasion duplicate scrobbling for DLNA played tracks still happens. |
|
Fixed in 1460. |
|
Verified 1460. |