PDA

View Full Version : Spotty on Rpi3 / Very slow



philosopher
2018-03-07, 09:08
So, I've set lms 7.9.1 on rpi3 (I've tried on raspbian, ubuntu mate, osmc, no difference).
Added Spotty, which is ridiculously slow though.
I have to wait 10 seconds between the songs (connecting... buffering... etc).
Once it starts playing, there are no dropouts/hicks.
Skipping to next song takes ages though.

Network is ethernet and super fast, so there must be something else I'm missing.
Hardware on rpi3 should be enough to run this easily, any ideas?

mherger
2018-03-07, 09:46
> Added Spotty, which is ridiculously slow though.

You simply installed the plugin, didn't build it yourself?

> I have to wait 10 seconds between the songs (connecting... buffering...
> etc).

This sounds like networking issues. I know, your connection is fast. But
is your connection to Spotify, fast, too? Do you have any means to
measure the data throughput to your Pi when it does buffer?

> Hardware on rpi3 should be enough to run this easily, any ideas?

It's what I'm running myself. It definitely is fast enough.

--
--

Michael

Mnyb
2018-03-07, 09:46
And your internet connection?

Grumpy Bob
2018-03-07, 10:00
I have Spotty running on a Raspberry Pi3 with piCorePlayer/LMS7.9.1 and I find selecting albums, playlists, searching and so forth to be rather too slow to be usable. The Pi has a wired connection to the router, and download speed is generally pretty high. When playing, I don't see buffering, the problems are in slow browsing speed.

Robert

mherger
2018-03-07, 10:38
> I have Spotty running on a Raspberry Pi3 with piCorePlayer/LMS7.9.1 and
> I find selecting albums, playlists, searching and so forth to be rather
> too slow to be usable.

That would be a different problem. But anyway: what do you consider "too
slow"? How long does it take to eg. get Top Tracks, or New Releases?


--

Michael

philosopher
2018-03-07, 10:50
> Added Spotty, which is ridiculously slow though.

You simply installed the plugin, didn't build it yourself?

> I have to wait 10 seconds between the songs (connecting... buffering...
> etc).

This sounds like networking issues. I know, your connection is fast. But
is your connection to Spotify, fast, too? Do you have any means to
measure the data throughput to your Pi when it does buffer?

> Hardware on rpi3 should be enough to run this easily, any ideas?

It's what I'm running myself. It definitely is fast enough.

--
--

Michael

Installed the plugin, did not build it.

Forgot to mention, when client is connected to Lms running on other machines, same network/internet access, everything is perfect. So there is something wrong with the pi. Maybe this double pcm/flac conversion is causing issues. I did not find anything hungry in resources though. Pi is running pretty much idle all the time.
Skipping track is painful though, almost unusable.
Too bad, the plugin is cool, nice work man.
I've used it in other machines, rocks big time. Something wrong with the pi though, I'll keep searching.

Do you have a guide for Lms installation on pi? Maybe some library missing/bad version?
I've basically followed this one
http://www.gerrelt.nl/RaspberryPi/wordpress/tutorial-stand-alone-squeezebox-server-and-player-for-bbq/

Thanks

Grumpy Bob
2018-03-07, 12:15
tbh - my old LMS was fitted with a better CPU and 2GB RAM running plain Debian.
Picoreplayer run in the limited RAM so compare my old lms with your setup is pretty ...

AFAIK ->You only get what you pay for..

Very true, so I'm not to troubled. Actually, it's when browsing albums and artists that it seems very slow. Playlists is a bit snappier.

Robert

slartibartfast
2018-03-07, 12:27
Installed the plugin, did not build it.

Forgot to mention, when client is connected to Lms running on other machines, same network/internet access, everything is perfect. So there is something wrong with the pi. Maybe this double pcm/flac conversion is causing issues. I did not find anything hungry in resources though. Pi is running pretty much idle all the time.
Skipping track is painful though, almost unusable.
Too bad, the plugin is cool, nice work man.
I've used it in other machines, rocks big time. Something wrong with the pi though, I'll keep searching.

Do you have a guide for Lms installation on pi? Maybe some library missing/bad version?
I've basically followed this one
http://www.gerrelt.nl/RaspberryPi/wordpress/tutorial-stand-alone-squeezebox-server-and-player-for-bbq/

ThanksI would just use max2play or picoreplayer. Much easier and lots of users in the forum.

Sent from my SM-G900F using Tapatalk

Man in a van
2018-03-07, 13:41
Do you have a guide for Lms installation on pi? Maybe some library missing/bad version?
I've basically followed this one
http://www.gerrelt.nl/RaspberryPi/wordpress/tutorial-stand-alone-squeezebox-server-and-player-for-bbq/

Thanks

In what way "basically followed"?


I have followed Gerrelt's blog for both LMS and Squeezelite installs on rpi3b without any problems.

I have also, in the past, run the spotty app from LMS, trouble free. I don't, however, now listen to Spotify so can't comment on that.

You should be aware that there may be a minor hiccup to be encountered when doing an update

http://forums.slimdevices.com/showthread.php?108744-Debian-packages-update-Possible-dpkg-failure

You might want to follow the Wiki instructions for Debian installs of LMS (referenced in the above link).

Ronnie

philosopher
2018-03-07, 23:11
In what way "basically followed"?


I have followed Gerrelt's blog for both LMS and Squeezelite installs on rpi3b without any problems.

I have also, in the past, run the spotty app from LMS, trouble free. I don't, however, now listen to Spotify so can't comment on that.

You should be aware that there may be a minor hiccup to be encountered when doing an update

http://forums.slimdevices.com/showthread.php?108744-Debian-packages-update-Possible-dpkg-failure

You might want to follow the Wiki instructions for Debian installs of LMS (referenced in the above link).

Ronnie

The guide assumes no missing dependencies, but socket::ssl was missing, along with a bunch of dependencies, so I've resolved them with usual update -f.
Thanks for the link for the deb pkgs, will check it.
Will also try max2play, as mentioned above.

General connection of rpi is good, I've ookled it with chromium.
Can't imagine it has trouble connecting only to Spotify, given other lms installations in the network have no issues.
Get's weird, really.

edwin2006
2018-03-07, 23:57
Spotty on rp3 with pcp, running fine

philosopher
2018-03-08, 14:32
Sooooo, tried Max2play, works noticeably better, around 5 seconds between skips.
Max2play does not seem to be my thing (how can I boot to console? lxde is awful), but anyway, I'll see if I can live with it.

So, max2play performs better, why is that?
Can anyone tell us what does the max2play automated installation run when installing squeezeboxserver?
It obviously does something that standard .deb deployment procedure misses.

slartibartfast
2018-03-08, 14:40
Sooooo, tried Max2play, works noticeably better, around 5 seconds between skips.
Max2play does not seem to be my thing (how can I boot to console? lxde is awful), but anyway, I'll see if I can live with it.

So, max2play performs better, why is that?
Can anyone tell us what does the max2play automated installation run when installing squeezeboxserver?
It obviously does something that standard .deb deployment procedure misses.Are you saying that skipping to the next song takes 5 seconds? I use max2play and skipping has no delay.

Sent from my SM-G900F using Tapatalk

philosopher
2018-03-09, 00:49
Are you saying that skipping to the next song takes 5 seconds? I use max2play and skipping has no delay.

Sent from my SM-G900F using Tapatalk

Yeap, that's what I'm saying.
Happens with both squeezebox touch & squeezelite.
Was 10 seconds with raspbian, so I should be happy now :/

It will play a playlist just fine, when a song ends the next one loads immediately.
But if you try to skip by hand, or choose a different playlist/song/whatever, you get the 5-6 second delay.

Dunno really what's going on, with all you people claiming it works fine.
Maybe a defect rpi? Though network is good, and other lms on local machines work perfect.

Mnyb
2018-03-09, 00:56
Try PiCore player its even faster than max2play much less overhead.

mherger
2018-03-09, 01:42
> Happens with both squeezebox touch & squeezelite.
> Was 10 seconds with raspbian, so I should be happy now :/

Running on pCP behind a slowish 10Mbps connection a skip usually takes a
bit more than one second here.

> It will play a playlist just fine, when a song ends the next one loads
> immediately.

In this case LMS will start buffering about 10s before the playing track
ends. Therefore you don't see the buffering.

> But if you try to skip by hand, or choose a different
> playlist/song/whatever, you get the 5-6 second delay.

Yeah, that's too slow. You could disable the PCM -> FLAC transcoding to
see whether this improves the situation?

--

Michael

d6jg
2018-03-09, 09:07
I am running piCorePlayer on a wired Pi3 as a dedicated LMS with FLACs on a NAS via NFS.
No issue with Spotty but I think I have found a limitation of the hardware.
If I ask LMS (via the web interface) to display "Albums with small artwork" it kills playback until the search has completed.
This is whether I am playing local FLACs or Spotify tracks.
No big issue though as its a rare thing to do.

Mnyb
2018-03-09, 09:42
I am running piCorePlayer on a wired Pi3 as a dedicated LMS with FLACs on a NAS via NFS.
No issue with Spotty but I think I have found a limitation of the hardware.
If I ask LMS (via the web interface) to display "Albums with small artwork" it kills playback until the search has completed.
This is whether I am playing local FLACs or Spotify tracks.
No big issue though as its a rare thing to do.

Make sure that items per page for the web-UI is the default 50 . Having 200 or so so that you can scroll a bit before selecting next page does have a performance impact .

mherger
2018-03-09, 10:00
> Make sure that items per page for the web-UI is the default 50 . Having
> 200 or so so that you can scroll a bit before selecting next page does
> have a performance impact .

And make sure you have decent storage media for your cache: when you're
browsing albums LMS will have to read all the images from the cache. If
you've got a cheap SD card, then this can be quite a bit of a bottleneck.

Oh... this could actually be a bottleneck for Spotty, too. I think the
helper is always storing the audio data temporarily to disk. By default
this would be /tmp, but on some systems it's LMS' cache folder, as /tmp
can be rather small.

What kind of SD card are you using?

Also make sure you enabled "high memory usage" for the database
(unrelated to spotty).

--

Michael

d6jg
2018-03-11, 14:34
Class 10 card. Items per page is 50.
Cache is here
https://uploads.tapatalk-cdn.com/20180311/03c7cb6d98ae0615c9c8bcbb05e26eeb.jpg


Sent from my iPhone using Tapatalk

philosopher
2018-03-14, 05:05
So, no solution found.
Flac/PCM setting on filetypes makes no difference.
Card is Samsung Evo 32GB.

System seems quite idle while streaming from Spotify (check image).
Connection is good (other local LMS works fine with spotty).
So, no clue, really.

24703

d6jg
2018-03-16, 07:54
> Make sure that items per page for the web-UI is the default 50 . Having
> 200 or so so that you can scroll a bit before selecting next page does
> have a performance impact .

And make sure you have decent storage media for your cache: when you're
browsing albums LMS will have to read all the images from the cache. If
you've got a cheap SD card, then this can be quite a bit of a bottleneck.

Oh... this could actually be a bottleneck for Spotty, too. I think the
helper is always storing the audio data temporarily to disk. By default
this would be /tmp, but on some systems it's LMS' cache folder, as /tmp
can be rather small.

What kind of SD card are you using?

Also make sure you enabled "high memory usage" for the database
(unrelated to spotty).

--

Michael

An update on this issue.

I didn't realise at the time but I had moved the Cache etc to my NAS within the piCorePlayer setup.
24722
This obviously has the benefit of making sure that all your Prefs are saved to the NAS and allows you to easily recover from an SD card corruption but there is this trade off which I have tripped over.
Something for other users to be aware thats all.

d6jg
2018-03-16, 08:02
Class 10 card. Items per page is 50.
Cache is here
https://uploads.tapatalk-cdn.com/20180311/03c7cb6d98ae0615c9c8bcbb05e26eeb.jpg


Sent from my iPhone using Tapatalk

@Pippin

iPeng is misreporting the location of the Cache etc - LMS is on piCorePlayer based Pi3 but the Cache & Prefs are on my NAS !!

See post above.

d6jg
2018-03-16, 08:04
@Pippin

iPeng is misreporting the location of the Cache etc - LMS is on piCorePlayer based Pi3 but the Cache & Prefs are on my NAS !!

See post above.

Actually I have realised that the piCorePlayer move Cache etc probably creates a symlink in which case iPeng is correct but it is misleading.

mherger
2018-03-16, 09:44
> Actually I have realised that the piCorePlayer move Cache etc probably
> creates a symlink in which case iPeng is correct but it is misleading.

Can you confirm that Settings/Information would report the same as iPeng?

And could you move the cache back to on-device, just to be sure the pCP
<-> NAS communication isn't the bottleneck you've been looking for?

--

Michael

d6jg
2018-03-16, 09:59
> Actually I have realised that the piCorePlayer move Cache etc probably
> creates a symlink in which case iPeng is correct but it is misleading.

Can you confirm that Settings/Information would report the same as iPeng?

And could you move the cache back to on-device, just to be sure the pCP
<-> NAS communication isn't the bottleneck you've been looking for?

--

Michael

LMS does report the same as iPeng

I will move the cache and advise but pretty sure it is the cause of the bottleneck. The Piís LAN is of course itís weak point being only 100mb and the bus is shared with the USB. I canít do the cache move today unfortunately.

d6jg
2018-03-20, 09:22
I built LMS onto some new (secondhand) hardware today.
An HP Microserver, AMD Turion(tm) II Neo N40L Dual-Core Processor, 2 cores with 8GB RAM and a 32GB SSD i.e. a very capable machine
OS is Vortexbox 2.4 hacked about a bit and with Logitech Media Server Version: 7.9.1 - 1521043527
Music is still on my NAS (NFS mount) but Cache & Prefs are now on the SSD
Ran the "Find albums with small artwork" thingy and it still borked the playback but not for anywhere near as long as on the Pi.

@Michael.
Does the small artwork search read the music files or just the database / Cache ?

mherger
2018-03-20, 09:47
> I built LMS onto some new (secondhand) hardware today.
> An HP Microserver, AMD Turion(tm) II Neo N40L Dual-Core Processor, 2
> cores with 8GB RAM and a 32GB SSD i.e. a very capable machine
> OS is Vortexbox 2.4 hacked about a bit and with Logitech Media Server
> Version: 7.9.1 - 1521043527
> Music is still on my NAS (NFS mount) but Cache & Prefs are now on the
> SSD
> Ran the "Find albums with small artwork" thingy and it still borked the
> playback but not for anywhere near as long as on the Pi.

This is becoming rather off topic... neither Spotty nor Pi involved?

> Does the small artwork search read the music files or just the database
> / Cache ?

That process is super slow, as it first would query all tracks to find
the corresponding albums, then go read all artwork files for all those
albums to figure out the size. Then go query the album information for
that album if the size was as requested.

It could probably be better implemented. But it's nothing you'd run
regularly, therefore not representative for general LMS use. Or even
less so Spotty :-).

--

Michael

d6jg
2018-03-20, 09:53
> I built LMS onto some new (secondhand) hardware today.
> An HP Microserver, AMD Turion(tm) II Neo N40L Dual-Core Processor, 2
> cores with 8GB RAM and a 32GB SSD i.e. a very capable machine
> OS is Vortexbox 2.4 hacked about a bit and with Logitech Media Server
> Version: 7.9.1 - 1521043527
> Music is still on my NAS (NFS mount) but Cache & Prefs are now on the
> SSD
> Ran the "Find albums with small artwork" thingy and it still borked the
> playback but not for anywhere near as long as on the Pi.

This is becoming rather off topic... neither Spotty nor Pi involved?

> Does the small artwork search read the music files or just the database
> / Cache ?

That process is super slow, as it first would query all tracks to find
the corresponding albums, then go read all artwork files for all those
albums to figure out the size. Then go query the album information for
that album if the size was as requested.

It could probably be better implemented. But it's nothing you'd run
regularly, therefore not representative for general LMS use. Or even
less so Spotty :-).

--

Michael

Apologies for the threadjack

mherger
2018-03-20, 10:06
> Apologies for the threadjack

FWIW: that query is poorly implemented in that it doesn't give the
server time to "breath". LMS is basically cooperative multi-tasking: a
long running task can tell LMS to do some streaming every now and then.
I don't do this in that particular case. I probably should. But as I
said it shouldn't be considered a benchmark for overall LMS performance.

--

Michael

Gobuleberbu
2018-05-15, 22:01
Hi! I just wanted to give my feedback as well with version 2.33.

Starting a new song will take:
- regular song in lms : instant
- web radio: less than 1 sec
- spotty from Spotify: 6 seconds (current playing song stops 2 seconds after changing track followed by a 4 seconds gap)
- spotty from ipeng's interface: 6-10 seconds
-spotty from lms web interface : 4-12 seconds
Librespot from Spotify average 2-3 seconds but got as long as 12 seconds delay (instant when rewinding the song-the files are not cached)

- Pausing from ipeng, Spotify or the web interface: instant
- Resuming from ipeng, Spotify or the web interface: 0-3 seconds (variable)

Running on class 10 card on a raspberry pi 2. LMS 7.9.1 Increased memory usage enabled. Also, I do not have particularly interesting logs to communicate..

Thanks for your work!

beans
2018-09-15, 07:17
Hi all, I'm experiencing slow Spotty behaviour on Raspberry Pi as well. Thought I would post here with what I've found in case it can help

Setup details:
Server: Raspberry pi 2B (exclusively running LMS)
Clients: Raspberry pi zero w (x3)
OS: Raspian
LMS version: 7.9.2
Spotty version: 2.4.4
Client version: Squeezelite v1.8.6-957
Internal Network: Ethernet for server, WiFi for clients
External network: DSL 18Mbps line speed

Browsing and playing local files is almost instant. Internet radio plays within a couple of seconds (great). Official Spottify browses and plays almost instantly too.

I'm finding it takes about 10-20 seconds to navigate the Spotty menus (e.g. Open Albums). Interestingly, i have found it get slower the longer LMS has been running. After restarting the service menu load times go down to 2-4s (which is great). Leave it a day, and it goes slow again.

I tried the resize cover art options (as suggested by others) but it doesn't make a differnce to the load times.

It also takes about 10-30s to start playing a song (whether an intial load or skipping tracks). Reducing the Spotty bitrate to 160k shaves off a couple of seconds at the most. I wanted to go digging a little deeper into what's happening on the network, so fired up nload on the lms server and got the following graph when skipping a song
25629
This was recorded soon after restarting LMS so the speed is about as good as it gets.
It looks like there's a 10s delay between pressing play and anything happening on the network. Then (I guess) the song starts streaming from Spotify. 6s later LMS starts pushing the data to the clients and it plays almost immidiately.

Is this expected behaviour? Or is there something weird going on? Our internet connection here isn't great (18Mbs), but considering the official Spottify plays almost instantly, I gather it's specific to Spotty.

Any ideas? I'm happy to do more testing if I can help.

Cheers

mherger
2018-09-15, 08:05
Server: Raspberry pi 2B (exclusively running LMS)


What OS are you using? Could you be running low on memory? Can you watch "top" while you tart playing a track? Is it CPU, RAM or I/O bound?

beans
2018-09-15, 08:40
hey mherger,

Running Raspian. Memory looks fine. top says ther's 500BM free. So I guess not memory bound.

When I start playing a track squeezebox has around 12% usage with a brief spike up to 50%ish

25637

While the track is playing spotty-hf seems to be using between 3-15% with an occasional spike up to 50%ish too.

25636

So doesn't look CPU bound. It's never getting to 100% of a single core.

Disk IO wait time doesn's seem to go above 0.1. So I guess not disk bound either.

Which only leaves network bound I guess?

mherger
2018-09-16, 22:00
> Running Raspian. Memory looks fine. top says ther's 500BM free. So I
> guess not memory bound.

Agreed, nothing obviously wrong there.

> When I start playing a track squeezebox has around 12% usage with a
> brief spike up to 50%ish

Hmm... I wouldn't even expect LMS to do much work in this case. It
should mostly be spotty.

> Which only leaves network bound I guess?

Yes. But then why would it take forever in this case but no other issues
with other services? You're not running LMS in all wireless mode, aren't
you?

--

Michael

beans
2018-09-18, 19:31
What do you mean by all wireless mode? As in, the way the pi connects to the network? The server pi is connected via ethernet cable. The three clients are connected via WiFi (Pi ZeroW).

If I find a spare few hours I might try to build and debug the spotty plugin on the pi. Hopefully that'll point us in the right direction. Any tips for debugging? Looks like I use the docker image to build spotty and copy the binaries across to my installation? Owww. you're using Rust. Good excuse to learn a new programming language!

mherger
2018-09-18, 22:08
> What do you mean by all wireless mode? As in, the way the pi connects to
> the network? The server pi is connected via ethernet cable. The three

Ok, that's what I wanted to know.

> tips for debugging? Looks like I use the docker image to build spotty

"Looks like I use docker" - didn't you do this on purpose? If so, get
rid of docker and install LMS directly.

> and copy the binaries across to my installation? Owww. you're using
> Rust. Good excuse to learn a new programming language!

It's not my choice... I had no clue about Rust when I started
investigating Spotify options. But the project I'm using (librespot) is
written in Rust. Therefore I had to get my hands dirty and figure some
out :-)

--

Michael

thekman35
2018-09-22, 16:43
hey mherger,

Running Raspian. Memory looks fine. top says ther's 500BM free. So I guess not memory bound.

When I start playing a track squeezebox has around 12% usage with a brief spike up to 50%ish

25637

While the track is playing spotty-hf seems to be using between 3-15% with an occasional spike up to 50%ish too.

25636

So doesn't look CPU bound. It's never getting to 100% of a single core.

Disk IO wait time doesn's seem to go above 0.1. So I guess not disk bound either.

Which only leaves network bound I guess?

Just to confirm your findings beans, I'm seeing the same behaviour from my setup as well. It doesn't seem to matter what system the LMS is running (have tried Windows, Debian, Ubuntu, Raspbian).

While playing a song, I have analysed both nload and my router, and both seem to show the connection to the spotify server capping out at around 3Mbps. As each song is around 4.5 to 5MB in size, that would equal an 8-10 second wait before playing.

piguy
2019-02-28, 17:19
Did anyone find a solution to this?

I just set up a 3B+ running PCP and the Spotty plugin, wired to router with gigabit, but find Spotify Connect just as slow as others have described in this thread...