LMS 7.9 randomly skips to the next song without finishing the one playing

[madattack]

Hi there,

out of nowhere since a couple of day I experience this same issue when using google music plug in. Random songs are not played until the end. LMS skips to the next track approx. 10 to 20 secs. before the end of the current song. I already tried a couple of things which did not help at all:

• reinstall of LMS 7.9
• reinstall of Google Music Plugin from github.com/squeezebox-googlemusic/squeezebox-googlemusic
• Update of gmusicapi to 10.1.0

I'm using a Raspberry Pi 3 as a server and squeezelite clients on Raspberry Pi B.

Any ideas what could be the reason?

[steffenheyne]

I observe the same thing since some weeks, but I can't say for sure if this didn't happen with an older LMS version. I update LMS every 2-3 months on average. My gmusicapi and Google Music Plugin I haven't touched for a much longer time (~1 year).
I'm running LMS "7.9.0 - 1479847212 @ Tue Nov 22"

[craigmaloney]

I've observed this happening when there's a network issue between the server and the client. Double-check that the network is giving you the full song and isn't getting interrupted.

[kettenbach-it]

Same problem here!
Running Logitech Media Server Version: 7.9.0 - 1482423225
gmusicapi 10.0.1
Google Music Plugin: latest version from github.com/squeezebox-googlemusic/squeezebox-googlemusic

I think my network is pretty stable (no wifi involved).
I happens at the end of every track.
So I don't think this happens by chance.

Didn't occur with older versions.

Where's the best point to start debugging?

[redlulz]

I am quite sure it is connected to the https support.

7931fbd (+ subsequent versions) has the issue, the parent commit 215357f however is fine.

May also be a problem with the plugin. The last time is has been updated was before LMS had https support.

[mherger]

@redlulz - thanks for this hint. I'm pretty sure there's a problem with the https support in some regards (eg. transcoding). But I don't know why this would cause a track to end a few seconds from the end, in particular as mp3 should not involve any transcoding. Are you seeing this issue with hardware players, too?

[kettenbach-it]

In my case it happens on hardware, as well as on software players:

• Logitech SB Touch Type: fab4, Firmware: 7.8.0-r16754
• MIPS 74K Processor with squeezeslave 1.2-365

It happens with each unsynchronized player as well with synchronized players.

For an unknown reason, the next track is pulled 60 seconds before the end of the current and 10 seconds later - ~50 secs before the end of the playing track - sbs switches to the new one:

Feb 12 09:36:40 sbs squeezeboxserver: [17-02-12 09:36:40.3901] Plugins::GoogleMusic::ProtocolHandler::new (36) Remote streaming Google Music track: https://r5---sn-4g57knsy.c.doc-0-0-sj.sj.googleusercontent.com/videoplayback?id=9f1bc3a63b7d02b8&itag=25&source=skyjam&begin=0&upn=mOJvPSCE_6g&o=10858210782842575827&cmbypass=yes&ratebypass=yes&ip=176.9.44.54&ipbits=0&expire=1486888684&sparams=cmbypass,expire,id,ip,ipbits,itag,mm,mn,ms,mv,o,pl,ratebypass,source,upn&signature=6A767A3F768D0E7135ABE642CEBB475FD94CE556.3D9F68779A8EFCE21BDB3BE6E676DFED2CC09089&key=cms1&mm=31&mn=sn-4g57knsy&ms=au&mt=1486888522&mv=m&pl=21

Feb 12 09:36:50 sbs squeezeboxserver: [17-02-12 09:36:50.0310] Plugins::GoogleMusic::Radio::commandCallback (472) [playlist newsong] master source:

The 60/50 seconds seem to be reproducable but the switch does not happen exactly at 50secs - could 49 as well as 52.

Changing the fading settings etc. doesn't change anything.

[kettenbach-it]

I checked if it's related to the https support:

In my case, the skipping happens with https as well with http.

Concerning this, I found out, that the mixing of protocols like the plugin does right now doesn't work: squeezebox-googlemusic/squeezebox-googlemusic#14
So the plugin in it's current state is buggy, but that's not the cause for the skipping.

There's a pull request already, but has it has not yet been merged:
squeezebox-googlemusic/squeezebox-googlemusic#16

[kettenbach-it]

Since this is really annoying, I did some serious debugging.

The reason for the skipping at the end of the track is Google sending a TCP-RST packet for an unknown reason.

After some time playing the stream, there's an unexpected reset package seen in tcpdump:

12:39:06.088699 IP 74.125.160.16.443 > 192.168.204.101.53852: Flags [R.], seq 2232732219, ack 637782516, win 242, options [nop,nop,TS val 901453210 ecr 79752128], length 0

The reaction of lms is correct: the StreamController-Source thinks the stream is over:

Feb 12 12:39:16 sbs squeezeboxserver: [17-02-12 12:39:16.9224] Slim::Player::Source::_readNextChunk (375) end of file or error on socket, song pos: 8699840
Feb 12 12:39:16 sbs squeezeboxserver: [17-02-12 12:39:16.9230] Slim::Player::Source::_readNextChunk (380) 00:04:20:23:a4:61 mark end of stream

=> The stream is considered as finished
=> The buffer runs out of data
=> SBS switches to next track

I have no idea, why google does this.
And I have no idea why google always does this after around 8-10MB of stream.

Is there something like a maximum file size using the MobileClient?

[kettenbach-it]

I tried gmusicproxy (https://github.com/diraimondo/gmusicproxy), a project which uses gmusicapi as well.
With gmusicapi I don't have this problem.
I'll try to figure out, how gmusicproxy does it.

[molobrakos]

This also happens to me frequently when playing podcasts (using the standard podcast plugin).

[prustage]

Fixed!

I had this too. In general it would jump to the next track after 1'58 although on certain days it would simply skip alternate tracks without playing them at all. I tried a fresh install, re-scan of the library, cabled the components (so there was no WiFi in the mix). None of these made any difference. I tried installing LMS and the index file on an SSD in case it was disk cycle lags that was the problem. I even moved a part of the library to SSD and re-scanned. Still no luck.

In the end it occurred to me that the only thing that had changed between everything working fine and the current disastrous situation was a recent series of LMS upgrades. So I uninstalled everything and went back to LMS 7.7. Now everything works fine!

Logitech seem to have broken the software for some people while upgrading. I am sticking with 7.7 until they can convince me this is fixed.

Edit: Reckon its worth noting what my configuration is: Logitech Media Server (was 7.9 now 7.7) on W10 driving Logitech Duet A/D converter over WiFi. I am using the Logitech PC client in IE 11.9 but when I had problems these were equally manifest in Chrome and the Logitech Android App so that seems to be irrelevant. I use IE simply because its the only web client that allows me to run Imguz Equalizer.

[sundown94]

Hey Everyone!
The prior post from user "prustage" says this problem was fixed by reverting back to LMS 7.7. For me, this did not seem to be an option. Not that I didn't try to revert back, but I had no success there because I discovered (after the fact of course) that versions of LMS prior to 7.9 don't easily work with Raspian Jessie, if at all. So, I was just about to start over with Raspian Wheezy in order to get LMS 7.7 installed, but then I decided to try one more thing: install the latest LMS 7.9.1 nightly. This final attempt did the trick for me....I am back up and running. To summarize, my final configuration is Raspian Jessie, LMS 7.9.1 (logitechmediaserver_7.9.1~1489384180_arm.deb), gmusicapi v10.1.1, and the latest Google Music plugin (along with the HTTPS change to line 5 in it's protocolhandler.pm file).

Just thought I would share the good news with everyone. Sorry if this is already old news, but I couldn't find this resolution documented anywhere.

[sunshine52]

Upgrade did not solve this problem for me.
I installed 7.9.1 (logitechmediaserver-7.9.1-0.1.1489743085.noarch.rpm) and I am still having no success. The tracks skip about 10 second before the end. I have so far been unable to resolve perl version issues when I trying to downgrade to LMS 7.7.6. I am running Fedora 24 with Perl version 5:22