Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
madattack opened this issue Jan 6, 2017 · 46 comments

Comments

@madattack
Copy link

commented Jan 6, 2017

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

This comment has been minimized.

Copy link

commented Jan 29, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Jan 29, 2017

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

This comment has been minimized.

Copy link

commented Feb 11, 2017

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

This comment has been minimized.

Copy link

commented Feb 11, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Feb 12, 2017

@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

This comment has been minimized.

Copy link

commented Feb 12, 2017

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

This comment has been minimized.

Copy link

commented Feb 12, 2017

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

This comment has been minimized.

Copy link

commented Feb 12, 2017

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

This comment has been minimized.

Copy link

commented Feb 13, 2017

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 comment has been minimized.

Copy link

commented Feb 18, 2017

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

@prustage

This comment has been minimized.

Copy link

commented Feb 22, 2017

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

This comment has been minimized.

Copy link

commented Mar 14, 2017

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

This comment has been minimized.

Copy link

commented Mar 17, 2017

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

This comment has been minimized.

Copy link

commented Mar 20, 2017

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

This comment has been minimized.

Copy link

commented Mar 21, 2017

@unbehagen

This comment has been minimized.

Copy link

commented Mar 23, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Mar 23, 2017

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

This comment has been minimized.

Copy link

commented Mar 23, 2017

@sundown94

This comment has been minimized.

Copy link

commented Mar 29, 2017

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

This comment has been minimized.

Copy link

commented Mar 29, 2017

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

This comment has been minimized.

Copy link

commented Apr 3, 2017

It looks like this issue was identified and fixed in the GMusicProxy project - gmusicproxy/gmusicproxy@972acc4
gmusicproxy/gmusicproxy#75
I suppose the same thing could be done in the LMS?

@BachaudioDK

This comment has been minimized.

Copy link

commented Apr 8, 2017

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

This comment has been minimized.

Copy link

commented Apr 19, 2017

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

This comment has been minimized.

Copy link

commented Apr 19, 2017

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

This comment has been minimized.

Copy link

commented Apr 19, 2017

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

This comment has been minimized.

Copy link

commented Apr 19, 2017

@Riddlr

This comment has been minimized.

Copy link

commented Apr 19, 2017

Good catch! I must need more coffee - thx

@Riddlr

This comment has been minimized.

Copy link

commented Apr 20, 2017

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

This comment has been minimized.

Copy link

commented Aug 22, 2017

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

This comment has been minimized.

Copy link

commented Aug 27, 2017

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 gmusicproxy/gmusicproxy#75. Installing GMusicProxy + the patches in this thread resolved the issue for me.

@peterboehm

This comment has been minimized.

Copy link

commented Sep 16, 2017

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

This comment has been minimized.

Copy link

commented Nov 2, 2017

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

This comment has been minimized.

Copy link

commented Nov 8, 2017

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

This comment has been minimized.

Copy link

commented Nov 8, 2017

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

This comment has been minimized.

Copy link

commented Nov 9, 2017

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

This comment has been minimized.

Copy link

commented Nov 9, 2017

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

This comment has been minimized.

Copy link

commented Jul 15, 2018

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

This comment has been minimized.

Copy link

commented Jan 15, 2019

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

This comment has been minimized.

Copy link

commented Feb 20, 2019

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

This comment has been minimized.

Copy link

commented Feb 25, 2019

@madattack

This comment has been minimized.

Copy link
Author

commented Feb 25, 2019

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

This comment has been minimized.

Copy link

commented Feb 25, 2019

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

@technarf

This comment has been minimized.

Copy link

commented Mar 13, 2019

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

This comment has been minimized.

Copy link

commented Mar 16, 2019

@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

This comment has been minimized.

Copy link

commented Mar 16, 2019

@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

This comment has been minimized.

Copy link

commented Aug 4, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.