UPnP playback: changes in NP list are mis-handled

[mcow]

Build 335, Android 4.2.2

Start a playlist of eight tracks from MMW UPnP server. Let tracks play. During track 4, dragged the track entry to the end of the NP list. Track 4 completes; Track 5 starts up, unexpectedly. Pause player.

Go to MMW. Track History shows tracks 1,2,3,4,7 have been played (not track 5, nor the final track #8 ).

Scrobble history also shows tracks 1,2,3,4,7.

[mcow]

Similar behavior:

Load a ten-track playlist from UPnP; tap the second track to start playing.
Track 2 completes; then Track 1 starts. Check MMW: only Track 2 marked as played.
Let track 1 complete; then Track 2 starts again. Check MMW: Track 2, 1, 3 are marked played.
Skip track 2; track 3 starts. Check MMW, still shows 2, 1, 3.
Let track 3 complete; track 4 starts. Check MMW: shows Tracks 2, 1, 3, 5 marked as played.

This alternating behavior continues: overall play order is 2 1 2 3 4 5 6 7 ...
History is updated as 2, 1, 3, 5, 4, 7, 6 ...

[mcow]

Some of this—the changes in the playlist not taking effect as expected—may be bug 12315.

The out-of-order setting of last-played and scrobbling is, I guess, an MMW bug. I think that may happen even if the UPnP list is played straight through without modifying, but I haven't had a chance to verify that yet.

[rusty]

Hi mcow,

As you guessed, there are bugs that are similar / related to what you're describing--including others besides the one you noted:
1) http://www.ventismedia.com/mantis/view.php?id=12315 (re-ordering tracks in Now Playing is broken in some cases)
2) http://www.ventismedia.com/mantis/view.php?id=12333 (play history/play counter is inaccurate--note: this is probably the root of scrobbling issues)
3) http://www.ventismedia.com/mantis/view.php?id=12320 (playback stops after x tracks and restarts)
We'll probably have to fix these various local playback issues before we can figure out if there are any play counter issues specific to UPnP.

-Rusty

[mcow]

As you guessed, there are bugs that are similar / related to what you're describing--including others besides the one you noted:
1) http://www.ventismedia.com/mantis/view.php?id=12315 (re-ordering tracks in Now Playing is broken in some cases)
2) http://www.ventismedia.com/mantis/view.php?id=12333 (play history/play counter is inaccurate--note: this is probably the root of scrobbling issues)
3) http://www.ventismedia.com/mantis/view.php?id=12320 (playback stops after x tracks and restarts)
We'll probably have to fix these various local playback issues before we can figure out if there are any play counter issues specific to UPnP.

All three of those bugs are marked fixed, but 341 is behaving like this, very similar to what's described above:
Tracklist 1-9
Playback stops after track 6 because wi-fi not kept awake. Playlist rewound to track 1. Track 1 did not play.

Scrobble history: 1, 2, 3, 4, 6, 5, 1
MMW history shows last six tracks 2,3,4,6,5,1

[rusty]

Yes--this is definitely a different issue. But if I understand correctly, the root cause is tracked at http://www.ventismedia.com/mantis/view.php?id=12301

-Rusty

[rusty]

Can you confirm whether this is fixed for you in build 353+ (to be posted within 24hrs).

Thanks.

-Rusty

[mcow]

OK: with MMA 1.1.0.0358, playing back from MMW 4.1.5.1719.

Ten tracks. During playback of an early track (A? or B?), I deleted track D. Transition from C to track E occurs with no problem. While E is playing, drag track H to between E and F. Transition from E to H to F is no problem. While F plays, drag it to the end of the list.

At the end of the track, the scrubber bar comes to a stop at 100% (0:00 remaining), and the Pause button keeps looking like a Pause. Clicked once, it changed to Play, but then returned to Pause. It seems that no further actions are available for a while (minutes, while I was typing the above), including clicking on the Notification. But after that time period elapsed, MM was responsive again.

EDIT: I'm not sure if that was the amount of time needed to play tracks G I J

MMW history shows A B C E H F, which is correct
Scrobble history shows A B C F E H F. I have no idea how that first 'F' got scrobbled, it seems completely out of order.

Log sent: 44BMIP2J8E.

[rusty]

Hi mcow,

I just realized that I may have been misunderstanding you. When you're talking about the scrobble history, are you referring to the scrobble history from MMA (i.e. MMA is running the last.fm scrobbler) or from MMW (i.e. MMW is using the scrobbler addon)?

I originally thought the former, but now I'm wondering if you meant the latter (in which case the problem is due to caching and the fact that UPnP doesn't communicate playback status between client and server).

-Rusty

p.s. MMA build 374 does have a problem scrobbling tracks played over UPnP (using the Simple Last.fm scrobbler for android).

[mcow]

I just realized that I may have been misunderstanding you. When you're talking about the scrobble history, are you referring to the scrobble history from MMA (i.e. MMA is running the last.fm scrobbler) or from MMW (i.e. MMW is using the scrobbler addon)?

Scrobble history is what's been scrobbled. My understanding is that MMW is doing the scrobbling when it serves up the track to UPnP.

I'm also seeing problem with inaccurate scrobbles as performed by MMA from local storage, but that's not this problem.

p.s. MMA build 374 does have a problem scrobbling tracks played over UPnP (using the Simple Last.fm scrobbler for android).

What? I thought MMA did not scrobble at all when playing from UPnP.

[mcow]

I just tested this, again, with build 381.

From the MMW UPnP server, I cued up tracks A-E. While A was playing, I selected a track X from the NAS server with Play Next, so the playlist was:
A X B C D E

These songs played in order, so the problems reported in this thread did not occur. When all the tracks had played, MMA returned to the idle state correctly.

After X played, while B was playing, I looked at last.fm. It showed that I had played A and C.

When all the tracks had completed, last.fm showed: A C B D E. It should have been A B C D E.

[rusty]

When all the tracks had completed, last.fm showed: A C B D E. It should have been A B C D E.

Shouldn't it have shown: A X B C D E ?

Regardless, it sounds as if the problem that you're describing is what is discussed at:
http://www.ventismedia.com/mantis/view.php?id=12524
(the fact that MMA pre-caching of UPnP tracks results in incorrect play history/play stats in MMW).

As to whether MMA should scrobble play history for UPnP tracks--I think that it should (see: http://www.ventismedia.com/mantis/view.php?id=12517 ). That'll be fixed in the next build. If you go with the client-based scrobbling (rather than via the UPnP server) you'll avoid the errors inherent to the server-side approach. Just remember to disable 'Update play counter for items played over UPnP/DLNA' if you go with this approach.

-Rusty

[mcow]

When all the tracks had completed, last.fm showed: A C B D E. It should have been A B C D E.

Shouldn't it have shown: A X B C D E ?

No, because MMA doesn't scrobble from UPnP. Yet.

Regardless, it sounds as if the problem that you're describing is what is discussed at:
http://www.ventismedia.com/mantis/view.php?id=12524
(the fact that MMA pre-caching of UPnP tracks results in incorrect play history/play stats in MMW).

Yes, that's it. Thanks for the url.

As to whether MMA should scrobble play history for UPnP tracks--I think that it should (see: http://www.ventismedia.com/mantis/view.php?id=12517 ). That'll be fixed in the next build. If you go with the client-based scrobbling (rather than via the UPnP server) you'll avoid the errors inherent to the server-side approach. Just remember to disable 'Update play counter for items played over UPnP/DLNA' if you go with this approach.

I am very glad to hear this part, and am looking forward to it. It's been long desired.

[mcow]

As to whether MMA should scrobble play history for UPnP tracks--I think that it should (see: http://www.ventismedia.com/mantis/view.php?id=12517 ). That'll be fixed in the next build. If you go with the client-based scrobbling (rather than via the UPnP server) you'll avoid the errors inherent to the server-side approach. Just remember to disable 'Update play counter for items played over UPnP/DLNA' if you go with this approach.

"If you go with this approach" -- is that supposed to mean there's an option? It appears, in 385, that if you have scrobbling on at all, then you have scrobbling on for UPnP. Is that right? I'm fine with that, just asking to be sure.

[Lowlander]

that if you have scrobbling on at all, then you have scrobbling on for UPnP.

That's terrible and should be reversed immediately, if true.