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.

7931fbd3a782d584fb6f17ecd1a062c3660063fa (+ subsequent versions) has the issue, the parent commit 215357feaf8f9dbfbdcacd887819648a9c9a7457 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: https://github.com/squeezebox-googlemusic/squeezebox-googlemusic/issues/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: https://github.com/squeezebox-googlemusic/squeezebox-googlemusic/pull/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

[unbehagen]

Could you please try this and let me know if it works? My theory is that Google Music closes the connection if the client reads the file too slowly. I'm trying to work around this by increasing the buffer sizes to pretty high numbers - if it works, a more sane value could probably be chosen. I don't completely understand how LMS proxies the stream to the client. If anyone knows more about this, I would be very happy to hear about this.

[sunshine52]

I tried it, and can report back more after some more testing. Here is what I did

1. added the bufferThreshold sub to the google music ProtocolHandler.pm and saved it.
2. turned on proxied streaming, and turned off crossfade etc.
3. restarted server.

Problem persisted when syncing 2 squeezebox touch boxes and one squeezelite

I added the b: parameter to squeezelite, de-synced it and it worked ok.

I resynced the squeezelite to other devices and the skipping came back to the sqeezelite too. .

i haven't tested the squeezebox touch devices without the squeezelite. But it may be that the buffer parameter is not resetting or is not making a difference. Can you call the sub from another routine in the protocol handler like get next track??

On Mon, Mar 20, 2017 at 8:15 AM, unbehagen [email protected] wrote:

Could you please try this https://github.com/squeezebox-googlemusic/squeezebox-googlemusic/issues/19#issuecomment-287623596 and let me know if it works? My theory is that Google Music closes the connection if the client reads the file too slowly. I'm trying to work around this by increasing the buffer sizes to pretty high numbers - if it works, a more sane value could probably be chosen.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Logitech/slimserver/issues/130#issuecomment-287742730, or mute the thread https://github.com/notifications/unsubscribe-auth/AZQjV6xFBxTrb7_qNhrv1cADcSoPjQKAks5rnm3KgaJpZM4LdOT_ .

-- Josh Barbanel [email protected]

[unbehagen]

This seems to support my hypothesis that all we have to do is somehow force LMS to read/buffer the whole file at once and then serve it bit by bit to the clients. From what I understand, it works, as long as all connected clients buffer enough of the data at once. Maybe this can be achieved without touching the clients by overriding some of the routines in the HTTP/HTTPS handler of the Google Music plugin. It should just read the whole file to memory and serve it in smaller chunks to the clients.

[mherger]

Have you tried enabling proxied streaming for your players? This would tell LMS to proxy the audio data, rather than stream to the devices directly. I would assume that this would grab more audio data quicker than the limited buffer on the device allows for.

[sunshine52]

I have proxied streaming turned on. I understand t hat if you have multiple devices synced it automatically uses proxied streaming.

On Thu, Mar 23, 2017 at 10:04 AM, mherger [email protected] wrote:

Have you tried enabling proxied streaming for your players? This would tell LMS to proxy the audio data, rather than stream to the devices directly. I would assume that this would grab more audio data quicker than the limited buffer on the device allows for.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Logitech/slimserver/issues/130#issuecomment-288729032, or mute the thread https://github.com/notifications/unsubscribe-auth/AZQjVwpLezyIrpeiiZJYfiVJenwD6gzHks5ronvigaJpZM4LdOT_ .

-- Josh Barbanel [email protected]

[sundown94]

OK, never mind. The problem is back, but only infrequently. So when it happens, I stop and re-start LMS and it seems to go away for a while (until the next day). Based on what I have been reading on this issue, I suspect that when the problem does occur, it is because LMS is unable to read/buffer the entire song before the URL times out. But I think the problem goes away when I get good network performance either through LMS, the RPi, or my provider. Maybe I should put an LMS restart into Crontab (to run everyday). Lastly, is it possible to reduce the bitrate from 320k to 160k in the GoogleMusic plugin so that the file size is smaller and easier to download prior to the URL expiring? If so, would I do this in the ProtocolHandler.pm file? I saw some references to bitrate in this file, but I suspect that this only "informs" LMS as to what Google Music is going to be sending it in the stream. I also probably have no idea what I'm talking about. :-)

[Riddlr]

I am using Logitech Media Server Version: 7.8.0 - 1395409907 and it is still an issue have tried the buffer tweak, but the issue persists... I have 2 touches and one radio that are synced... I didn't have an issue with the original version of the plugin - I just upgraded to this one as search wasn't working on the old... might have to switch back.

[Riddlr]

It looks like this issue was identified and fixed in the GMusicProxy project - https://github.com/diraimondo/gmusicproxy/commit/972acc49ce84d89ae66bfab1f1a8320c8c29ccf6 https://github.com/diraimondo/gmusicproxy/pull/75 I suppose the same thing could be done in the LMS?

[BachaudioDK]

I had similar problems with LMS 7.9.0 and 7.9.1

I use SOX for upsampling of my FLAC files, and I could see the skipping in my case was related to the SOX was enable for FLAC.

I think I solved it by copying the lates version of SOX + DLL´s into the folder: C:\Program Files (x86)\Squeezebox\server\Bin\MSWin32-x86-multi-thread

I used the sox-14-4-2.

Now I see no problems with skipping files anymore :) and SOX upsampling is still working!

Cheers Flemming Bach Denmark

[unbehagen]

I still wasn't able to completely fix the problems by increasing the buffer sizes. One of my five players would always buffer too slowly and the track would skip.

So I installed the latest revision of gmusicproxy from github and patched the ProtocolHandler.pm of Google Music Plugin to stream the mp3 from GMusicProxy (Replace the placeholders with your GMusicProxy ip and port):

# To support remote streaming (synced players), we need to subclass Protocols::HTTP
sub new {
        my $class  = shift;
        my $args   = shift;

        my $client = $args->{client};

        my $song      = $args->{song};
        my $streamUrl = $song->streamUrl() || return;
        my $track     = $song->pluginData('info') || {};

        my $url = $song->track->url;
        my ($id) = $url =~ m{^googlemusic:track:(.*)$}x;

        my $newurl = 'http://<GMUSIC PROXY IPADDRESS>:<GMUSIC PROXY PORT>/get_song?id=' . $id;

        my $sock = $class->SUPER::new( {
                url     => $newurl,#$streamUrl,
                song    => $song,
                client  => $client,
        } ) || return;

        ${*$sock}{contentType} = 'audio/mpeg';

        return $sock;
}

Make sure you use the HTTP protocol, not HTTPS. In the beginning of the file: use base qw(Slim::Player::Protocols::HTTP);

This completely eliminated all track skipping. However, with this method, seeking in tracks is broken.

To completely fix this problem, the following should work, I just don't have the time to implement it right now: Instead of streaming the track through GMusicProxy, which doesn't appear to properly support range requests, create a flask server that takes a URL as a request parameter (the real url of the mp3 on Google's servers). It downloads the file to memory (caches the last n songs), then serves it to the client. Ideally, this server is multithreaded and after retrieving the file can stream to multiple clients at the same time. Range requests have to be implemented (http 206 partial content). The URL passed to the flask server would have to be encoded using urlencode or base64. Most of what GoogleMusicProxy does isn't necessary as we already have this logic in place in the plugin itself. In the patch I just use it because it implements some of the necessary buffering logic so the tracks don't skip.

[unbehagen]

If anyone with some knowledge of the internals of slimserver reads this, I would very much prefer a solution that doesn't require any of these proxy shenanigans. Is there any way to force SlimServer to buffer the whole file to memory before playback?

[Riddlr]

Thanks unbehagen

I tried your changes and it works great except for when I sync players - once I do that I get a bunch of: Warning: stream failed to open [googlemusic:track:trackId]

in the LMS log and the following in the GMusicProxy Log:

Unknown command '%3E/get_song' or missing required parameter!

[unbehagen]

The %3E appears to be the problem, which is the “>” character. You probably left that in there when replacing the server ip/port in the code. It should look like this: my $newurl = 'http://192.168.0.1:9999/get_song?id=' . $id;

[Riddlr]

Good catch! I must need more coffee - thx

[Riddlr]

Quick update... to support using the proxy while direct streaming you have to change canDirectStreamSong:

sub canDirectStreamSong {
        my ( $class, $client, $song ) = @_;

        my $url = $song->track->url();
        my ($id) = $url =~ m{^googlemusic:track:(.*)$}x;
        my $newurl = 'http://<proxy ip (not 0.0.0.0 has to be directly addressable from the client)>:<proxy port>/get_song?id=' . $id;

        # We need to check with the base class (HTTP) to see if we
        # are synced or if the user has set mp3StreamingMethod
        return $class->SUPER::canDirectStream( $client, $newurl, $class->getFormatForURL($song->track->url()) );
}

In my case with hardware players song truncation was still happening on unsynced players using direct streaming...

[richardhenwood]

hi All,

I observe random skips with Mixcloud streams and GMusic tracks.

I don't expect the workaround with GMusicProxy to fix the issues I'm having with Mixcloud -- so are there any suggestions for a more general fix?

some details: I have tried enabling proxied streaming for the player, but the problem remains. I'm using LSM version 7.9.1~1499900819 on a raspberry pi 2. My player is squeezelite.staticcmp3 Squeezelite v1.8-589, static build, on a second RPi2

any suggestions greatfully received! best regards, Richard

[tmancill]

I just wanted to chime in and say thank you to @unbehagen and @Riddlr for the patches and for linking this back to the root cause discovered by @abusenius in https://github.com/diraimondo/gmusicproxy/pull/75. Installing GMusicProxy + the patches in this thread resolved the issue for me.