FireFly Media Server › Firefly Media Server Forums › Firefly Media Server › Nightlies Feedback › Broken Pipe issue
- This topic has 26 replies, 4 voices, and was last updated 17 years, 3 months ago by niamh.
-
AuthorPosts
-
17/01/2007 at 4:56 PM #8193niamhParticipant
@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 pipeFor the record signal levels with high gain were -60dBm to -65dBm and the standard give -72dBm to -78dBm
17/01/2007 at 5:12 PM #8194rpeddeParticipant@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?
17/01/2007 at 5:56 PM #8195niamhParticipant@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.
17/01/2007 at 6:03 PM #8196rpeddeParticipant@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.
17/01/2007 at 9:27 PM #8197niamhParticipant@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.
17/01/2007 at 10:48 PM #8198rpeddeParticipant@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
17/01/2007 at 11:15 PM #8199niamhParticipant@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.
17/01/2007 at 11:57 PM #8200rpeddeParticipant@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
18/01/2007 at 6:17 PM #8201niamhParticipant@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
18/01/2007 at 7:09 PM #8202 -
AuthorPosts
- The forum ‘Nightlies Feedback’ is closed to new topics and replies.