Hi,

After recently adding a second Soundbridge to my home network, I've started seeing a problem where a track that's been playing suddenly stops, and the Soundbridge moves onto the next track in the album, without indicating that there's been any problem. If I skip backwards, it'll usually play the same track a second time without a problem. I see this on about 1 out of 6 tracks. It's infrequent and random. It can happen at any point in the track.

I have both Soundbridge's wired into a GigE switch, along with my PC that's running MediaConnect. There's a D-Link router also wired up to the switch which is acting as the DHCP server. There aren't any static IP addresses used on this net at all.

Both Soundbridge's exhibit the problem, but I only need to have one powered up for it to happen.

The only thing that I see that bothers me is that the LEDs on the switch port that the Soundbridge is plugged into shows that there's lots (more or less appears continuous) of collisions on the wire.

If anybody has any ideas, they'd be appreciated.

Thank-you!

--Imre M.

I'm also seeing this behaviour on a wireless network running iTunes, although its frequency probably about 1 in 10 tracks. Otherwise it is running fine.

I have seen this behavior as well. It happens very rarely (once every 50-100 tracks). In my case what usually happens is that the SB immediately jumps to the next track. I have had two cases where it simply stopped playing and didn't jump tracks. In these two cases I'm not sure if it stopped becuase it was at the end of the song que or not

I'm glad it's not just me then. I wish it was only 1 out of 100 tracks for me too, unfortunately it's definitely more like 1 in 5.

If it's not the last track in the list, then yes, it simply abruptly moves on to the next track in mid-stream. No warning, no rebuffering or anything. It just moves on.

Any suggestions from Roku? Please??

--Imre

Happens for me often enough to be really annoying.

Config:
Linux (Fedora Core 3) running mt-daapt
wired to D-link 802.11g bridge
over-the-air to D-link 802.11g WAP
wired to Airport basestation
over-the-air to M1000 soundbridge

Same "random skip" behavior as previous posts.

As you might imagine, we have more than a couple of SoundBridges on our network at work, and many of us have multiple units at home (I have three, myself).

The only times I've seen the symptom you described were when the SoundBrige got some sort of network or server error so that the actual fetching of the data from the server failed at some point in the song.

We don't always know at the playback level how long a song is expected to be, so this can be seen as just "we reached the end of the song", so we don't display an error or anything -- just move on to the next track.

The collision thing mentioned by magyar is not a symptom of a problem, by the way. For some reason, our particular network stack and Ethernet chip just make for a lot of collisions. We've looked into it and may be able to reduce it in the future. But, it doesn't cause playback problems.

I don't know enough about what might be causing the problem you're seeing, especially with the wired connections, to suggest anything. Let me ping my colleagues.

I will add a little more information about the collision light. We are running the SoundBridge in half duplex 10mbit mode (for reasons I won't go into in this post). The Ethernet standard says that when a unit is being run in half duplex mode, then the controller must listen for a fixed amount of time for no network activity before transmitting. The hub does the same thing, for the exact same amount of time. Then what will happen is that both the hub and the device will attempt to transmit at the same time, causing a collision. Then using the random backoff algorithm of Ethernet, one of the units that caused the collision will back off more than the other, and one unit will successfully send the packet.

So, as you can see from my explanation, the SoundBridge is operating exactly according to the 802.3 specification. I have also checked with the company that makes the Ethernet chip we are using and they agree that the chip is operating properly and according to the Ethernet 802.3 spec.

Greg Garner
Director of Hardware Engineering
Roku

Thanks for the collisions info, Greg & Mike. At least we know that's not the source of the problem then.

Regarding the possibility of server errors (it sound like it's more than just one brand of server, though), is it possible to look at any statistics or error counts on either the Soundbridge web-server page or through the telnet connection perhaps?

If there's anything we can do to help resolve this, please let us know.

--Imre M.

Hate to bump my own thread, but there were a number of others who are having the same problem, so I thought it's worth the trouble to ask again...

To rule out (or at least diminish the liklihood) of network hardware errors, I isolated the Soundbridge and the PC that WMC runs on on their own network switch. The server is now a new PC wiith a clean Windows install. The only other thing installed and running on it is WMC. There isn't anything else on the network, and it's all wired.

Not all the others reporting the problem were running WMC, so it sounds like the problem probably isn't on the server side, unless it's a Windows internal bug.

For what it's worth, when a track just stops in midstream like this, it seems to tend to almost always be in the second half, often towards the end.

Again, if we can help diagnose/debug the problem for you, please say so.

--Imre M.

I am also having this problem. Running a SoundBridge M1000, wireless with a Linksys WRT54G router, mt-daapd on Linux as a server. It seems to happen every 10 songs or so -- all of a sudden the song will cut off (always toward the middle-end of the song) and the next song will play. Sometimes the same song will play fine, sometimes it will cut off. The SoundBridge is currently the only wireless device on the network. The linux box is plugged in and running at 100Mbps. Most of my songs are 320 kpbs CBR MP3s.

I'm currently running mt-daapd in a rather verbose logging mode. The log around the most recent cut-off song looks like:

2005-03-08 23:06:38: Session 1: Streaming file '02 The Rover.mp3' to 192.168.0.201 (offset 0)
2005-03-08 23:11:14: Rescanning database
2005-03-08 23:11:14: Processing static playlist: Hawd Koa.m3u
2005-03-08 23:11:14: Processing static playlist: MelloLog.m3u
2005-03-08 23:11:14: Processing static playlist: MelloTronic.m3u
2005-03-08 23:11:14: Processing static playlist: Punk Rock.m3u
2005-03-08 23:11:14: Processing static playlist: Rockkkk.m3u
2005-03-08 23:11:14: Scanned 3600 songs (was 3600) in 0 seconds
2005-03-08 23:11:17: Finished streaming file to remote: 10641408 bytes
2005-03-08 23:11:21: Request: GET /databases/1/items?query='dmap.itemid:1343884'&session-id=1& /SNIP/ HTTP/1.0
2005-03-08 23:11:21: query: 'dmap.itemid:1343884'
2005-03-08 23:11:21: Request: GET /databases/1/items/1343884.mp3?session-id=1 HTTP/1.0
2005-03-08 23:11:21: Session 1: Streaming file '03 In My Time Of Dying.mp3' to 192.168.0.201 (offset 0)

---

The song "The Rover" was cut off early. The actual file size is 13490243 bytes. Note that the log says it streamed only 10641408 bytes.

I'm not sure if it's significant that a database scan happened just before the song got cut off. The database is rescanned every 5 minutes, and it usually causes no problem. Also, I think some songs have been cut off without a recent database scan. I plan to explore this further by turning off automatic database rescanning. I will report the results of that experiment.

I can't make any conclusions from this data. Is there any way to view an activity log on the SoundBridge?

Update:

I disabled the automatic rescans, and the cut-offs are still happening.

If we have the same problem when using linux-based servers, I guess it's probably safe to rule out Windows and WMC as the culprit.

That other old thread about the random channel reversal that sometimes happens on tracks, usually between the halfway point and the end, could this be a different manifestation of the same problem, except that the track terminates instead of getting its channels reversed? It seems an odd coincidence that things go awry in the second half of a track.

In any case, one would think there's some sort of debug tracing that could be enabled on the Soundbridges somehow.....

Roku guys???

Jgatts, mt-daapd won't do wma lossless, will it?

Are you playing VBR MP3s? Many MP3 players have problems detecting the end of VBR MP3s and cut off prematurely. My iPod often clips the ends of VBR MP3 songs that I ripped using MusicMatch.

satan wrote:

Are you playing VBR MP3s? Many MP3 players have problems detecting the end of VBR MP3s and cut off prematurely. My iPod often clips the ends of VBR MP3 songs that I ripped using MusicMatch.

Nope, just playing wma lossless.

Magyar:

No, I don't think mt-daapd will do WMA lossless.

Satan:

This is happening with CBR MP3s. As I mentioned, it is also inconsistent -- sometimes a song will play through and sometimes it won't. So I doubt that it's a problem calculating the song length.