View Issue Details

IDProjectCategoryView StatusLast Update
0015842MediaMonkey 5Extensions frameworkpublic2021-10-20 00:31
Reporterlowlander Assigned To 
PriorityhighSeverityminorReproducibilityalways
Status assignedResolutionopen 
Product Version5.0 
Target Version5.0.3 
Summary0015842: Plays from DLNA Server not scrobbled
DescriptionWhen MediaMonkey serves files to DLNA/Chromecast clients the plays aren't scrobbled to last.fm. With MM4 MediaMonkey does scrobble DLNA playback.
Additional Informationhttps://www.mediamonkey.com/forum/viewtopic.php?f=32&t=99113
TagsNo tags attached.
Fixed in build

Relationships

related to 0007837 closedLudek MediaMonkey 4 DLNA/UPnP: Play counter increases after a few seconds of playback 
related to 0010454 closedLudek MediaMonkey 4 Playcount is not increased for auto-converted tracks sometimes 
related to 0008615 closedLudek MediaMonkey 4 Option to disable DLNA playcounts 
related to 0014043 feedbackmartin MediaMonkey for Android DLNA Playback: Playing using DLNA from MMW double scrobble 
related to 0008154 assignedpeke Last.fm plugin Ability to disable scrobbling for DLNA devices 
related to 0016291 newrusty MediaMonkey 5 Last.fm Scrobbler: support for radio streams and non-library files 
related to 0006597 closedmichal MediaMonkey 5 Integrate scrobbler into MM 
related to 0016713 closedmichal MediaMonkey 5 Play to devices other than the internal player fails to scrobble 

Activities

lowlander

2019-07-24 19:31

developer  

2186 last.fm UPnP.LOG (624,314 bytes)

michal

2019-07-29 11:40

developer   ~0054226

Rusty, please revise this request. I think, this is logically wrong - last FM script is bound to the MM5 player, it sends nowplaying info and scrobbles to lastFM based on MM5 player events. MM5 DLNA server can serve data to more clients, every client could have different lastFM account, some could use scrobbler, some not. I think this should not be feature of the server at all.

Ludek

2019-07-29 13:42

developer   ~0054229

Last edited: 2019-07-29 13:43

View 2 revisions

Note: If we decide to add DLNA scrobbling to MM5 too then it makes sense to make it customizable per client (like auto-conversions and shared content) already is. And probably also play counter and scrobbling should have separate checkbox? Also, the default for MM* family clients should be OFF.

rusty

2019-07-29 18:47

administrator   ~0054232

Last edited: 2019-07-29 18:49

View 2 revisions

I can understand both perspectives. i.e.
- Last.fm shouldn't be updated by the server because it's really something that should be managed by each client (different users/accounts; accuracy issues to to caching of partially played tracks)
- Last.fm should be updated by the server for remote devices used by the same user that the PC belongs to in the same manner that Playcounts can be updated for all remote clients (which they currently are by default). In fact the current default settings seem a bit strange that they track UPnP Play Counts (by default) but not last.fm scrobbles.

If we do implement this, as Ludek's suggested it probably also has ramifications for playcount handling over UPnP (0008615), since that currently doesn't support per-client rules, and it would make sense to implement both sets of functionality similarly. BTW, I'm not sure that it makes sense to have separate rules for play counts and scrobbling--It seems to me that a common approach could be used for both, especially since it wouldn't necessarily make sense to have scrobbling config in the MediaSharing dialog.

Possible approaches:

1) Simplest: Just modify the current implementation to support last.fm (in addition to UPnP). e.g.
Update play counter for items played over UPnP/DLNA --> Update database / play counts for items played over UPnP (this more generic wording applies better to last.fm)

2) Also modify the current implementation with custom rules. e.g. on the dialog

Media Sharing > DeviceName
-------------------------------------------------------------------
[UPnP/DLNA]
[ ] Customize for this device

[ ] Update database / play counts for items played over UPnP

rusty

2019-07-30 18:27

administrator   ~0054243

Last edited: 2019-07-30 19:08

View 3 revisions

3) The downside of 1) and 2) as pointed out by Martin is that if server UPnP playcounts/scrobbling is enabled, then remote clients playing this content may double-scrobble this. If 0014043 is implemented (it will give MMA the option to scrobble/or not content played from a remote server) then double scrobbles will be prevented, however, if the user prefers client-based scrobbling for server tracks, then Playcounts of the server-based tracks won't be updated.

So to cover that scenario, an alternative approach would be:
- Retain the existing wording of Update play counter for items played over UPnP/DLNA
- Add an option to [ ] Use last.fm (if enabled) to submit tracks played by UPnP clients
- Add the custom per-device rule for play counts

My preference is not to go with this third option because it probably only affects a small number of users, it's overly complex (last.fm UI must be split across two locations), and wording is necessarily clumsy. Note, though, that if 0014043 proves to not be technically feasible (and MMA is unable to disable scrobbling for playback of remote tracks), then we'll probably have to implement 3) since _all_ MMA clients that scrobble will likely be in a position where content will be double-scrobbled.

lowlander

2020-06-12 17:50

developer   ~0058523

Note that MediaMonkey also doesn't submit Chromecast plays and for Chromecast clients don't scrobble at all.

lowlander

2020-06-13 17:40

developer   ~0058543

To clarify, MediaMonkey 5 doesn't scrobble when Casting to DLNA and Chromecast Clients as well as not scrobbling when a Client plays from the Media Monkey Server (which MediaMonkey 4 did).

rusty

2020-06-14 03:54

administrator   ~0058546

OK, thanks. I've moved the 'Play to' issues to 0016713 since existing MM4 users (and any user) would expect that to work (unlike Serving content from MM5 in which the expectations are unclear and where the feature is technically problematic (since the server can't distinguish between plays and skips).

lowlander

2020-07-02 19:50

developer   ~0058738

Last edited: 2020-07-02 19:52

View 2 revisions

That's why an option in the Media Server settings to scrobble play can solve this. It's up to the user to enable and it can come with a warning that scrobbles could included skipped tracks and double scrobbles if client scrobbles too. If MMA has an option to exclude DLNA play from scrobbling we would have resolved it from a MediaMonkey environment.

An even better solution is to allow per client settings to override global play counter/scrobble settings so users can choose which clients count plays and/or scrobble.

Most hardware clients have no scrobbling capability, it's only in some App/Software clients that the client can scrobble and with Play To now scrobbling it will also be perceived as inconsistent by users that one method of DLNA playback scrobbles and the other doesn't.

lowlander

2021-04-12 16:27

developer   ~0062789

Note that MM5 also can't scrobble as a DLNA client (so neither MM5 Server nor MM5 Client can scrobble) as MM5 doesn't scrobble non-library files.