|
|
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. |
|
|
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. |
|
|
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 |
|
|
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. |
|
|
Note that MediaMonkey also doesn't submit Chromecast plays and for Chromecast clients don't scrobble at all. |
|
|
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). |
|
|
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). |
|
|
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. |
|
|
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. |
|
|
OK, per client config for scrobbling / playcounter (for the clients that cannot scrobble) makes sense IMO. Probably by introducint new "Playback rules" tab per client device: Assigned to Rusty for the wording review / suggestions. image.png (28,813 bytes) |
|
|
Ludek's suggestion makes the most sense, BUT I doubt that there will be more than a handful of users taking advantage of this. So my vote would be to limit the effort on this and just make a single config entry. e.g. [x] Update play count when playing remotely . [ ] Scrobble to last.fm if Scrobbling is enabled Question: if we implement this, should we also implement a similar option for Synchronization e.g. - on the last.fm panel: . [ ] Include plays by synced devices OR on each device profile: . [ ] Scrobble to last.fm if Scrobbling is enabled |
|
|
1) Implemented the UI, assigned to Michal to implement the scrobbling functionality.. Details discussed via IM.. 2) Options > last.fm throws error in 5.1 builds |
|
|
Regression 2) fixed in build 2804. |
|
|
Fixed in build 2805. |
|
|
I find it bit confusing that user needs to know to enable Last.FM in Server settings in order to scrobble remote plays. eg. Now we have: "Library -> Last.FM" settings and "Library -> Media Sharing -> Server settings -> Clients Tab -> Increase play count for remote plays + Scrobble to last.FM" Otherwise both bugs are Verified in 2805 Edit: I personally think that introducing new playback rules tab (0015842:0068183) would be good for various reasons. 1. It would be per client setting that users can customize if needed 2. We can use that same tab for future fixes and customization eg. like disabling/customizing playback (fade, gap), custom Metadata sending, ... |
|
|
I agree that some users might expect to see this functionality in the last.fm settings. But given the limited number of users that will be taking advantage of this, I wouldn't spend any more time on this until we see strong demand for it. It's probably a niche feature though, given that: - The segment of our users that use both Last.fm and UPnP is probably very small - Track counts over UPnP are not that accurate - Track counts may include other users that the library owner might not want to count |
|
|
Agreed Closing We can review this along 0016291 and 0014043 |
- Anonymous
