Comments (60)
from slimserver.
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...
from slimserver.
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.
from slimserver.
@mandoonandy sure, I mentioned it above, but this thread is becoming long..
#130 (comment)
it has a small proxy python file + a small change in the ProtocolHandler.pm file so it uses this proxy.
from slimserver.
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"
from slimserver.
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.
from slimserver.
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?
from slimserver.
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.
from slimserver.
@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?
from slimserver.
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.
from slimserver.
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
from slimserver.
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?
from slimserver.
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.
from slimserver.
This also happens to me frequently when playing podcasts (using the standard podcast plugin).
from slimserver.
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.
from slimserver.
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.
from slimserver.
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
from slimserver.
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.
from slimserver.
from slimserver.
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.
from slimserver.
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.
from slimserver.
from slimserver.
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. :-)
from slimserver.
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.
from slimserver.
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?
from slimserver.
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
from slimserver.
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.
from slimserver.
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?
from slimserver.
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!
from slimserver.
Good catch! I must need more coffee - thx
from slimserver.
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
from slimserver.
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.
from slimserver.
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.
from slimserver.
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.
from slimserver.
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).
from slimserver.
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?
from slimserver.
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.
from slimserver.
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$
from slimserver.
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.
from slimserver.
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 :-)
from slimserver.
from slimserver.
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!!!
from slimserver.
@huubbouma Thanks from me as well. The flask proxy works perfectly and the skips are gone!
from slimserver.
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.
from slimserver.
@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
from slimserver.
@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...
from slimserver.
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
from slimserver.
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.
from slimserver.
@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
from slimserver.
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..
from slimserver.
@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
from slimserver.
I just noticed that the problem I have is limited to my Squeezebox Touch, while my Radio plays the same song fine. Re-installing the firmware on the Touch didn't solve it.
Update: I have replaced the power supply on the SBT, which didn't fix it, then replaced the SBT. The new SBT doesn't have the issue.
Update 2: actually the new SBT does have the issue, too. Still suddenly skips to the next song. When it occurs the error is repeatable, playing the song again skips at the very same place. The issue is not Google Music-related, it happens when playing my music library. There are no issues when streaming with Spotty.
Update 3: Here is a video of an instance where it just stops playing. There is no longer sound, and the track timer moves in a loop from 0:31 to 0:36. This and the skipping to the next song are the two symptoms I observe. Before falling into the loop, it had already skipped to the next song in the middle of playing another song. So far the skipping and soundless loop have only occurred on .m4a files that were ripped from CDs with iTunes in 2011. The weird thing is, the same files, server and SBT have worked for years and suddenly I have these issues that make it practically unuseable.
from slimserver.
@huubbouma Your solution sounds a like a good interim fix. My family are about to force me to junk my current setup.
Would you be able to share your python proxy in a gist (or a repo)?
from slimserver.
I just noticed that the problem I have is limited to my Squeezebox Touch, while my Radio plays the same song fine. Re-installing the firmware on the Touch didn't solve it.
Update: I have replaced the power supply on the SBT, which didn't fix it, then replaced the SBT. The new SBT doesn't have the issue.
Update 2: actually the new SBT does have the issue, too. Still suddenly skips to the next song. When it occurs the error is repeatable, playing the song again skips at the very same place. The issue is not Google Music-related, it happens when playing my music library. There are no issues when streaming with Spotty.
Update 3: Here is a video of an instance where it just stops playing. There is no longer sound, and the track timer moves in a loop from 0:31 to 0:36. This and the skipping to the next song are the two symptoms I observe. Before falling into the loop, it had already skipped to the next song in the middle of playing another song. So far the skipping and soundless loop have only occurred on .m4a files that were ripped from CDs with iTunes in 2011. The weird thing is, the same files, server and SBT have worked for years and suddenly I have these issues that make it practically unuseable.
It seems to me that I have been able to fix this by changing the File Format Conversion Setup for AAC - AAC and for Apple Lossless - Apple Lossless to Disabled:
I am not sure what this does and whether it affects sound quality, but the skipping seems to have stopped.
from slimserver.
The proxy that @huubbouma created has been working perfectly for me.
I attempted to create a fix in a fork, but it appears to be causing an OutputUnderrun error when the player reaches the end of the song. There are several SMTt stat calls and then finally an SMTo:
[20-01-23 11:20:30.0055] Slim::Networking::Slimproto::_stat_handler (784) b8:27:eb:b9:90:f3: STAT-STMo: fullness=1086, output_fullness=-1, elapsed=87.519
[20-01-23 11:20:30.0057] Slim::Networking::Slimproto::_stat_handler (811) b8:27:eb:b9:90:f3 Squeezebox stream status:
event_code: STMo
bytes_rec_H 0
bytes_rec_L 3505631
fullness: 1086 (0%)
bufferSize 2097152
fullness 1086
bytes_received 3505631
signal_strength: 65535
jiffies: 9617337
voltage: 0
[20-01-23 11:20:30.0058] Slim::Networking::Slimproto::_stat_handler (823)
output size: 3528000
output fullness: 0
elapsed seconds: 87
[20-01-23 11:20:30.0059] Slim::Networking::Slimproto::_stat_handler (835)
elapsed milliseconds: 87519
server timestamp: 0
The basic concept is to spawn a thread to pull down the chunks into a queue to cache the song. If anyone wants to take a look, please feel free. The song finishes playing and the next in the queue does eventually start after about 5 seconds of delay. I'm not sure if where to go from here or if this is even a good solution.
https://github.com/kstunger/slimserver/tree/BufferingHTTP(s)
from slimserver.
I just noticed that the problem I have is limited to my Squeezebox Touch, while my Radio plays the same song fine. Re-installing the firmware on the Touch didn't solve it.
Update: I have replaced the power supply on the SBT, which didn't fix it, then replaced the SBT. The new SBT doesn't have the issue.
Update 2: actually the new SBT does have the issue, too. Still suddenly skips to the next song. When it occurs the error is repeatable, playing the song again skips at the very same place. The issue is not Google Music-related, it happens when playing my music library. There are no issues when streaming with Spotty.
Update 3: Here is a video of an instance where it just stops playing. There is no longer sound, and the track timer moves in a loop from 0:31 to 0:36. This and the skipping to the next song are the two symptoms I observe. Before falling into the loop, it had already skipped to the next song in the middle of playing another song. So far the skipping and soundless loop have only occurred on .m4a files that were ripped from CDs with iTunes in 2011. The weird thing is, the same files, server and SBT have worked for years and suddenly I have these issues that make it practically unuseable.It seems to me that I have been able to fix this by changing the File Format Conversion Setup for AAC - AAC and for Apple Lossless - Apple Lossless to Disabled:
![]()
I am not sure what this does and whether it affects sound quality, but the skipping seems to have stopped.
Thanks a lot Wapall
I'm using LMS 8 and was having horrible skipping problems with Tidal (recently signed up), was pulling my hair out. We have multiple hardware players (Boom, Radio) and software (SqueezePlay), multiple Wifi APs and everything was working well for years synced whole building music.... except with Tidal.
Disabling AAC seems to have worked ! Thanks!
from slimserver.
Keeping this thread alive, as I am suffering from this as well -- but (I think) mostly on SqueezePlayer on Android and (newest) SqueezePlay on Windows 10. FLAC only. Newest LMS 8.1.1 on Debian.
from slimserver.
After searching for a long time I found this thread. I am using Deezer plugin for streaming and songs stopped before their end.
I can confirm that disabling AAC format (seems) to work (for now). I will report back if things change.
LMS Version: 8.2.0 - 1627922070 @ Tue Aug 3 11:43:55 CEST 2021
Operating system: Debian (Docker) - EN - utf8
Platform Architecture: x86_64-linux
Perl Version: 5.32.1 - x86_64-linux-gnu-thread-multi
from slimserver.
It took me some time to find this thread too :)
I also use deezer plugin and was struggling with the problem that the playback of a track stopped around 50s before the end and jumped to the next track instead.
Disabling Fileformat AAC => Streamformat AAC seems to have fixed the problem for me as well.
LMS Version: 8.1.2
OS: Armbian 21.02.3 Focal with Linux 4.14.222-odroidxu4
Perl Version: 5.30.0 built for arm-linux-gnueabihf-thread-multi-64int
from slimserver.
After a few months of testing, I'm sorry to say that the problem persists. This is also the case with an adapted file format.
The more curious the problem, the more curious the attempts to solve it:
I use a VPN gateway (VPN client on Opensense Firewall to ProtonVPN) for communication to the Internet. Now I have adjusted the routing on my OpnSense firewall so that the LMS server does not use the VPN gateway and communicates directly with the ISP WAN gateway. All Squeeze players are set to "Proxy" so that the players receive the streams via the LMS.
=> Lo and behold, so far it works. I was also able to reproduce it. As soon as I enabled VPN again, the skipping at the end of a song also started again.
LMS Version: 8.1.2
Player: 10 x Seqeezeplayer (Max2Play)
OS: Armbian 21.02.3 Focal with Linux 4.14.222-odroidxu4
Perl Version: 5.30.0 built for arm-linux-gnueabihf-thread-multi-64int
from slimserver.
Related Issues (20)
- Erroneous Album Artists appear in Library Views HOT 9
- Feature request: Being able to control powerplug to switch on / off external amplifier HOT 1
- Analytics plugin: reporting delay is dependent on debug setting HOT 1
- Feature request : Plugin for SPOTUBE HOT 3
- Add WORK tag to additional browse modes plugin HOT 5
- Podcast plugin - audio not played if extensions (eg .mp3) not included in path HOT 1
- podcast plugin - cannot delete items from list (Version: 9.0.0 - 1714490454) HOT 1
- Albums erroneously labelled as "Various Artists" HOT 8
- Unable to jump to artist on SB Radio when playing songs via spotty
- Unable to jump to artist on SB Radio when playing songs via spotty
- I have a memory leak HOT 18
- LMS shows "New version available" but same version installed HOT 4
- Remote music library - don't show another LMS HOT 12
- Random Mix plugin repeatedly reverts to defaults HOT 4
- Update Massage still show the 8.5.2 is not installed HOT 2
- Playout stucks when a new Update or any Plugin is ready to install HOT 2
- Playlist stucks on first Track HOT 7
- Docker/8.5.2: Command Line Arguments not recognized? HOT 4
- Supporting Disc Subtitles (TSST tag) HOT 21
- How to uninstall from MacOS HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from slimserver.