View Issue Details

IDProjectCategoryView StatusLast Update
0010454MMW v4DLNA/UPnPpublic2019-07-29 11:08
ReporterLudek Assigned To 
PriorityurgentSeverityminorReproducibilityalways
Status closedResolutionfixed 
Product Version4.1 
Target Version4.1Fixed in Version4.1 
Summary0010454: Playcount is not increased for auto-converted tracks sometimes
DescriptionIf you play tracks from MMW 4.1 server then Played# is not increased when the track is auto-converted. This worked fine in MMW 4.0
Additional Informationhttp://www.mediamonkey.com/forum/viewtopic.php?f=6&t=69764#p358451
TagsNo tags attached.
Fixed in build1625

Relationships

related to 0007837 closedLudek MMW v4 DLNA/UPnP: Play counter increases after a few seconds of playback 
related to 0015842 closedrusty MMW 5 Plays from DLNA Server not scrobbled 

Activities

Ludek

2013-01-25 18:36

developer   ~0034678

Fixed in 1623.

peke

2013-01-30 02:02

developer   ~0034726

Verified 1623

Ludek

2013-02-02 22:11

developer   ~0034749

Re-opened, this was not properly fixed:
http://www.mediamonkey.com/forum/viewtopic.php?f=6&t=69998

Fixed in 1624.

lowlander

2013-02-12 18:51

developer   ~0034866

Verified on 1624

lowlander

2013-02-13 16:53

developer   ~0034882

When playing on Android (tested with MMA and Skifta) playcounts don't get consistently updated (most tracks are missed).

Ludek

2013-02-13 17:25

developer   ~0034883

I can reproduce only if I play a track and skip the track in less than 1 minute.

MMA pre-buffers whole the file before playing and thus MMW is not sure whether to increase the PlayCounter or not.

The current politic is that it must buffers at least 90% of the file and the last increased time should be > 1 minute or the song length < 1 minute.
I know that it is a little bit tricky, but it is a result of several complaints when tracks were often double-scrobbled because some clients re-buffered them.

lowlander

2013-02-13 17:30

developer   ~0034884

I'm playing tracks completely through.

Ludek

2013-02-13 17:41

developer   ~0034885

Last edited: 2013-02-13 17:43

OK, it could be because of another prevention that I added because of 0007837:0028759

I will simplify the politic to just check whether the last song (for which Played# was increased) is different from the current song (for which the Played# is about to be increased).

It should fix the issue.

Ludek

2013-02-13 17:49

developer   ~0034886

Fixed in 1625.

peke

2013-05-05 22:39

developer   ~0035930

Verified 1636