Anubis wrote:An additional idea came to me on how this situation could be handled better....
Could you do something a bit smarter by checking the expected play length of the song and have MM keep track of the elapse time between requests, and if the next request for the next song comes in significantly BEFORE the expected elapsed time of the current songs playing time, then don't update the play counter or last played fields.

That might be problematic as different devices might buffer the next track differently.

Having now used 1343 with my WD TV Live to play music, I can confirm that play counts and last played date are now updated.
Thanks.

Further to the skipping discussion, I have already experienced this with my WD TV Live. I skipped a track that I was listening to (for only 30 secs) that was 3 minutes long, and MM4 incremented the play counter and updated the last played field, even though I skipped it. [Not unexpected from the discussion above].

As implemented, I can live with this understanding and will limited my "skipping" of songs so that my stat's don't get too stuffed up.

An additional idea came to me on how this situation could be handled better....
Could you do something a bit smarter by checking the expected play length of the song and have MM keep track of the elapse time between requests, and if the next request for the next song comes in significantly BEFORE the expected elapsed time of the current songs playing time, then don't update the play counter or last played fields.

What is "significantly before", say if the song only played for 20% of it's play time or less, then assume the song was skipped.
This algorithm would have problems if a client buffered multiple songs at once. In this scenario, an extra tweak could be to not apply this algorithm if multiple requests come in in a "short period of time", say 5 seconds?

Just some thoughts.... I'm happy with the current implementation with my WD TV Live.

PS. Twonky Media Server is able to keep a playlist of last played tracks. Unfortunately I've never figured out how to get Twonky to send played tracks to last.fm.

Peke wrote:Added this to http://www.ventismedia.com/mantis/view.php?id=7086 so that we can investigate.

Ludek (from Mantis 7086) wrote: There are actually 2 other problems:

1) Some clients seek end of file for another reason than playback
-> this is resolved by increasing the play counter only if client requests portion at 90% of the file
2) Some clients pre-buffers the file, it means that 90% of the file can be buffered although user could abort the playback
-> we can hardly do something about it

My suggestion for the problem of pre-buffering and then canceling before it is played fully is.... why not set up an option for each "DLNA client" that says whether or not to increment the play count at all. This will then at least allow the user to control whether (all) "played" tracks are counted or not for each particular client. That way if a client does funny things, the user can turn it off from contributing to the play-count [and last-played] and not stuff their stat's up.

Ludek wrote:Fixed in build 1343

When can we get it.

An algorithm where any repeat requests made from the same source within file length times x being discarded would go a long way. x could be 1, but then you wouldn't account for pausing and possibly even buffering.

Just be aware that other media servers have had this problem in the past. Some clients, specially PS3 handling video, request the same file more than once. That means that MM should be intelligent enough to decide if a file has been read fully or not.

Added this to http://www.ventismedia.com/mantis/view.php?id=7086 so that we can investigate.

I hope so, including the option to submit to last.fm.

I've noticed the play count # and the last played date/time are NOT updated when playing music from the MM4 DLNA server using my WDTV Live DLNA client.
Is this something that will be corrected over time?