PDA

View Full Version : Buffer drained, pausing playback



natemorriss
2006-02-04, 15:35
Here's the situation.

I have a Mac mini 1.42 GHz 1GB DDR SDRAM running OSX 10.4.4 Slimserver 6.2.1 and a SliMP3.

This is the household mac but is also the slimserver. I have two additional 200GB external Firewire and USB2 HD. The music is on the Firewire drive. My music playback will stall, in the middle of playback, every couple of songs for about 5 seconds then resume.

I believe this is a snippit from the log file (at the end) from when a stall occured. I included the lines before and after incase they can help. I beleive the "***Stream underrun: 200" is where the problem begins.

The computer can be idle and this happens. There appears to be a spike in the processor when it happens but I thinks it's slimserver tring to fix the problem. I don't use the web interface for anything but setting preferences. This seems to be a problem that only came up since the last upgrade.

Is there any fix for this? At this point I'm considering going with a Roku SoundBridge if this can't be fixed.


2006-02-04 16:10:06.4776 Generating page for status_header.html took: 0 wallclock secs ( 0.02 usr + 0.00 sys = 0.02 CPU)
2006-02-04 16:10:06.8304 Generating page for playlist.html took: 0 wallclock secs ( 0.01 usr + 0.00 sys = 0.01 CPU)
2006-02-04 16:10:17.4075 DBI: Supressing periodic commit - no dirty items
2006-02-04 16:10:36.8353 Generating page for status_header.html took: 0 wallclock secs ( 0.02 usr + 0.00 sys = 0.02 CPU)
2006-02-04 16:10:37.2118 Generating page for playlist.html took: 0 wallclock secs ( 0.01 usr + 0.00 sys = 0.01 CPU)
2006-02-04 16:10:44.4561 browsedb - hierarchy: age,track level: 0
2006-02-04 16:11:12.7645 Generating page for status_header.html took: 0 wallclock secs ( 0.02 usr + 0.00 sys = 0.02 CPU)
2006-02-04 16:11:12.9464 ***Stream underrun: 200
2006-02-04 16:11:12.9479 00:04:20:04:19:5dBuffer drained, pausing playback
2006-02-04 16:11:12.9733 00:04:20:04:19:5d Buffer full, starting playback
2006-02-04 16:11:13.3437 Generating page for playlist.html took: 0 wallclock secs ( 0.01 usr + 0.00 sys = 0.01 CPU)
2006-02-04 16:11:13.3636 DBI: Supressing periodic commit - no dirty items
2006-02-04 16:11:14.9004 Generating page for browsedb.html took: 30 wallclock secs ( 1.64 usr + 0.74 sys = 2.38 CPU)
2006-02-04 16:11:43.3098 Generating page for status_header.html took: 0 wallclock secs ( 0.02 usr + 0.00 sys = 0.02 CPU)
2006-02-04 16:11:43.3672 DBI: Supressing periodic commit - no dirty items
2006-02-04 16:11:43.7085 Generating page for playlist.html took: 0 wallclock secs ( 0.00 usr + 0.00 sys = 0.00 CPU)
2006-02-04 16:12:13.3772 DBI: Supressing periodic commit - no dirty items
2006-02-04 16:12:13.6639 Generating page for status_header.html took: 0 wallclock secs ( 0.02 usr + 0.00 sys = 0.02 CPU)
2006-02-04 16:12:13.8599 Generating page for playlist.html took: 0 wallclock secs ( 0.00 usr + 0.00 sys = 0.00 CPU)
2006-02-04 16:12:16.0276 forceCommit: syncing to the database.

Bonesteel
2006-02-04, 19:26
I have been in your same situation, but switching to the Roku is not the answer. As it was described to me, after I essentially pitched a fit here, the SLiMP3 has a very small buffer. Do a little searching and you'll find the Wiki page which compares it to the newer devices.

Given this relatively small buffer, what I have experienced with my SLiMP3 and the SlimServer is that any release post 6.02 impacts my playback such that I get the same cut outs that you get. Unlistenable. This is b/c with the small buffer there is little wiggle room from the server if you put any other load on it. And I have a dedicated G4 Sawtooth with a gig or RAM and 10.3.9.

I would offer the caveat that many seem to be able to support running current Slimserver releases on the SLiMP3 without issues, but these folks mostly have either small libraries or have the time to dick around with settings all day to optimize playback. If you use the Mini for other tasks, you've also introduced additional hits in processing that help to drain the buffer.

You have two reasonable options - drop back to an earlier version of Slimserver, losing some bells & whistles, or buy a new Squeezebox with a larger buffer.

natemorriss
2006-02-04, 19:58
I honestly don't think that a larger processor would do any good for the situation I'm in. It looks like the server has about reached it's usful life and they are no longer supporting the SliMP3 folks. When the playback stalls the proccessors are about 80% free. The Mac mini is more then enough computer to serve up a little music. I upgraded from an old iMac last summer and had very few music stalls if ever and that had a 350MHz G3.

I've heard a couple of people who have switched to the Roku from squeezeboxes and have been very happy. I like the whole open source software but it doesn't really seem to be improving any with the last couple of updates.

Bonesteel
2006-02-04, 20:15
I think you misunderstood me. I am by no means advocating a faster processor. The Mini should be fine. The problem is the combination of the small buffer in the SLiMP3 and the bloat introduced in the newer versions of the slimserver SW that only become evident with that small buffer. I tried running 6.2.1 on my G5 iMac 2Ghz and still had drop outs on my SLiMP3. For what it's worth, I can run 6.02 of the Slimserver SW and it works great. Try rolling back to an earlier version and see if your performance improves. It's a quick test.

notanatheist
2006-02-04, 23:49
FWIW, there's a memory leak in 6.2.1 (at least on linux). I was advised to upgrade to a nightly 6.2.2. Just did that today and everything seems fine so far (SB2/3 firmware needs to be upgraded to v29 too). Your CPU isn't a problem and the SB2/3 have an adequate buffer. I'd be intertested in knowing if the upgrade works for the Mac too.

Let me also add, I *had* a Soundbridge. They are damned slow in comparison. The lag is as bad as using XMMS or Winamp. Even Softsqueeze is more responsive.

Ben Sandee
2006-02-05, 00:05
On 2/4/06, natemorriss <natemorriss.22qkab (AT) no-mx (DOT) forums.slimdevices.com>
wrote:
>
>
> I honestly don't think that a larger processor would do any good for the
> situation I'm in. It looks like the server has about reached it's usful
> life and they are no longer supporting the SliMP3 folks.


<snip>

This is simply untrue and unfair characterization of SlimDevices and the
community. I'd bet that a significant percentage of the contributers (paid
and unpaid) to the SlimServer software do use SliMP3's still. Slim has gone
out of their way to continue to support this device and there is no
indication that I can see that this will change. Efforts are constantly
being made to improve issues that make the SliMP3 a tricky beast to develop
for (like the small buffer size, in particular). You may be unhappy with
the pace of the development but if you look at how far we've come in one
year, it really is significant.

FWIW, one of my two SliMP3's gets more daily use than my SB2 and my SB3
combined and when I file bug reports that specify failures specific to my
SliMP3 (has happened in the past), they still get prompt responses and
fixes.

Ben

2006-02-05, 02:25
> > It looks like the server has about reached it's usful
> > life and they are no longer supporting the SliMP3 folks.

> This is simply untrue and unfair characterization of SlimDevices and the
> community.

I agree. Up until recently (when I upgraded to SB2's as I like that form factor better) I was using a SLIMP3 a lot. Bug fixes were still forthcoming.

Of course, someday, they will stop supporting the SLIMP3. And I will argue that that is reasonable. You cannot support legacy hardware forever, especially if you're a small company.

I'm willing to bet, though, that when that day comes, whatever legacy code is needed in the slimserver to drive the SLIMP3 is left in there indefinitely, so it will not be as though the device implodes or something.

Kevin

bpa
2006-02-05, 02:53
Another reason for not switching to Roku is that some Roku users get this error as well even on wired connections.

What is worse is the Roku has a timeout in the slimserver emulation which means after underrun it will reset the connection and stop playing even though slimserver still sends the data. The only solution is to stop the song and restart it - your current situation is annoying with 5 sec gap but functional.

natemorriss
2006-02-05, 06:33
oK, I downgraded to 6.0.2. I was hopeing there was a setting that I could change to prevent this error.

There's too much on my computer for me to play with beta software to upgrade to 6.2.2 or 6.5.x. I do nightly backups but I'd rather never have to use them...

Bonesteel
2006-02-05, 13:25
I'd be curious to see how you fare with the roll back to 6.02.

I've had no luck with any rev later than that.

Michaelwagner
2006-02-05, 20:43
As I recall, there is a performance problem, introduced by a well-meaning database call at the top of the browse pages. This call forces the database to enumerate all the tracks every time the web page refreshes.

This is why I believe this is what is happening to you:


2006-02-04 16:10:44.4561 browsedb - hierarchy: age,track level: 0
2006-02-04 16:11:12.7645 Generating page for status_header.html took: 0 wallclock secs ( 0.02 usr + 0.00 sys = 0.02 CPU)
2006-02-04 16:11:12.9464 ***Stream underrun: 200
2006-02-04 16:11:12.9479 00:04:20:04:19:5dBuffer drained, pausing playback
2006-02-04 16:11:12.9733 00:04:20:04:19:5d Buffer full, starting playback


at 16:10:44, you started to generate a browse out of the database.
28 seconds later, it finishes and formats the status page.
Then (and only then, because of the way Slimserver is architected) it notices that it underran the SLiMP3 buffer.
But the SLiMP3 buffer is only about 5 or 10 seconds. So the music stopped.

There are several solutions.

As suggested, newer squeezeboxes have bigger buffers, so they hide this problem.

Or remove the expensive and totally unnecessary database call. You can do this by hacking the web page yourself (hard) or upgrading to the 6.2.2 version, where they reduced the expense of the call by (I think) caching the result.

A faster processor would have to be about 6 times faster (for your system) to reduce that 28 second delay to something the SLiMP3 can overlive. It's unlikely you'd find such a processor.

natemorriss
2006-02-26, 08:56
Well 6.0.2 has fixed the skipping problem but it returned the problem of playing songs twice. A couple of albums will play everysong twice which is almost as annoying as the skipping. If I force a rescan it sometimes will fix that album (mostly not) but others may then double play. I've scanned the library and the files are not duplicated...

Michaelwagner
2006-02-26, 09:02
Well 6.0.2 has fixed the skipping problem

Did you really mean 6.0.2? Or did you mean 6.2.2?

Recent versions of 6.2.2 have the option to turn off the statistics at the top of the web page, which was what was slowing down your database scan. It seems to make a fair difference.

I don't know what you mean by
returned the problem of playing songs twice. I am running a fairly recent version of 6.2.2 (but perhaps not the same version as you). Nothing is playing twice. Is this something you have reported before? If so, can you give me a pointer so I can find out what you're talking about?

natemorriss
2006-02-26, 11:20
Your response make it sound like it's the web interface that is slow and I don't use the web interface except when there is a problem. So most of the skipping occurs without a web interface open with 6.2.1. Therefore, it seems to me that a fix to the web interface would not help my situation.

Yes I downgraded to 6.0.2. I have too much on my computer to play with beta software right now. I do back up evernight but it would still be a PITA to restore everything.

The new problem is that the older version would double play tracks. Using the web interface you can see that it has each song listed twice. Therefore it plays each song twice. The latest cd to double play is the Shrek Sound Track. The first song is item=8226 and the second song is item=1982 and as far as I can tell it's the same song. Clicking rescan did nothing. It's possible the song are in the library twice but they have differenet file names then.

NATE

Michaelwagner
2006-02-26, 11:47
Your response make it sound like it's the web interface that is slow and I don't use the web interface except when there is a problem.

For the trace you submitted, you did have the web interface open. I can see it in the trace. And it was the web interface that stopped streaming for 27 seconds.


So most of the skipping occurs without a web interface open with 6.2.1. Therefore, it seems to me that a fix to the web interface would not help my situation.

Perhaps. I can't tell from the trace you put into the thread. If there's another performance problem as well, the "big" one is masking the smaller one.

When you want to diagnose this again, please submit a trace where the server performance option Library Statistics is set to Disable, and therefore doesn't trigger the problem I saw.


Yes I downgraded to 6.0.2. I have too much on my computer to play with beta software right now. I do back up evernight but it would still be a PITA to restore everything.

Understandable. Thanks for clearing that up.

6.0.2 isn't current, though, so the double play problem you describe is likely fixed in more current versions. I understand this sounds like catch 22, but I'm not sure what to suggest.


Clicking rescan did nothing. It's possible the song are in the library twice but they have differenet file names then.

Did you do a full rescan? Sometimes when switching versions backwards and forwards, you can end up with bits of discordant database structure from the forward version confusing the back version.

Michaelwagner
2006-02-26, 11:55
Hmm...I re-read the thread (it's been a while since it started and my memory wasn't fresh).

You have a SLiMP3 and the pauses are about 5 seconds, you said. A SLiMP3 can buffer and run without the server for about 5 seconds, so these times when the processor isn't feeding the SLiMP3 are something like 10 seconds (5 seconds to eat up the buffer, 5 seconds of silence).

The trace you showed was 27 seconds of inattention, so that's clearly a different problem.

You also wrote:

The computer can be idle and this happens. There appears to be a spike in the processor when it happens but I thinks it's slimserver tring to fix the problem. I don't use the web interface for anything but setting preferences. This seems to be a problem that only came up since the last upgrade.
It would be useful to know *who* is using the processor during that spike. It *might* be Slimserver, but it might be someone else too. I'm not a MAC person, so I don't know what tools there are to isolate who is eating the CPU.

The one thing that occurs to me is device recovery ... have you checked the firewire drive for device errors. If the processor spikes it might be trying to recover from an error on the disk. I had this happen on one system, and the signs are very diffuse ... it was hard to track it back to the disk subsystem.

Although, device errors on schedule every 5 minutes seems like an odd situation.

I'm guessing now. A fresh trace without the contamination of the web interface would be very helpful.

natemorriss
2006-02-28, 05:11
OK I've put 6.2.2 on and did a complete rescan of the library and the questionable cd (Shrek soundtrack) still had the songs double loaded. I switched to "Do Not Use iTunes" and rescanned and the repeat songs disapperaed. My best guess is the iTunes library is either corrupt or has the songs doubled counted with the "Group compilations when browsing" feature, but I just checked and this is turned off anyway. I'm rescanning the library right now with iTunes turned on to see if the doubls reappear. I report when the server finished the scan.

I have not used the sliMP3 since I upgraded to the 6.2.2 so I don't know if it skips.

What Debugging loggers should I turnon to catch the skips? I forget what i had tuned on the first time.

Michaelwagner
2006-02-28, 05:30
In the scan you posted before, it looks like you had protocol and http turned on.

That's a good place to start, assuming the skips happen again.

But also watch and see if there is any other activity happening around the time of the skip, and turn on appropriate loggers for that too.

And try the network health page, see if it tells you anything about what's going wrong. It's quite a good diagnostic tool and there are people who can help you interpret it here on the forum.

natemorriss
2006-02-28, 05:37
Great thanks for the advice Michaelwagner I'll hopefully be able to get something. Well I guess truely I hope I don't get anything...

The rescan finished with iTunes turned back on and the repeat tracks have returned. I guess I can't enjoy my iTunes playlist anymore...

NATE

Michaelwagner
2006-02-28, 06:17
the repeat tracks have returned. I guess I can't enjoy my iTunes playlist anymore...
Well, or it could be a bug in the iTunes program,
or a bug in the iTunes interface inside Slim ... or
any number of things.

I can't help you with that part. I don't have iTunes. But someone else here might be able to help out.

natemorriss
2006-03-05, 09:01
Well I finally put some time into using the Slimp3 with 6.2.2 and it still skips. Not as often but it's still stalls. The log file has no mention of the stall so I must have not had the right debugger on. Only server was on. I'm not sure how the other got turned off but I'm going back to 6.0.2 and will have to turn iTunes support off. I didn't turn on Server & Network Health so it's no help.

Apple Front Row looks promising as a replacement. I'll have to wait and see if somebody comes out with a dedicated display, I don't want to have to turn the tv on to play music.



ID3v2 found. Be aware that the ID3 tag is currently lost when transcoding.
Input file is freeformat.
LAME: Can't find termcap entry for terminal "unknown"
ID3v2 found. Be aware that the ID3 tag is currently lost when transcoding.
Input file is freeformat.
LAME: Can't find termcap entry for terminal "unknown"
ID3v2 found. Be aware that the ID3 tag is currently lost when transcoding.
Input file is freeformat.
2006-03-05 09:48:52.6024 Requesting web page to keep SlimServer unswapped, re-request interval is 30 minutes.
LAME: Can't find termcap entry for terminal "unknown"
ID3v2 found. Be aware that the ID3 tag is currently lost when transcoding.
Input file is freeformat.
LAME: Can't find termcap entry for terminal "unknown"
ID3v2 found. Be aware that the ID3 tag is currently lost when transcoding.
Input file is freeformat.
LAME: Can't find termcap entry for terminal "unknown"
ID3v2 found. Be aware that the ID3 tag is currently lost when transcoding.
Input file is freeformat.

**********************

Michaelwagner
2006-03-05, 09:21
Hi Nate!

What format are these files? The log indicates they're being transcoded, which is an expensive process to be going through if it's not necessary ana may be a source of stuttering.

Michaelwagner
2006-03-05, 09:35
Nate, your trace is quite bizarre. The only message that came from Slim, as far as I can tell, is this one:

2006-03-05 09:48:52.6024 Requesting web page to keep SlimServer unswapped, re-request interval is 30 minutes.

The others came from somewhere else. At least I can't find them in the source.

And the references to LAME and transcoding make me think you're playing things other than mp3s. Are you? If so, what?

The debugging options you want, to start, are:
protocol
stream
source

That should help us get a handle on what's happening.

coldslabs
2006-04-29, 18:32
I've had the same problem with my squeezebox 1 for a while now. I haven't been able to nail down the problem. I followed the log suggestions in this thread and got this when the pause occurred:

Setup:
---------------------
2.1Ghz
1GB Ram
WinXP
SS 6.2.2 (clean reinstall, deleted the folder as well)
AlienBBC is installed
Squeezebox 1 (running wired)
MP3 with "no limit" to bitrate limiting set
---------------------
2006-04-29 18:12:44.7921 read a chunk of 32768 length
2006-04-29 18:12:46.0156 Read 32768 bytes from source
2006-04-29 18:12:46.0160 read a chunk of 32768 length
2006-04-29 18:12:47.2790 Read 32768 bytes from source
2006-04-29 18:12:47.2793 read a chunk of 32768 length
2006-04-29 18:12:48.5290 Read 32768 bytes from source
2006-04-29 18:12:48.5293 read a chunk of 32768 length
2006-04-29 18:12:49.3967 Setting maxBitRate for 192.168.0.5 to: 0
2006-04-29 18:12:49.3971 Setting maxBitRate for 192.168.0.5 to: 0
2006-04-29 18:12:49.6513 Setting maxBitRate for 192.168.0.5 to: 0
2006-04-29 18:12:49.6518 Setting maxBitRate for 192.168.0.5 to: 0
2006-04-29 18:12:49.7711 Read 32768 bytes from source
2006-04-29 18:12:49.7715 read a chunk of 32768 length
2006-04-29 18:12:49.9754 Setting maxBitRate for 192.168.0.5 to: 0
2006-04-29 18:12:49.9759 Setting maxBitRate for 192.168.0.5 to: 0
2006-04-29 18:13:00.0699 DBI: Supressing periodic commit - no dirty items
2006-04-29 18:13:01.8750 00:04:20:05:13:78: Underrun while this mode: play
2006-04-29 18:13:19.4918 Setting maxBitRate for 192.168.0.5 to: 0
2006-04-29 18:13:19.4922 Setting maxBitRate for 192.168.0.5 to: 0
2006-04-29 18:13:19.7890 Setting maxBitRate for 192.168.0.5 to: 0
2006-04-29 18:13:19.7894 Setting maxBitRate for 192.168.0.5 to: 0
2006-04-29 18:13:20.0674 Setting maxBitRate for 192.168.0.5 to: 0
2006-04-29 18:13:20.0678 Setting maxBitRate for 192.168.0.5 to: 0
2006-04-29 18:13:21.7165 Read 32768 bytes from source
2006-04-29 18:13:21.7168 read a chunk of 32768 length
2006-04-29 18:13:30.0708 DBI: Supressing periodic commit - no dirty items
2006-04-29 18:13:49.5593 Setting maxBitRate for 192.168.0.5 to: 0
2006-04-29 18:13:49.5598 Setting maxBitRate for 192.168.0.5 to: 0
2006-04-29 18:13:49.9373 Setting maxBitRate for 192.168.0.5 to: 0
2006-04-29 18:13:49.9378 Setting maxBitRate for 192.168.0.5 to: 0
2006-04-29 18:13:50.1400 Setting maxBitRate for 192.168.0.5 to: 0
2006-04-29 18:13:50.1404 Setting maxBitRate for 192.168.0.5 to: 0
... etc
---------------------------
This seems to be the significant line:
"Underrun while this mode: play"

The web interface has the "play" button highlighted and the player itself still says "now playing", but nothing is actually playing. Most of the time there is just a 2-3 second dropout, not a complete stopping of the music (as it was for the above output). All my music is MP3 (some VBR and some CBR). The player has no bitrate limiting set (and LAME isn't even installed). The dropouts have consistent happened with every version since ~6.0x. I can't say I've tried everything to fix it, but I've tried a lot.

- I wired my squeezebox.
- I replaced my router (Updated firmware for router)
- I replace my NIC (Newest drivers)
- I've upgraded to WinXP from Win2K (wiping the machine to do it)
- Removed ZoneAlarm

I can't really say any of this has had much of an impact. Frustratingly, the problem seems random. I won't run into for a day or two and then it'll happen every couple of minutes. Sometimes I ignore it and sometimes I want to tear my hair out. Strangely, my brother has a similar setup with a Slimp3 and he has never had this problem.
Does the output help? Anyone have suggestions of more things I can try? Any more information or output needed?

[The full stop has occurred twice while I've been writing this email.]

--G

Update: A pause occurred right after I posted this. I had the Network Health plugin enabled and it didn't report any problems ("This player is performing normally."). The log had the same underrun as the full stop, but then just went back to playing:

"2006-04-29 18:30:28.1538 read a chunk of 32768 length
2006-04-29 18:30:29.1311 Read 32768 bytes from source
2006-04-29 18:30:29.1315 read a chunk of 32768 length
2006-04-29 18:30:30.1140 DBI: Supressing periodic commit - no dirty items
2006-04-29 18:30:30.2170 Read 32768 bytes from source
2006-04-29 18:30:30.2174 read a chunk of 32768 length
2006-04-29 18:30:34.8418 Setting maxBitRate for 192.168.0.5 to: 0
2006-04-29 18:30:34.8423 Setting maxBitRate for 192.168.0.5 to: 0
2006-04-29 18:30:34.8565 Generating page for status_header.html took: 0 wallclock secs ( 0.00 usr + 0.02 sys = 0.02 CPU)
2006-04-29 18:30:34.9672 Generating page for playlist.html took: 0 wallclock secs ( 0.00 usr + 0.00 sys = 0.00 CPU)
2006-04-29 18:30:38.2953 00:04:20:05:13:78: Underrun while this mode: play
2006-04-29 18:30:39.7545 Read 32768 bytes from source
2006-04-29 18:30:39.7549 read a chunk of 32768 length
2006-04-29 18:30:39.8070 Read 32768 bytes from source
2006-04-29 18:30:39.8074 read a chunk of 32768 length
2006-04-29 18:30:39.8579 Read 32768 bytes from source
2006-04-29 18:30:39.8583 read a chunk of 32768 length
2006-04-29 18:30:39.9091 Read 32768 bytes from source
2006-04-29 18:30:39.9094 read a chunk of 32768 length
2006-04-29 18:30:39.9609 Read 32768 bytes from source
...etc"

Sigh. While composing this update I got another pause and then a fullstop. Buffer Fullness was reported as "Low" in the Network Health page (but that is kind of expected when it is stopped I suppose.). Help?

SoundBoy
2006-04-29, 20:39
Another reason for not switching to Roku is that some Roku users get this error as well even on wired connections.

What is worse is the Roku has a timeout in the slimserver emulation which means after underrun it will reset the connection and stop playing even though slimserver still sends the data. The only solution is to stop the song and restart it - your current situation is annoying with 5 sec gap but functional.

but if you are using Roku you can access the ITunes directly.. no slimserver needed to get your tunes to your ears, if memory servers me correct.

SoundBoy
2006-04-29, 20:43
[QUOTE=coldslabs]I've had the same problem with my squeezebox 1 for a while now. I haven't been able to nail down the problem. I followed the log suggestions in this thread and got this when the pause occurred:
....

great quote: I am sorry for your bad experience.. Mine is the super poor handling of Internet Radio Streams. What Real and Windows Media Player handel nicely, the SlimSoftware is chopping up like crazy.. I got used to it. I would say - hardware top.. software flop.. welcome to Slim Universe. Maybe you need to get used to your problem too.

Cheers

Michaelwagner
2006-04-29, 21:07
who said that?

Doesn't match either my experience with the software or, when I've had a problem, my experience with Slim customer support.

Triode
2006-04-30, 03:44
Sigh. While composing this update I got another pause and then a fullstop. Buffer Fullness was reported as "Low" in the Network Health page (but that is kind of expected when it is stopped I suppose.). Help?

Could you leave the server running with network health enabled and several songs playing, then post the graphs on the health player page here after it has paused a couple of times. [The summary section doesn't give all the details of the graphs below]

Is the player wired now? Is is a graphics display Squeezebox1 - if so you can run the NetTest plugin on it to check the network performance (see Wiki for diagnostics)

coldslabs
2006-04-30, 13:36
Could you leave the server running with network health enabled and several songs playing, then post the graphs on the health player page here after it has paused a couple of times. [The summary section doesn't give all the details of the graphs below]

Is the player wired now? Is is a graphics display Squeezebox1 - if so you can run the NetTest plugin on it to check the network performance (see Wiki for diagnostics)

The player is currently wired.

Attached is the Network Health output after about 4 pauses in a 3 hour period (pretty "good", at least compared to last night where is was happening much more often. Nothing changed in my setup since last night. I even played two of the same albums. I didn't even reboot the machine.).

I used the NetTest plugin at 192kbps (what most of my music is ripped at) for 45 minutes. The average reading was 98%.

Thanks for your help Triode. Hopefully this will shed some light on the matter.

Triode
2006-04-30, 15:23
I used the NetTest plugin at 192kbps (what most of my music is ripped at) for 45 minutes. The average reading was 98%.
I would hope this would state 100%. During this time did the instantaneous value drop below 100%? Less than 100% at slightly higher than your desired rate is likely to be a problem. [NB there is some overhead in the streaming protocol.] This should not be a problem when wired but best to be sure of this first.

The "Server Response Time" graph is the one that matters - your results look normal, but there are 7 times when the server took between 1 and 5 seconds to respond and 1 time when it took more than 5 seconds. It may be worth zeroing the counters and watching this to see. However server does look healthy for all other measurements.

coldslabs
2006-05-01, 13:17
I would hope this would state 100%. During this time did the instantaneous value drop below 100%? Less than 100% at slightly higher than your desired rate is likely to be a problem. [NB there is some overhead in the streaming protocol.] This should not be a problem when wired but best to be sure of this first.

The "Server Response Time" graph is the one that matters - your results look normal, but there are 7 times when the server took between 1 and 5 seconds to respond and 1 time when it took more than 5 seconds. It may be worth zeroing the counters and watching this to see. However server does look healthy for all other measurements.

I didn't watch the squeezebox during the 45 minutes of using NetTest so I'm not sure whether the instantaneous value dropped. If I retest it again, and it does drop, what does this indicate? That the network itself is defective in some manner and not the software?

Unfortunately I continue to have dropouts and stops. When I retest, server responsiveness levels are mostly strong with some longer times similar to the one I posted. Any other suggestions?

Mark Lanctot
2006-05-01, 15:29
If I retest it again, and it does drop, what does this indicate? That the network itself is defective in some manner and not the software?

It's already showing you that it can't quite pass 192 kbps of data. That's definitely a weak network.

Apologies if you've already listed this, but what router are you using? Have you taken a look at http://wiki.slimdevices.com/index.cgi?NetworkProblemsSecondGuide ?

coldslabs
2006-05-01, 15:47
It's already showing you that it can't quite pass 192 kbps of data. That's definitely a weak network.

Apologies if you've already listed this, but what router are you using? Have you taken a look at http://wiki.slimdevices.com/index.cgi?NetworkProblemsSecondGuide ?

I have had the same problem while using two different routers (a NetGear and a DLink). I'll post the model #s when I get home.

I hadn't seen that link. Thanks. Unfortunately most of that page seems applicable to WIRELESS/FLAC playout and problems. There doesn't seem to be any suggestions for my WIRED/MP3 issues, other than transcoding to an even lower bitrate. Since much of my music is already 192kbps, I'd really rather not go any lower.

UPDATE: The router is a DLink DI-604. I lent the Netgear to someone, so I'm not sure what model it is.

Mark Lanctot
2006-05-01, 16:16
I have had the same problem while using two different routers (a NetGear and a DLink). I'll post the model #s when I get home.

I hadn't seen that link. Thanks. Unfortunately most of that page seems applicable to WIRELESS/FLAC playout and problems. There doesn't seem to be any suggestions for my WIRED/MP3 issues, other than transcoding to an even lower bitrate. Since much of my music is already 192kbps, I'd really rather not go any lower.

It's not particular to FLAC playback, although that'll always push the limit. However it is particular to wireless.

I didn't realize you were on a wired network! A wired network that can't pass more than 192 kbps of data is severely broken. Have you swapped cables?

coldslabs
2006-05-01, 18:07
I didn't realize you were on a wired network! A wired network that can't pass more than 192 kbps of data is severely broken. Have you swapped cables?

I hadn't thought of that. Unfortunately the wiring is in the walls so swapping cables isn't really very easy. I'll have to borrow one and move my stereo I suppose. Ugh.

The squeezebox maintains a 99% buffer most of the time, but drops out every once in a while. Is it likely that a cable would be the cause of that? That seems like strange behavior for something that is physically static, but I'm totally uninformed on the subject.

Is it possible to have interference in a wired connection? I have 2 sets of speaker wire along with the cat5 in the same box. Could that be a problem?

FYI: I updated the other post. My current router is a DLink DI-604.

snarlydwarf
2006-05-01, 18:59
It is possible for a wired connection to show that sort of problem if the wiring is faulty. If it gets too near a 120vac circuit for too long, inductunce can be a problem (not always from the 120vac itself, that's a nice 60hz hum.. but things with motors and such can grind up an electric signal well).

Normally this isn't a problem: it's why there are rules about twisted pair: for each side of the ethernet there is a + and a - (ie, TX+/TX- and RX+/RX-) providing a balance.. when the + is driven high, the - is pulled low, which should make the signal very resistant to noise. (A T1 data circuit can run for -miles- like this without a problem, moving 1.5Mbps error free.)

But if the circuit is wired 'wrong' by mispairing the wires: it will actually be -more- susceptible to noise induction.

My desk at work at one point was wired by a phone guy who wired it like this. It worked fine and dandy.. unless I started moving a lot of data, then the wire would start generating noise with itself.

Do you have a long cable to try for a day to see if that fixes the problem? If it does you know where to look: it may be as simple as rewiring the connectors at the wall plate.

Michaelwagner
2006-05-01, 19:08
always worth asking - was it a telecom guy who put the ethernet cables in the wall? Cat 5 is pretty simple to wire, but you need to know the rules. There are some rules about not pulling it hard around sharp corners, etc. Some of those can break a cable and cause instabilities.

coldslabs
2006-05-01, 19:56
always worth asking - was it a telecom guy who put the ethernet cables in the wall? Cat 5 is pretty simple to wire, but you need to know the rules. There are some rules about not pulling it hard around sharp corners, etc. Some of those can break a cable and cause instabilities.

Well it wasn't the telecom guy who installed it (shuffling feet, looking at the ground) it was... me. I don't remember being particularly rough with it, but I can't say I didn't do something I shouldn't have.

I've moved the squeezebox next to the computer and hooked up some powered speakers to it. I'll see if my problem is replicated with this setup. Assuming the d***ass who installed the cat5 did it wrong, would you have a link to some good installing advice so it can be done properly next time? I think I'll start with making sure the connectors at each end are ok per snarlydwarf's post above, but if I have to rewire, I may need some pointers.

Thanks for the advice everyone. It is nice to feel like I'm narrowing down the problem, even if I caused it.

UPDATE: I have the squeezebox sitting next to the computer with a 4ft ethernet cable and I'm running the NetTest plugin. It's been going for ~15 min at 256kbps and I've seen repeated brief drops to 0%. The average is 97% right now. Maybe it's not my wiring skills.

Browny
2006-05-02, 03:17
Since it does not appear to be the cable can you confirm what your Link Speed and Duplex are set to on the NIC on your Server and the ports on your Switch.

Usually Auto-Detect should work fine. If you have this set already you could try using 100Mb / Full Duplex and see if that helps.

Michaelwagner
2006-05-02, 04:08
(shuffling feet, looking at the ground) it was... me.
No need to shuffle your feet.

If you're moderately careful installing cat5, you should be fine. But installers who are used to pulling copper thick enough to run 30 amps through tend to be a bit, how should I say, indelicate, when pulling cat5. And that can damage it, especially through steel joists or other sharp objects.

But it sounds like it happens even without that cable run, so time to look elsewhere. Good suggestions by others in the forum, nothing for me to add at this point.

slimpy
2006-05-02, 05:28
UPDATE: I have the squeezebox sitting next to the computer with a 4ft ethernet cable and I'm running the NetTest plugin. It's been going for ~15 min at 256kbps and I've seen repeated brief drops to 0%. The average is 97% right now. Maybe it's not my wiring skills.
This is normal. It always drops to 0 at the end of tracks.

Ignore the above, I didn't realize you had a SB1. Sorry.

-s.

coldslabs
2006-05-02, 10:44
This is normal. It always drops to 0 at the end of tracks.


This is the NetTest plugin I'm using though, not playing songs. It should be a solid block of data without drop outs.

Triode
2006-05-02, 10:55
Quick point - which version of NetTest are you using? (the one posted on the forum?)

Reason for asking is that I did change one thing in it between the one posted to the forum and the one included as part of the 6.5 beta. I think the early version (forum post) would record a reduced rate if the server instantaneously ran slow. The one in 6.5 does not (it over reads in these conditions.) Let me look at it and see...

coldslabs
2006-05-02, 11:00
Quick point - which version of NetTest are you using? (the one posted on the forum?)


I downloaded the one posted on the forums.
This is the link:
http://forums.slimdevices.com/showpost.php?p=66366&postcount=37

Should I be using the newer one? If so, where do I get it?

Triode
2006-05-02, 11:53
Just uploaded a newer version of NetTest to the same forum location: http://forums.slimdevices.com/showpost.php?p=66366&postcount=37

I don't expect to see a change in results here, but it is worthwhile you using the lastest one just to be sure.

[Details of the change: in the old version, if the server computer is doing something else, the NetTest plugin could store up a set of packets to send. These could cause it to think the connection is congested and hence record drops. The new version suppresses busts of test packets if the server computer is running slow. This actually means the rate generated on the network can be slightly low, but avoids recording low values due to the server doing other things. All an artifact of the fact that NetTest is makes cunning use of slimserver timers and screen displays, rather than being something the server was intended to do...]

coldslabs
2006-05-03, 09:28
Since it does not appear to be the cable can you confirm what your Link Speed and Duplex are set to on the NIC on your Server and the ports on your Switch.

Usually Auto-Detect should work fine. If you have this set already you could try using 100Mb / Full Duplex and see if that helps.

I checked this setting and the router was actually set to 10Mb. I changed it to 100Mb/Full Duplex and did a bit of testing:

NetTest plugin @256 for ~4 hours was 99% (an improvement)

I setup music to continuously run overnight with Network Health enabled, and the worst server response time I got was 1 packet(?) at < 1 (which is also an improvement). There were no 0% buffer-fullness entries, but there were some 20-30%.

I haven't been home long enough to actually listen to music for an extended period to see if the pausing issue is still present. Previously when I setup music to play overnight, it stopped at some point. I woke up this morning to the music still playing, which is definitely a good sign.

Thanks for the advice. Hopefully this was the problem and I can go back to listening and stop troubleshooting.

Michaelwagner
2006-05-03, 09:41
Yes, a router set to only 10Mb/s would be a drag.

Naively, 10Mb/s should still be enough.

The problem is, if the buffer gets close to empty, which it will from time to time, it will fill at 1/10 of the "normal" speed.

Hope it's all solved now.

coldslabs
2006-05-03, 20:30
I left the Squeezebox playing all day (on repeat all) and came home to it stopped. I started playing music tonight and I had a pause on the second song.

- "AfterSettingChange.txt" is the Network Health output after running all day, after changing the router and NIC's media settings to 100/Full Duplex.

- "AfterBriefRunPause.txt" is the output after the pause that occurred after playing less than two songs.

Any other suggestions? I don't know what else to try.

Michaelwagner
2006-05-04, 03:16
I was afraid of that. There are perhaps 2 problems, the 10Mb/s problem was likely masking the other.

I took a quick glance at the network statistics but could see nothing out of the ordinary. In the first one, there's no connection to the player, but that's reasonable .... it was stopped. Unfortunately, that screen isn't going to tell me why (and wasn't designed to).

I leave it to wiser minds than mine to see if there's something amiss in those reports that I missed.

Browny
2006-05-04, 06:55
Seems to me you have now covered off most of the possibilities:

- checked the Network Speed
- checked the cabling
- rebuilt the Server
- tried a different NIC on the Server

Is it possible to try:

- using a different PC for the server
- using a different Squeezebox (or Softsqueeze) as the client

Someone with better knowledge of the Squeezebox Hardware can comment better on this, but is it possible the Squeezebox itself is the cause of the issues?

coldslabs
2006-05-04, 07:14
- using a different PC for the server
- using a different Squeezebox (or Softsqueeze) as the client


Unfortunately, I don't have a different PC to try, at least in the short term. I have downloaded the new SlimCD (1.6.1) and booted from that last night. I left it playing on 'repeat all' with the Network Health plugin when I left for work. I'll test with linux for the next day or two and see if it acts similarly.

I am going to try and con my brother this weekend to allow me to steal his squeezebox for some testing.

Thanks for the suggestions.

coldslabs
2006-09-07, 07:27
In case anyone is subscribed and is interested, I fixed my dropout problem by... resetting the BIOS. My everpresent and nagging dropouts were erased entirely. I am thankful to say the least (I was using my squeezebox1 less and less because of my frustration) but I'm not quite sure what fixed it. Improper CPU clock speed maybe? I have yet to step through the BIOS again and configure them one at a time to determine exactly what the problem was (I've left the defaults). If anyone has any ideas to make the job easier I'd be happy to hear them. My squeezebox is much more enjoyable now that it doesn't stutter.

Michaelwagner
2006-09-07, 08:00
I'm still here and still subscribed.

Yeah, improper BIOS settings can open up a multitude of problems.