Song plays only after 5 min delay (Firefly on MSS+ to Roku)

[schro20]

I have installed SVN-1433 on my MSS+ according to the online instructions and am streaming to a Roku SB1000 (2.7b3) over wireless. Everything is working fine, but there is one song (one I have found so far…) which only plays after a considerable delay. I have increased error logging and looked at the log. It appears that when this song is selected the log claims it is being served. I see activity on my wireless link consistent with there being bits pushed across it but my Roku makes no noise (it appears to be waiting). After approx. 5:15 minutes the song is served a second time, and that time the Roku actually produces the music. The length of the song is 6:30. So the initial delay is not the same as the song length. I have rebooted and played various other games and find this behavior to be consistent. Whether I play the song as an element of a song list or alone, it’s the same thing every time. When playing the song with iTunes (7.0.2) on my PC from a local disk it plays fine. When I have my PC iTunes connect to the MSS hosted firefly it too has a problem of playing the song (the play button reverts back to the arrow and repeated hitting it, waiting for more than 5:15 minutes, hitting it again, etc. does not coerce iTunes on my PC to play it).

In the logs I did notice one thing. The first time the song is served it is served with “offset 0”. The second time (when I can hear it) it is served with offset 32. The song is encoded in m4a by Nero (if that matters; I have other files that came out of the same workflow which appear to be playing fine). It has no meta tags.

What sort of additional data should I collect to help understand what is happening here?

[stretch]

The song is encoded in m4a by Nero

Yes, it does actually.

The SB requires AAC music files to be configured for “fast start” streaming.
The only encoder I’ve found that can do this is iTunes 😥

the reason for the silence is the SB is scanning through the file looking for some information that it needs.
When configured for fast start streaming this bit of the file is places at the very beginning so it’s the first thing that is read.

I’m lead to believe that if you put that track into an iPod it will suffer the same problem.

[schro20]

Stretch, thank you for your response.

I just tried playing this song on my iPod and it starts right away. Note also that it starts right away when I play it on my PC using iTunes and the file lives on the PC. (If I play it in iTunes on my PC, but use the firefly server to serve it up it doesn’t play at all.)

I have other files that were encoded by Nero (same workflow) and they play ok, so I suspect this is not yet the answer to this riddle.

What does the “offset” field in the server logs indicate? As I mentioned, the first serve serves to ipnumber:offset 0 while the second one (which I can hear) serves to ipnumber:offset 32. Perhaps there is a hint in that behavior.

[xaviour]

@schro20 wrote:

I have installed SVN-1433 on my MSS+ according to the online instructions and am streaming to a Roku SB1000 (2.7b3) over wireless. Everything is working fine, but there is one song (one I have found so far…) which only plays after a considerable delay.

You can fix your m4a files using “mp4creator -optimize” from the package mpeg4ip.

Someone made a compiled version available as a 7z compressed archive for Windows there. While I use the linux version regularly to fix the problem you describe, I have never tried the windows version.

[rpedde]

@schro20 wrote:

What does the “offset” field in the server logs indicate? As I mentioned, the first serve serves to ipnumber:offset 0 while the second one (which I can hear) serves to ipnumber:offset 32. Perhaps there is a hint in that behavior.

Stretch is exactly right — the file you have isn’t fast-start enabled.

Basically, it works like this — there is a ton of data in a m4a file — album and author info, info about bitrate and sample size, album art, lyrics, etc.

They all get laid out in the file one block after another in any order.

So you can lay out the data in the file however you want, but there is a smart way to do it and a dumb way. The smart way is to put the data you need to play the music (sample rate, etc) at the start of the data, then the actual music data after it. That way, if the song is streamed, you get the chance to read the info you need to play the music before you see the music.

The dumb way, on the other hand, puts the metadata *after* the actual music data. In the case of a file played on the local PC, it doesn’t matter. You can skip to the end of the file, read the metadata you need, then skip back to the beginning of the file. That works fine.

When you stream, though, it sucks… you can’t really seek to the end of a file, you have to stream the whole file to get there.

That’s what’s happening here. It has to stream the whole file to get the metainfo it needs to play the song, and then has to restart the stream in order to actually play the music data, which is sitting at the beginning of the file (offset 32).

So that’s what the mpeg4ip utility does — it rearranges the data so it’s got the metadata first.

— Ron

[schro20]

Yep, running it through the mp4creator -optimize fixes it. Now that I know what to look for of course I found a whole bunch of files which have the same problem… Gross.

I wonder whether I can just simply run this program on *all* my m4a files instead of hunting for the particular ones that have this missing fast start layout. I am nervous about making itunes angry…

Thanks for helping out with identifying this culprit.

[stretch]

iTunes configures AAC files for fast start by default so the first step would be to identify which files were not encoded by iTunes and optimise those first.

[Author]

Posts