I just updated to njb 6.03.2 (from 5.something). Before and after, I have a problem streaming mp3 to my iPhone. Phone has iOS 7.0.4. Steps to repeat: Launch Chrome or Safari browser over Wifi on local network, browse to njb server, login as user with streaming rights, browse to album & a 4 minute song, select Stream. The stream starts out fine (it launches Quicktime player & starts playing music) but after a couple minutes playback jumps back to the beginning of the song. FWIW the QT time elapsed/scrub/scroll control stays at 0:00 (even when the music is playing), shows a total time of "--:--" and does not respond to changes. I tried changing Stream profile from 128 to 64 kpbs; the only difference is the music plays a little longer before looping back to the beginning, but still does not complete even a 4 minute song.

Please let me know if any other information would help isolate this problem. Thanks!

Apple makes streaming very complicated, see: https://developer.apple.com/streaming/
I haven't found a way to stream multiple files like in standard m3u playlist.
But it supports a way to cut one large stream in multiple blocks like:

Instead of using blocks from the same content I have used different tracks (of course with different playtime) and set the #EXT-X-TARGETDURATION to the longest track.
This seems to work for most albums and always for one track.
It looks like that if there are very different playlenght streaming doesn't work anymore.
Here you can download a test version: netjukebox_6.04alpha1.zip
Please give me some feedback how the test version works.

Maybe streaming with different length tracks will work again when using #EXT-X-BYTERANGE for longer tracks????

First, thanks for your help with this! I was finally able to try out 6.02 alpha 1 and alpha 2. Right now I have only general observations:

* The file I complained about initially (doesn't stream correctly in 6.03.2) doesn't stream at all in the alphas. The QT player launches but the media never loads.
* Some files do stream in the alphas, and when they do, the seek control works within reason (short seeks are more successful) (yay!)

Streaming success seems to have a correlation with the provenance of the target file. The target could be any of the following:
1. MP3 of unknown origin (downloaded from usenet, file sharing, etc.)
2. MP3 created by me from CD using AudioGrabber and LAMEEnc
3. MP3 downloaded from Amazon
4, m4A downloaded from iTunes
5. MP3 created by iTunes from m4A

My original complaint was based on case (2). For me to do a proper test I need to identify files in each case and try them in each version. This will take me a while. I guess I've complicated the question enough for now.