UPnP playback, wifi shuts down->current track skips [#12301]

[mcow]

Build 331. Android 4.2.2.
Playing from UPnP server, tracks playing for minutes at a time. Wi-fi finally shut down due to no user action, which has always been a problem for MMA. (UPnPlay, for one, keeps wi-fi alive when it's playing.)

What was unusual this time was, instead of playback stopping after the wi-fi dies (skipping thru unresponsive tracks until list is exhausted), playback skipped to the beginning of the next track and started playing. I wonder if this is due to gapless playback having preloaded the next track?

[rusty]

Thanks, I'm able to replicate this more or less. Tracked at:
http://www.ventismedia.com/mantis/view.php?id=12301

-Rusty

[mcow]

I never saw a crash as you describe at that bug report.
My UPnP list terminated early again, as with this report. During playback of six tracks, the wi-fi lost sometime prior to starting the seventh track; sixth track completed normally, seventh track did not play at all.

Just to be clear: in the first post of this thread, the problem I described was the playback: that was what had changed with 4.1.

But the real problem is MMA failing to keep the wi-fi alive during UPnP. I should be able to play from UPnP for more than 20 minutes without playback suddenly stopping; other players such as UPnPlay can handle that. And the bug report doesn't mention this at all.

[rusty]

Thanks--we actually came to the same conclusion when we discussed this internally. I've updated the bug accordingly.

-Rusty

[rusty]

Fixed in build 353. Can you confirm that it works for you?

Thanks.

-Rusty

[mcow]

It's not clear to me what might have been fixed.

I posted a log on Dec 22; AZ3SRGR7YI I'm pretty sure that was with build 359.
I had been playing from UPnP, and the wifi shut down during playback.

[rusty]

Thanks--looking into this again.

-Rusty

[mcow]

I finally got a chance to test the most recent fix (as of 368) using 381; the problem persists.

I started a UPnP playlist, put it to sleep, and didn't touch it again. In the fifth song, it suddenly advanced to the next track. I woke it up and the wifi was disconnected.

I sent a log: 406YT3I7NT.

I have to ask: are you guys even aware of this API? If so, are you using it?

[rusty]

Thanks. Re-opened.

-Rusty

[bhiefer]

I finally got a chance to test the most recent fix (as of 368) using 381; the problem persists.

I started a UPnP playlist, put it to sleep, and didn't touch it again. In the fifth song, it suddenly advanced to the next track. I woke it up and the wifi was disconnected.

I sent a log: 406YT3I7NT.

I have to ask: are you guys even aware of this API? If so, are you using it?

Thank you for the log. I will look at it. And thank You for the link ..we are already using this API...

[rusty]

Hi mcow,

This should be fixed in 392 (to be posted shortly). Can you confirm whether the fix works for you (I've never been able to replicate)?

Thanks.

-Rusty

[mcow]

I finally got a chance to try this in depth; I was able to play over UPnP (from my NAS) for over 50 minutes with no interruption.

This was for about nine tracks. I noticed that Simple Last.fm scrobbled the first five, then queued up the next four tracks' scrobbles. But the wi-fi remained connected the whole time.

Thanks for putting all the work into this! Now that UPnP can handle gapless and scrobble from the client, all my UPnP issues have been put down.

[mcow]

Regressed:

With build 595, I was playing tracks from MMW. After six tracks taking about 22 minutes, the playback halted at the end of a track. It did not skip forward to the end of the playlist but simply stopped at the beginning of the next track. I picked it up and looked: wifi had shut off.

[Peke]

Should be fixed in 596