View Issue Details

IDProjectCategoryView StatusLast Update
0007837MMW v4DLNA/UPnPpublic2019-07-29 11:08
Reporterpeke Assigned To 
PriorityurgentSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Product Version4.0 
Target Version4.0.1Fixed in Version4.0.1 
Summary0007837: DLNA/UPnP: Play counter increases after a few seconds of playback
DescriptionUsing 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 Informationhttp://www.mediamonkey.com/forum/viewtopic.php?f=6&t=61512
TagsNo tags attached.
Fixed in build1460

Relationships

related to 0008615 closedLudek MMW v4 Option to disable DLNA playcounts 
related to 0009335 closedLudek MMW v4 DLNA/UPnP Playback can cause double play counts 
related to 0010454 closedLudek MMW v4 Playcount is not increased for auto-converted tracks sometimes 
related to 0015842 closedrusty MMW 5 Plays from DLNA Server not scrobbled 
child of 0007086 closedLudek MMW v4 MM4: Played # increase When tracks are pplayed over DLNA/uPNP 

Activities

peke

2011-05-17 21:21

developer   ~0025375

Last edited: 2011-05-18 09:46

2. It looks that using WMP12 over DLNA there is no way to detect Skip Counter due the original issue explained above.

rusty

2011-11-02 06:24

administrator   ~0028574

This mucks up play counts significantly. Is an easy fix possible?

peke

2011-11-02 08:59

developer   ~0028579

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.

Ludek

2011-11-02 14:00

developer   ~0028580

Last edited: 2011-11-02 14:01

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.

peke

2011-11-02 17:52

developer   ~0028588

Last edited: 2011-11-02 17:54

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

Ludek

2011-11-02 19:51

developer   ~0028589

Last edited: 2011-11-02 19:53

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

peke

2011-11-02 19:57

developer   ~0028590

Last edited: 2011-11-02 20:44

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.

Ludek

2011-11-02 22:36

developer   ~0028595

Last edited: 2011-11-02 22:39

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.

peke

2011-11-03 01:11

developer   ~0028597

You are right that is even better, as it will be consistent with current increase PlayCount approach in MediaMonkey.

Ludek

2011-11-09 20:39

developer   ~0028759

Last edited: 2011-11-09 23:36

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.

Ludek

2011-11-09 20:55

developer   ~0028761

Fixed in build 1458.

lowlander

2011-11-10 05:08

developer   ~0028782

Last edited: 2011-11-10 23:36

It seems that 1458 is much improved, but on occasion duplicate scrobbling for DLNA played tracks still happens.

Ludek

2011-11-11 00:16

developer   ~0028817

Last edited: 2011-11-11 09:32

Fixed in 1460.

rusty

2011-12-14 22:44

administrator   ~0029462

Verified 1460.