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 notifications@github.com 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 joshbarbanel@gmail.com

[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 notifications@github.com 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 joshbarbanel@gmail.com

[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.

[peterboehm]

I can confirm this problem for Deezer. Deezer is the only streaming plugin I use on LMS and the problem was definitely introduced with LMS 7.9. It doesn't occur at every song but often enough to be annoying. When it occurs, the last 10-40 seconds of a song get skipped.

[richardhenwood]

From some initial debugging, it looks like my problem is related to squeezelite. I am using a static build: Squeezelite v1.8-589 on armhf and a stream seems to stalls with:

[12:50:58.597070] faad_decode:414 error: 13 Maximum number of bitstream elements exceeded [12:50:58.597432] faad_decode:453 unable to decode further [12:50:58.597520] decode_thread:99 decode error

this looks like a known issue in faad, so i am hopeful a squeezelite build with newer libs won't have this issue.

[cfeitzin]

I can confirm this problem for Deezer. Deezer is the only streaming plugin I use on LMS and the problem was definitely introduced with LMS 7.9. It doesn't occur at every song but often enough to be annoying. When it occurs, the last 10-40 seconds of a song get skipped.<

I have the exact problem with Deezer but am running v. 7.7.6 on a Synology NAS. This combination had worked for a long time but the issue started to appear a couple of months back. Any hints would be helpful. Thanks.

Since so many different confiturations are affected I would suspect that there are network issues that cause this behaviour by LMS.

[cfeitzin]

Since streaming via phone or Google Chromecast Audio doesn't have these issues maybe there is a way to integrate a chromecast audio device as a source for LMS. I'm thinking of a stream from chromecast audio that could be picked up by LMS (like an internet radio stream).

[elfez]

The WaveInput/WaveInput for Linux plugins should in theory allow you to do that, though I've yet to try it myself.

As for this issue I'm not sure I quite follow: If the gmusicproxy can work around this issue why can't the same fix be included into this plugin?

[cfeitzin]

As for this issue I'm not sure I quite follow: If the gmusicproxy can work around this issue why can't the same fix be included into this plugin?

I'll try to understand what the gmusicproxy workaround is and how it could be included into the deezer plugin. Thanks.

[erdoukki]

The problem may also occur in Qobuz. It may also occurs qith a huge local library.

The problem can be quickfix by clearing the cache files, tested with the PicorePlayer and with a cutom installation based on debian squeeze OS.

You can test on debian packaged version with the the commandline logitechmediaserver-cleanup --cache. ot the perl version of the command line; cleanup.pl in the /usr/local/slimserver or anywhere you have it installed... Stop the service before, use the cleanup tool and then restart the service and take a new try. It will not get the cache bug being fixed, but it will get you a quick fix to get back your streams played correctly again ! You ll also get back a quick browsing with a huge library. The prefs and the library will not be cleared, but only the caching parts will be. The problems is really from the caching part then. The under bug still has to be deeper analysed.

here the snap from picoreplayer

tc@pCPStreamer:/usr/local/slimserver$ ./cleanup.pl --dryrun
Utilisation: ./cleanup.pl [--all] [--cache] [--database] [--filecache] [--prefs] [--logs]

Options de ligne de commande:

    --database     Supprimer la base de donn?es multim?dia
    --filecache    Supprimer le cache des pochettes, mod?les, etc.
    --prefs        Supprimer les fichiers de pr?f?rence
    --logs         Supprimer les fichiers journaux

    --cache   (!)  Nettoyer le dossier cache, y compris la base de donn?es de la biblioth?que multim?dia, les pochettes, etc.

    --all     (!!) Tout supprimer. S?lectionnez cette option si vous ?tes s?r de vouloir tout supprimer.

    --dryrun       Affiche les fichiers et dossiers devant ?tre supprim?s sans effectuer de nettoyage.

The command line to clear the cache itself

tc@pCPStreamer:/usr/local/slimserver$ ./cleanup.pl --cache

Suppression en cours cache...
-> /usr/local/slimserver/Cache

Suppression en cours some legacy files...

Red?marrez le Logitech Media Server pour appliquer les modifications.

tc@pCPStreamer:/usr/local/slimserver$ 

[tompdillon]

I had the skipping problem after I believe a perl upgrade which broke LMS 7.9.1 so I updated to the latest 7.9.2 build and perl was fixed but the annoying skipping to the next song started.

I used GMusicProxy with the help of code patches above from unbehagen and Riddlr.

Thanks!

I have Linux based server and problem was on both Squeezebox Touch and Boom clients.

[huubbouma]

I followed @unbehagen 's very helpful advice and created a tiny flask proxy server which takes care of loading the complete song in memory, and serving it in smaller chunks to LMS. (see fork: https://github.com/huubbouma/squeezebox-googlemusic.git)

I'm running this setup for a day now, and it works perfect (including seeking in tracks) although I would prefer a simpler fix without the need of a proxy.. I didn't go through the effort of automatically starting the helper proxy like e.g. the spotify plugin does. I just created a systemd service file which takes care of running the proxy. Also note that some parameters are hardcoded, but perhaps someone else wants to polish this :-)

[huubbouma]

my pearl knowledge is very limited but I think it's likely that caching the song in memory could work in the plugin itself.. or in LMS if you could force it to load the complete song as fast as possible (use a big buffer perhaps?)

However the problem annoyed me too much and using the workaround with the flask proxy (not the gmusicproxy) solves the issue completely and there are no side effects afaik.

Op ma 25 feb. 2019 21:57 schreef madattack notifications@github.com:

I still experience the same issues, also after updating to the latest squeezelite versions. Interesting aspect is that the issue does not occur when I listen to audiobooks via gmusic.

Isn't there any approach how to fix this either in LMS or in the gmusic plugin? I understand the work around using gmusicproxy but somehow this seems be a workaround with limited functionality as I understood.

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

[madattack]

thanks so much hhubouma! works like a charm. As kind of a newbie it took me some time to understand that I have to start the proxy.py manually. But nows its working!!!

[steffenheyne]

@huubbouma Thanks from me as well. The flask proxy works perfectly and the skips are gone!

[technarf]

Hi, Thanks @huubbouma for your fork. It was working really well but overnight, it doesn't work anymore. I don't know why... When I install the original plug-in, I have the end of track issue, and when I install your fork it doesn't work. I can navigate in google play, and when I launch a song, I have the coverart and informations working, but no sound at all... I have the following error in the log for each song : Slim::Player::Song::open (472) Warning: stream failed to open [googlemusic:track:.....]. Could you tell me what is wrong in my configuration ? The server is a 7.9.2 on a Raspberry Pi and I have a squeezebox duet, 2 squeezeboxes radios and a windows based player. All my devices are ethernet connected (no wifi). Excuse me for my english and thanks for your help.

[huubbouma]

@technarf Check if the proxy.py is running? Is your google account still working? I don't have any issue so I can't reproduce your issue

[technarf]

@huubbouma thanks for your response. The proxy.py was running and my google account was still working. But I was wondering why the repo we have to add (see the README.md) is the same as the original plugin... So maybe I haven't installed your fork correctly... After some install/uninstall the googlemusic plugin (not your fork) seems to be working without the skip so I don't want to break anything at this point... I'm wondering if this was related to sync functionnality... I will test in the future if my system becomes buggy... One more time, thank you for your help...

[davein2it]

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.

Fabulous - works here

[Wapall]

This problem has started bugging me, too. With LMS 7.7.6 and also 7.9.1 on Synology DS916+. It repeatably skips at the same place in a song and not during other songs.

I don't have the skills to implement the above fixes and might have to look for another solution unless this gets taken care of with a future update.

[ghost]

@Wapall Both 7.7.6 and 7.9.1 are very old Synology builds. Please update to 7.9.2 first and see if this issue persists. For more information about the 7.9.2 version, see the appropriate forum on Slimdevices: https://forums.slimdevices.com/showthread.php?108960-Synology-7-9-2-packages

[huubbouma]

The problem is that google music will stop the stream after some time so the application (LMS) needs to buffer the song before this timeout occurs. So forcing LMS to fill up the buffer would be a nice way to fix this issue, but I don't know if this is possible.

The workaround that works 100% is to use a proxy server between LMS and google music that takes care of downloading the song in one go and then delivers the song to LMS in the requested chunks of data.

The small proxy I wrote in python works fine, but you have to manually set it up, so it auto starts after a reboot. I know you can automate this because the spotify plugin does something similar but I couldn't be bothered to fix it. But I might look into it one day..

[Wapall]

@Wapall Both 7.7.6 and 7.9.1 are very old Synology builds. Please update to 7.9.2 first and see if this issue persists. For more information about the 7.9.2 version, see the appropriate forum on Slimdevices: https://forums.slimdevices.com/showthread.php?108960-Synology-7-9-2-packages

Thank you! I have just updated and yes, the issue does persist. In my case it is not related to Google Music, I am just playing from my own media library. I assumed that the thread is not Google Music related, as it isn't mentioned in the thread title, but I see now it's mentioned in the first post.

I don't see anything in the log, there are only two entries:

[19-10-24 10:58:46.8016] main::init (387) Starting Logitech Media Server (v7.9.2, 0027.1571226194, Wed Oct 16 14:24:12 CEST 2019) perl 5.024000 - x86_64-linux [19-10-24 10:59:29.8096] Slim::Utils::Misc::msg (1256) Warning: [10:59:29.8091] Image::Scale libpng warning: iCCP: known incorrect sRGB profile (/volume1/@appstore/SqueezeCenter/Slim/Plugin/DontStopTheMusic/HTML/EN/plugins/DontStopTheMusic/html/images/icon.png)

I am trying to play a .m4a Apple Lossless file, the file is not corrupted, I can play it fine in the Music app, and it has played fine on the Squeezebox for many years. I know that I have had the issue on 7.7.6, 7.9.1 and 7.9.2, but do not know whether it has been introduced with 7.7.6