Broken Pipe issue

[niamh]

@rpedde wrote:

I’d sure like to find out what this is, but I don’t seem to have that problem. I have yet to experience a skip, so I think it’s something environmental.

— Ron

OK some more information to mull over-

Fixed IP and I attached a pair of high gain antenna to rhe router and ran a 24 hour continuous test without problems.

Swapped back to the stock antenna (The antenna change was just before “Catherine Of Aragon”) and within a few tracks was getting-

[root@fedora log]# tail -n 20 mt-daapd.log
2007-01-17 16:05:49 (b6b47bb0): Session 0: Streaming file ’11 – Anything Goes.mp3′ to 10.0.0.12 (offset 0)
2007-01-17 16:09:15 (b6b47bb0): Session 0: Streaming file ’12 – Rocket Queen.mp3′ to 10.0.0.12 (offset 0)
2007-01-17 16:10:09 (b7f4a6c0): Rescanning database
2007-01-17 16:10:15 (b7f4a6c0): Starting playlist scan
2007-01-17 16:10:16 (b7f4a6c0): Scanned 3983 songs (was 3983) in 7 seconds
2007-01-17 16:20:26 (b6b47bb0): Session 0: Streaming file ’01 – Catherine Of Aragon.mp3′ to 10.0.0.12 (offset 0)
2007-01-17 16:23:56 (b6b47bb0): Session 0: Streaming file ’02 – Anne Of Cleves.mp3′ to 10.0.0.12 (offset 0)
2007-01-17 16:32:00 (b6b47bb0): Session 0: Streaming file ’03 – Catherine Howard.mp3′ to 10.0.0.12 (offset 0)
2007-01-17 16:38:38 (b6b47bb0): Session 0: Streaming file ’04 – Jane Seymour.mp3′ to 10.0.0.12 (offset 0)
2007-01-17 16:39:09 (b6146bb0): Session 0: Streaming file ’05 – Anne Boleyn (The Day Thou Gavest Lord Has Ended).mp3′ to 10.0.0.12 (offset 0)
2007-01-17 16:39:17 (b6b47bb0): Write error: Broken pipe
2007-01-17 16:39:32 (b6b47bb0): Session 0: Streaming file ’06 – Catherine Parr.mp3′ to 10.0.0.12 (offset 0)
2007-01-17 16:39:33 (b6146bb0): Write error: Broken pipe
2007-01-17 16:39:47 (b6b47bb0): Write error: Broken pipe
2007-01-17 16:39:50 (b6b47bb0): Session 0: Streaming file ’01 – Because.mp3′ to 10.0.0.12 (offset 0)
2007-01-17 16:40:09 (b6146bb0): Session 0: Streaming file ’02 – Get Back.mp3′ to 10.0.0.12 (offset 0)
2007-01-17 16:40:18 (b6b47bb0): Write error: Broken pipe
2007-01-17 16:40:49 (b6b47bb0): Session 0: Streaming file ’03 – Glass Onion.mp3′ to 10.0.0.12 (offset 0)
2007-01-17 16:40:50 (b6146bb0): Write error: Broken pipe
2007-01-17 16:43:58 (b6b47bb0): Write error: Broken pipe

For the record signal levels with high gain were -60dBm to -65dBm and the standard give -72dBm to -78dBm

[rpedde]

@niamh wrote:

Fixed IP and I attached a pair of high gain antenna to rhe router and ran a 24 hour continuous test without problems.

This sure seems like a wireless thing then.

Even so, I can’t imagine a wireless signal so bad it can’t pass a 192k stream. That seems very wrong. The code just sits in a tight read/write loop from the file to a socket, so there really isn’t anything to not work there.

I wonder if there might be some sockopts that might help. Buffer size or something of that nature?

[niamh]

@rpedde wrote:

This sure seems like a wireless thing then.

Even so, I can’t imagine a wireless signal so bad it can’t pass a 192k stream. That seems very wrong. The code just sits in a tight read/write loop from the file to a socket, so there really isn’t anything to not work there.

I wonder if there might be some sockopts that might help. Buffer size or something of that nature?

Shame the Soundbridge doesn’t report the connection speed, it would be one more piece of data to throw into the equation.

If you come up with anything further to test let me know.

[rpedde]

@niamh wrote:

@rpedde wrote:

This sure seems like a wireless thing then.

Even so, I can’t imagine a wireless signal so bad it can’t pass a 192k stream. That seems very wrong. The code just sits in a tight read/write loop from the file to a socket, so there really isn’t anything to not work there.

I wonder if there might be some sockopts that might help. Buffer size or something of that nature?

Shame the Soundbridge doesn’t report the connection speed, it would be one more piece of data to throw into the equation.

If you come up with anything further to test let me know.

Can you get a network capture of it at the time of the disconnect? It would be nice to know who is resetting the connection — the soundbridge or the firefly server. If it’s the soundbridge, then we might have to take it to them.

[niamh]

@rpedde wrote:

Can you get a network capture of it at the time of the disconnect? It would be nice to know who is resetting the connection — the soundbridge or the firefly server. If it’s the soundbridge, then we might have to take it to them.

I can try, if anyone wants to suggest some good pointers as to a good way to do it, I’ll appreciate it.

[rpedde]

@niamh wrote:

@rpedde wrote:

Can you get a network capture of it at the time of the disconnect? It would be nice to know who is resetting the connection — the soundbridge or the firefly server. If it’s the soundbridge, then we might have to take it to them.

I can try, if anyone wants to suggest some good pointers as to a good way to do it, I’ll appreciate it.

Should be able to use wireshark if on windows. Google for the windows binary for it. You can set up a filter like “tcp.port == 3689” or whatever port you are using on the server. Then tell it to start capturing on the interface on the server you have connected to the network.

Then just start capturing until you get a skip. Stop capturing, save the capture, and that’s it.

Those are kind of big-picture instructions — there are more details on how to select what interface to capture, etc, but I think you’ll find it isn’t too bad.

Once you’ve got a capture of the event, you can save just a few frames — the ones near the disconnect, and then it will be easy to see what’s going on.

Yell if this is too terse.

— Ron

[niamh]

@rpedde wrote:

Should be able to use wireshark if on windows.

Then just start capturing until you get a skip. Stop capturing, save the capture, and that’s it.

Those are kind of big-picture instructions — there are more details on how to select what interface to capture, etc, but I think you’ll find it isn’t too bad.

Once you’ve got a capture of the event, you can save just a few frames — the ones near the disconnect, and then it will be easy to see what’s going on.

Yell if this is too terse.

— Ron

Firefly is running on a server install of FC4 here… I’ll start googling in the morning and see what I come up with.

[rpedde]

@niamh wrote:

Firefly is running on a server install of FC4 here… I’ll start googling in the morning and see what I come up with.

in that case, someting like

foo@bar:~$ sudo tcpdump -i eth0 -w out.cap port 3689

should get a capture file that’s readable with wireshark/ethereal.

— Ron

[niamh]

@rpedde wrote:

foo@bar:~$ sudo tcpdump -i eth0 -w out.cap port 3689

should get a capture file that’s readable with wireshark/ethereal.

— Ron

OK, why does it take for ever waiting for an error condition to happen? Finally got a “Broken pipe”, now to see what I’ve captured in the almost 4 million packets

[niamh]

@niamh wrote:

now to see what I’ve captured in the almost 4 million packets

Something that crashes wireshark!

18:46:28 Err file emem.c: line 291: assertion failed: (npc->buf != NULL)

Press any key to exit

[Author]

Posts