nervoteso wrote:
> i'm on 7.7.2 (on ts119 qnap) should i update fw?
Sorry for late reply! I really don't know if that would help though! But
you could try anyhow!
/Anders
falolaf's Profile: http://forums.slimdevices.com/
falolaf wrote:
> I can't speak for everyone but it works for me since a couple of month.
> I'm on openSUSE 13.1 x64 with 7.8.0.
>
> /Anders
i'm on 7.7.2 (on ts119 qnap) should i update fw?
Touchx3,Boomx2,1 radio, 1 classic!Squeezebox Server 7.7.2 (Qnap ts-119)
---
nervoteso wrote:
> i stopped using triode spotify due to buffering issues on multiple
> players, does anyone know if the problem has been solved? i'm on 7.7.2
> thanks
I can't speak for everyone but it works for me since a couple of month.
I'm on openSUSE 13.1 x64 with 7.8.0.
/Anders
i stopped using triode spotify due to buffering issues on multiple
players, does anyone know if the problem has been solved? i'm on 7.7.2
thanks
Touchx3,Boomx2,1 radio, 1 classic!Squeezebox Server 7.7.2 (Qnap ts-119)
nervo
I've tried the test-2 and test-3 versions of the win32 helper app from
the main thread, and they haven't really changed the behavior I'm
getting when trying to stream to a Receiver: The first ~30 seconds of
each track plays great, then pausing starts happening about every 2 to 5
seconds. This goes
New test versions available in the attachment spotifyd-test2 on the main
thread. Please test and report back.
Triode's Profile: http://forums.slimdevices.com/member.php?userid=17
View this thread: http://forums.slimdevices
falolaf wrote:
> Hi,
>
> I have now tested the updated version but I still have the same
> behaviour unfortunately. After a while I get dropouts and then it starts
> to skip to next track. And then no sound at all but the players seem to
> indicate that something is playing. As soon as I unsync
Hi,
I have now tested the updated version but I still have the same
behaviour unfortunately. After a while I get dropouts and then it starts
to skip to next track. And then no sound at all but the players seem to
indicate that something is playing. As soon as I unsynchronize the music
continues
Triode wrote:
> Could people who are still experiencing playback issues when synched or
> on linux try the test versions attached to this post:
>
> http://forums.slimdevices.com/showthread.php?79706-Announce-Spotify-Premium-Plugin-(Beta)&p=783496&viewfull=1#post783496
>
> Please report back her
Could people who are still experiencing playback issues when synched or
on linux try the test versions attached to this post:
http://forums.slimdevices.com/showthread.php?79706-Announce-Spotify-Premium-Plugin-(Beta)&p=783496&viewfull=1#post783496
Please report back here or on the main thread. I
rod_hull wrote:
> Are you also running your LMS on 64-bit Linux? Could you maybe post also
> in the main thread? I haven't managed to get any traction by myself
> there!
Yes indeed! openSUSE 13.1 64-bit. I can post in the main thread also but
I'm not sure it improve the traction... :-)
I though
Are you also running your LMS on 64-bit Linux? Could you maybe post also
in the main thread? I haven't managed to get any traction by myself
there!
rod_hull's Profile: http://forums.slimdevices.com/member.php?userid=53725
V
rod_hull wrote:
> Does no-one else see these buffer underruns when using synchronisation
> to more than one Squeezebox (physical or squeezelite) when running on an
> x64 Linux LMS?
>
> I can't believe I'm the only one!
You are not alone! As soon as I try to synchronize the problem starts.
I ca
Does no-one else see these buffer underruns when using synchronisation
to more than one Squeezebox (physical or squeezelite) when running on an
x64 Linux LMS?
I can't believe I'm the only one!
rod_hull's Profile: http://fo
I just moved my LMS off a Raspberry Pi where streaming performance to my
Radio was great but the web UI and media scanning were slooow so I chose
another more powerful Linux box (an Acer Revo) running Ubuntu 13.10
64-bit hoping for increased performance of the LMS.
I never had any probs with this
I've been trying 2.3.0alpha on openSUSE 13.1 x64, with LMS 7.8.0.
I do still have some dropouts when synchronizing my wired Receiver with
my wireless Radio. The dropouts are not that frequent though but when it
starts it can skip a track or two. Then quite stable for a few tracks.
Will do more t
Triode wrote:
> Could you try the 2.3.0alpha version of the plugin available when you
> add: http://triodeplugins.googlecode.com/svn/trunk/testrepo.xml, to the
> repositories at the bottom of the plugin page.
>
> This includes the changed setsockopt with 524288 bytes. (which is done
> for all p
Could you try the 2.3.0alpha version of the plugin available when you
add: http://triodeplugins.googlecode.com/svn/trunk/testrepo.xml, to the
repositories at the bottom of the plugin page.
This includes the changed setsockopt with 524288 bytes. (which is done
for all platforms I'm trying to see
Just one further piece of information. I've run ss while streaming a
track from Spotify on both 2.6.32 and 3.2 kernels and it appears that
twice the memory is allocated by the 3.2 kernel for the same Send Queue
size, so the buffer's now filling up twice as quickly. So that explains
the behaviour w
Triode wrote:
> Hi - I can definitely avoid calling setsockopt - it is there to make the
> buffer larger than default on windows and old linux version which
> default to smaller versions.
>
> As you have diagnosed spotifyd is currently using the tcp send buffer as
> the main buffer for the str
Stevie P wrote:
> I've been having this problem too on Ubuntu 12.04, but I think I've got
> to the bottom of it.
>
> Using the ss utility with -m shows that the write buffer is limited to
> 68KB. The Linux stack is measuring the link speed at 2-4Mbps, which
> should be enough. However, with roug
I've been having this problem too on Ubuntu 12.04, but I think I've got
to the bottom of it.
Using the ss utility with -m shows that the write buffer is limited to
68KB. The Linux stack is measuring the link speed at 2-4Mbps, which
should be enough. However, with roughly 60-70ms RTT latency (it's
I have the same problem. I.e. stuttering sound when streaming Spotify
using Triode plugin on LMS 7.7.3 with a 1.5 Squeezelite client on a
Raspberry Pi.
LMS is running on Ubuntu Server 12.04 x64 with 3.2.0-32 kernel.
When I start a virtual Windows 7 machine on the Ubuntu Server, with LMS
and Tri
jcharbar wrote:
> I've made some progress with this. I put in a new ethernet adapter and
> it's working as expected. The original adapter is an nVidia onboard
> MCP61. It's obviously struggling with the duplex nature of the spotifiy
> plugin although I thought it should be able to handle it easil
I've made some progress with this. I put in a new ethernet adapter and
it's working as expected. The original adapter is an nVidia onboard
MCP61. It's obviously struggling with the duplex nature of the spotifiy
plugin although I thought it should be able to handle it easily. I
imagine it could be
tinmice wrote:
> How do I test this? Having same problems on 64bit 12.04.
You can run the following: cat
/proc/sys/net/ipv4/tcp_limit_output_bytes
It should output a number.
@tinmice - I've attached a lshw from my server (lists the hardware). Are
there any similarities to your server hardwar
Thanks for taking a look at this.
Triode wrote:
> Could you check if all linux cases have:
> net.ipv4.tcp_limit_output_bytes
>
> sysctl net.ipv4.tcp_limit_output_bytes
>
> I wonder if the presence of this in newer kernels is causing a problem
> (the helper definitely relies on using the tcp so
Triode wrote:
> Could you check if all linux cases have:
> net.ipv4.tcp_limit_output_bytes
>
> sysctl net.ipv4.tcp_limit_output_bytes
>
> I wonder if the presence of this in newer kernels is causing a problem
> (the helper definitely relies on using the tcp socket for buffering)
How do I test
Could you check if all linux cases have: sysctl_tcp_limit_output_bytes
sysctl net.ipv4.tcp_limit_output_bytes
I wonder if the presence of this in newer kernels is causing a problem
(the helper definitely relies on using the tcp socket for buffering)
jcharbar wrote:
> Triode,
>
> I tried out a similar test using an Arch x64 LMS and a Windows 7 LMS
> (both wired). I'm also using a different router: TWG870.
>
> Case 3a:
> Thompson TWG870 Cable Router.
> Wired Windows 7 LMS server. Wireless RPi client.
> Wireless Squeezelite client (position
Triode,
I tried out a similar test using an Arch x64 LMS and a Windows 7 LMS
(both wired). I'm also using a different router: TWG870.
Case 3a:
Thompson TWG870 Cable Router.
Wired Windows 7 LMS server. Wireless RPi client.
Wireless Squeezelite client (positioned upstairs from router. Signal
~90
I'm seeing the same problem with a wired Arch X64 server and a wireless
Squeezelite client running on a Raspberry Pi. I ran a few test cases to
try and narrow it down. I used iptraf to track data rates and ifconfig
to track packet loss.
Case 1a:
Cisco EPC2524 Cable Router.
Wired Arch x64 LMS ser
Triode wrote:
> Can you comment on what QoS you had on the router - why was this
> impacting spotify? Could it be that the new server OS version is
> interacting with this?
I'll have a look when I get home but it's the default settings on
Netgear wnr3500lv2 I would say...
I have no idea how th
As previously request, a pcap with associated log file can be found at
http://sdrv.ms/17TD4Tc - It's too big to upload here
I disable IPv6, which took away a lot of retransmits, but did not solve
the issue - I am on Ubuntu 13.04 64 bit (which seems to be the issue!)
falolaf wrote:
> Some notes from the past weeks struggle...
>
> Setting the server to a static IP had some impact but it's not a
> solution unfortunately...
>
> I have altered the settings in the router and if I disable QoS and WMM
> it's actually possible to listen to the wireless Radio but I
Some notes from the past weeks struggle...
Setting the server to a static IP had some impact but it's not a
solution unfortunately...
I have altered the settings in the router and if I disable QoS and WMM
it's actually possible to listen to the wireless Radio but I have not
been able to synchron
Triode wrote:
> This looks like a lack of network bandwidth to me - is the player used
> for the self test wired?
Hi Triode, thanks for the reply. The self test basically chooses the
wireless player every time, but when I try and pay through the wired
radio I still get buffering issues. I can't
clarkey wrote:
> I've attached a copy of my log from the start of the self test to the
> end.
>
> I have both a wired and a wireless player and have the same problem with
> both. I haven't tried a local player as my server is a headless
> installation.
>
> Really appreciate your help.
>
> Than
falolaf wrote:
> I have made one small change to my setup that seems to have big impact.
> I set a static IP in my server. Before I had a dynamic adress that was
> reserved to the server by the router.
>
> Anyway I have now played for a few hours without any dropouts or skip to
> next song.
>
I have made one small change to my setup that seems to have big impact.
I set a static IP in my server. Before I had a dynamic adress that was
reserved to the server by the router.
Anyway I have now played for a few hours without any dropouts or skip to
next song.
I will try this out for a coup
Triode wrote:
> Can you capture the log from the start of playback? Does it work for a
> local player or a wired player?
I've attached a copy of my log from the start of the self test to the
end.
I have both a wired and a wireless player and have the same problem with
both. I haven't tried a l
15110
I've attached my log from the start of self test to the end.
Really appreciate your help.
+---+
|Filename: spotifyd.log.gz |
|Download: http://forums.slimdevices.com/attachment.php?at
clarkey wrote:
> Hi guys,
>
> I'm a new user on here, so please bare with me. I have been using
> Triodes plugin on my Squeezebox server for sometime now, possible a just
> over a year. I was running a very old version of Debian which is no
> longer supported, and was still using old IDE drives.
Hi guys,
I'm a new user on here, so please bare with me. I have been using
Triodes plugin on my Squeezebox server for sometime now, possible a just
over a year. I was running a very old version of Debian which is no
longer supported, and was still using old IDE drives. I have since
upgraded the h
falolaf wrote:
> I have now also tested to install LMS 7.7.3 on my laptop also running
> openSUSE 12.3 and I have the same problem with that setup...
>
> I have here attatched a new log from my main server. A bit shorter but
> the same problem. No broken pipe though. Now only one player.
>
> In
I have now also tested to install LMS 7.7.3 on my laptop also running
openSUSE 12.3 and I have the same problem with that setup...
I have here attatched a new log from my main server. A bit shorter but
the same problem. No broken pipe though. Now only one player.
In the end of the log one song i
Mnyb wrote:
> Well if works ocer cable and not wifi , thats a starting pioint.
>
> Afaik the spotify plugin translates the stream to a lossles flac ( or
> wav depending on server settings ) . So can uou play a lossles local
> file to the offending player , not only mp3 ?
> Is rhe server wired to
Well if works ocer cable and not wifi , thats a starting pioint.
Afaik the spotify plugin translates the stream to a lossles flac ( or
wav depending on server settings ) . So can uou play a lossles local
file to the offending player , not only mp3 ?
Is rhe server wired to the network it should be
Triode wrote:
> This looks to be a network problem to me. You have two players which
> are synced and the plugin streams to them ok until they both
> disconnect:
>
> I don't see any other errors suggesting the OK is causing the problem -
> are you sure the network is ok? Are there any errors i
falolaf wrote:
> Hi,
>
> I have now attatched three files with a spotifyd log. From the beginning
> of a listening session until the music starts to skip and drop out. Hope
> these contain anything that can help finding the problem.
>
> /Anders
This looks to be a network problem to me. You ha
Hi,
I have now attatched three files with a spotifyd log. From the beginning
of a listening session until the music starts to skip and drop out. Hope
these contain anything that can help finding the problem.
/Anders
+---+
|Filenam
Triode wrote:
> This debug looks ok as the rate is always above the target rate of 44100
> - the stream should only stall when it falls below this. [you will
> always get can't write as there is a finite buffer for the socket]
Thanks Triode! I probably didn't copy the best part of the log then.
falolaf wrote:
> Hi,
>
> Sorry to "reopen" this thread but did anyone find a solution to these
> dropouts? I have just assembled a new server and installed openSUSE
> 12.3. I have one Radio, connected wireless, and one Receiver, connected
> with wire.
>
> My wireless Radio is useless with Spot
Hi,
Sorry to "reopen" this thread but did anyone find a solution to these
dropouts? I have just assembled a new server and installed openSUSE
12.3. I have one Radio, connected wireless, and one Receiver, connected
with wire.
My wireless Radio is useless with Spotify while my wired Receiver work
Annoying. When I tried the spotify plugin on the 12.2-server, it
suddenly works... I will try it a couple of times more to see if it
stops working, and provide the logs.
/Hans
hansg's Profile: http://forums.slimdevices.com
Sorry for the delay.
I have made two new files with "sysctl -a | grep wmem"
The 11.4 version is the working one
15001
15002
/Hans
+---+
|Filename: tcpparams_11.4_wmem.txt |
|Download: http://foru
I have these problems as well using 3rd party Spotify in LMS 7.8 under
Ubuntu Server x64.
I have all wired Squeezeboxes, 3 Radios and one Duet synced.
The weirdest thing is that some listening sessions it works absolutely
flawless(for as long as the playlist is), but the next time I want to
use
hansg wrote:
> Ok, made two files wit "sysctl -a |grep tcp"
>
> opensuse 11.4 (works)
>
> 14976
>
> opensuse 12.2 (doesn't work)
>
> 14977
Could you try |grep wmem?
Also can you get a logging dump from spotfyd with logging set to Stream
Debug for both cases at the start of the remote stream
Ok, made two files wit "sysctl -a |grep tcp"
opensuse 11.4 (works)
14976
opensuse 12.2 (doesn't work)
14977
+---+
|Filename: tcpparams_12.2.txt |
|Download: http://forums.slimdevices.com/att
The self test fails on the last of the 5 tests on opensuse 12.2 and
debian 7.1.0
It passes on all tests on opensuse 11.4
I'm not sure on how to check tcp parameters, but this is in opensuse
12.2:s sysctl.conf:
kernel.sysrq = 0
net.ipv4.ip_forward = 0
net.ipv4.tcp_syncookies = 1
net.ipv6.conf.all
hansg wrote:
> Well, now I installed an opensuse 11.4 virtual client on the same
> machine, installed the latest LMS and the Spotify plugin, and everything
> works perfectly.
>
> So, something has happened with the networking from 11.4 to 12.2 that
> has this effect. And it isn't just opensuse,
Well, now I installed an opensuse 11.4 virtual client on the same
machine, installed the latest LMS and the Spotify plugin, and everything
works perfectly.
So, something has happened with the networking from 11.4 to 12.2 that
has this effect. And it isn't just opensuse, the latest debian server
(
I just tested the above trick of installing a debian server in a virtual
machine, but I get the same error as with my opensuse installation, so
it seems to be someting else.
I will try with an older opensuse (11.4 for example) and see if there's
any difference
--
I'm still at a loss with this problem - if anyone can get a wireshark
trace of the problem case compared to an earlier kernel then I will look
at it but I've not been able to find what could cause the problem...
Triode's Pr
Just wanted to add that I have the same problem since I upgraded from
opensuse 11.4 to 12.2.
Any client that sits on the wireless network stutters and eventually
fails (skipping to the next song), but on the wired network everything
works fine.
Any idea on how to solve this without downgrading t
Hi all,
Just to add to the diagnostics, I have the same issues on a newly
installed version 13 Ubuntu server, 64bit processor and 4Gb RAM so no
hardware related performance issues should be being experienced.
I hope that helps!
Jon
-
ncannings wrote:
> Just to eliminate network issues, I installed a clean debian install
> into a VirtualBox running on my main LMS. I then installed the Spotify
> plugin, connected my Squeezebox and started streaming... And I had no
> issues at all. It is a tiny little VM running on a much larg
Just to eliminate network issues, I installed a clean debian install
into a VirtualBox running on my main LMS. I then installed the Spotify
plugin, connected my Squeezebox and started streaming... And I had no
issues at all. It is a tiny little VM running on a much larger box that
splutters its
I have just resurrected my squeesbox's after a change to my network and
have come across the same issues described here - it stalls on the
spotify test app and playback is skipping alot!
altruizine, was it purely the OS that fixed yours?
I have tried ubuntu server 10.04 and 12.04, both are stut
dasjoen wrote:
> There is no firewall/NAT. It is, however, a Netgear WNDR3700 v3 with a
> DD-WRT alpha build, so that could be the reason... ;-)
I just reinstalled the original firmware. Same problem... :-(
What could make the transition between LAN/WLAN not work?
Julf wrote:
> And I assume you have checked that there is no firewall or NAT active on
> the WLAN router?
There is no firewall/NAT. It is, however, a Netgear WNDR3700 v3 with a
DD-WRT alpha build, so that could be the reason... ;-)
--
dasjoen wrote:
> As previously mentioned, it fails when the Squeezebox is on WLAN and the
> server on wired LAN. I suspect my WLAN router must be the culprit here
> somehow...
And I assume you have checked that there is no firewall or NAT active on
the WLAN router?
dasjoen wrote:
> Does anybody have any idea what could cause this? As I said, it worked
> on the laptop (Windows 8, WiFi), but not on the Ubuntu server (wired).
The self test passes in two cases:
1. When the Squeezebox and the server are both on wired LAN
2. When the Squeezebox and the server a
dasjoen wrote:
> I just tried installing LMS on my laptop, and the self test passed, so
> the problem is clearly with the Ubuntu server somehow...
Does anybody have any idea what could cause this? As I said, it worked
on the laptop (Windows 8, WiFi), but not on the Ubuntu server (wired).
-
Triode wrote:
> This suggests there is a problem streaming over the local network. Some
> other users of recent ubuntu has seen something but I've not got to the
> bottom of it. The plugin will require more reliable streaming than
> local flacs as it can't seen such a big burst of traffic (henc
dasjoen wrote:
> I just ran the self test: Everything is OK, except streaming to the
> player: "Streaming to player stalled before end of track, rate LOW". The
> log file (again) looks like this:
>
> [21:51:07.443394] main:586 req: stream.flc res:
> spotify:track:7mliwEVqxIuwLmHdTXlBrx par:
> pl
I just ran the self test: Everything is OK, except streaming to the
player: "Streaming to player stalled before end of track, rate LOW". The
log file (again) looks like this:
[21:51:07.443394] main:586 req: stream.flc res:
spotify:track:7mliwEVqxIuwLmHdTXlBrx par:
player=00%3A04%3A20%3A12%3Aab%3A
altruizine wrote:
> Thanks a lot for responding -- and good to know I'm not the only one
> with this problem.
>
> I tried thinking very hard what I might have changed in my system setup
> before the problem started. The only relevant things I could come up
> with are a Linux kernel upgrade, inc
Thanks a lot for responding -- and good to know I'm not the only one
with this problem.
I tried thinking very hard what I might have changed in my system setup
before the problem started. The only relevant things I could come up
with are a Linux kernel upgrade, including an upgrade of the Virtual
I have exactly the same problem. Spotifyd.log shows the following when
the problems occur:
[19:42:34.630197] main:586 req: relogin res: (null) par: (null) prot:
HTTP/1.0 auth: (null)
[19:42:34.630255] main:1579 relogin requested
[19:42:34.630333] main:1608 resetting streambuf
[19:42:34.664392] lo
80 matches
Mail list logo
