Broken Pipe Error when Streaming files to Soundbridge

[jheinitz]

Hello,

I’m using Firefly Media Server (svn-1489) on an NSLU2 using unslung 6.8. I stream music to a Soundbridge and everything works perfect except one thing:

Most of my songs are AAC files that I converted from Audio CDs to AAC files using iTunes and the AAC Encoder which comes with iTunes. I added the Album Covers to quite a lot of these songs. I copy the files from the Windows PC to the NSLU2. When I stream music to the Soundbridge, I see a “Write Error: Broken Pipe” message in the logfile very often. The music is streamed perfect anyway. To see if the problem is related to my network connection or the file that is streamed, I created 4 files: 2x AAC and 2x MP3. All of the files contain the same song and 1 AAC file contains an album cover and the other AAC one not. Same with MP3 songs.
When I stream these 4 songs to iTunes, I get no “Broken Pipe”. When I stream them to the Soundbridge, I get the “Broken Pipe” only for the files containg an artwork image.

I searched the forums for “Broken Pipe” and found that there are issues around, but I believe that it is related to the image in the file and not to network settings like DHCP or WLAN.

Please also see my logfile. (IP Adress x.x.x.40 is a Windows PC with iTunes and x.x.x.46 is the Soundbridge)

2007-01-28 15:41:16 (006d3c04): Session 0: Streaming file ’01 Test1 AAC – no cover.m4a’ to 192.168.85.40 (offset 0)
2007-01-28 15:46:11 (006ffc04): Session 0: Streaming file ’01 Test1 AAC – no cover.m4a’ to 192.168.85.46 (offset 0)
2007-01-28 15:46:15 (00700c05): Session 0: Streaming file ’01 Test1 AAC – with cover.m4a’ to 192.168.85.40 (offset 0)
2007-01-28 15:51:02 (0072a804): Session 0: Streaming file ’01 Test1 AAC – with cover.m4a’ to 192.168.85.46 (offset 0)
2007-01-28 15:51:03 (0072a804): Write error: Broken pipe
2007-01-28 15:51:04 (0072b004): Session 0: Streaming file ’01 Test1 AAC – with cover.m4a’ to 192.168.85.46 (offset 82759)
2007-01-28 15:51:15 (0072d405): Session 0: Streaming file ’01 Test1 MP3 – no cover.mp3′ to 192.168.85.40 (offset 0)
2007-01-28 15:56:07 (00757c04): Session 0: Streaming file ’01 Test1 MP3 – no cover.mp3′ to 192.168.85.46 (offset 0)
2007-01-28 15:56:16 (00759005): Session 0: Streaming file ’01 Test1 MP3 – with cover.mp3′ to 192.168.85.40 (offset 0)
2007-01-28 15:57:12 (00757c04): Write error: Broken pipe

Best regards

Jens

[rpedde]

@jheinitz wrote:

I searched the forums for “Broken Pipe” and found that there are issues around, but I believe that it is related to the image in the file and not to network settings like DHCP or WLAN.

Looks like the soundbridge is seeking past the image data. It reads the headers, sees where the file actually starts, and seeks to that position. It does that by closing the connection and requesting a new connection at a longer offset.

That’s probably normal. Not very polite, but normal. Perhaps I could tune down the logs some, but the error could be indicative of other problems, so I’d rather leave it in there.

In the case you show, though, it’s a normal error. If that makes sense.

— Ron

[jheinitz]

Hi Ron,

thanks for your fast reply. I agree with you that the Soundbridge might skip the image data. But unfortuneatly it seems that the play_count in the Database does not get updated. I think that this is related to the Broken Pipe error. I’m using the Soundbridge quite often, but the play_counts are very low. I performed the following SQL command using sqlite3:

SELECT title, play_count FROM songs WHERE play_count != 0

and this returns only a few of the songs that I already played.

Could it be related to the Broken Pipe? I read something that the play_count is only updated when all data is streamed to the client. Otherwise it’s not.

Regards

Jens

[CCRDude]

*doublepost somehow, one deleted*

[CCRDude]

Actually I’ve been experiencing things while testing with album covers that affect iTunes as well. When you add a song with a cover, it’ll show a track length time of lets say 10:00 minutes.
If you start the song in iTunes, iTunes will immediately switch to 9:30 minutes (some lesser time, seems to be directly related to the size of the image, but ONLY of the image, imho not the tag size, because removing the image but filling it only with zeros, not reducing tag size, seems to have lead to full playback in an early test).

So I tested a bit further, and there even seems to be an offset!
If I play one and the same file in WinAmp, it starts at the very beginning, if I start it in iTunes streamed from the net, it starts a few seconds later! If I add it to the local iTunes database, it starts from the beginning again, so the late start happens ONLY when streamed through Firefly.

I can still try if this happens when streaming from one iTunes to another iTunes, to make sure it doesn’t have to do something with the iTunes streaming client…

edit: this indeed happens as well when streaming from iTunes to iTunes. Maybe I’ll try to use unsynchronized ID3v2.4 tags instead of plain ones next…

[rpedde]

@jheinitz wrote:

Could it be related to the Broken Pipe? I read something that the play_count is only updated when all data is streamed to the client. Otherwise it’s not.

Yup, that’s what it is. I’ll try and get a workaround for that.

— Ron

[CCRDude]

Now I am totally confused 😀

I could swear that there was a different post just before mine yesterday?
One mentioning that when a track had album art, it wouldn’t start streaming at the beginning ❓

[jheinitz]

Hi Ron,

that would be nice to get a workaround for that. Than I can build playlists based on the play_count field.

In order to get around other Broken Pipe errors, maybe you can think about adding a parameter to the config file where every user can set wether the server should treat the stream as played when 10%, 20% or 100% is streamed to the client. This would give more flexibility to the product. But anyhow, I really like the Firefly Server and I’m happy with it.

@CCRDude: I tried to reproduce your phenomena with the playtime in itunes, but I could not do so. A song with 5:00min playtime was not reduced to 4:xx after pressing the play button. But maybe it is related to the fact that the image in the file is too small. I’m not using high quality images.

Best regards

Jens

[CCRDude]

Oh, it’s getting more difficult 😉 Got a file thats skipping 5 seconds for a 49 KB cover picture.

Summary: I thought I had found a general problem with album art, in which case we would have something that Ron maybe could more easily reproduce it. Wasn’t the case though, I continued testing, and found that the problem only appears with iTunes as a client, NOT with the Soundbridge as a client (using either iTunes or Firefly didn’t matter, so it’s clearly a client thing).

Details: ID3v2.3 and ID3v2.4 (normal and unsynched) on iTunes local database: starts at position #0. ID3v2.4 (normal and unsynched) over Firefly or standard iTunes: starts at later positition. ID3v2.3 starts at correct position even over remote conenction. I’ve written those tags with different apps to make sure its not a badly written tag.

Conclusion: if you were using mostly MP3, I would have recommended to try ID3v2.3 instead of ID3v2.4, or at least unsynchronized ID3v2.4 tags. Since you’re using mostly AAC though, and my tests revealed that the direction I investigated does only affect the iTunes client, forget that, sorry that I can’t be of more help 😀

[Author]

Posts