HTTP Range

[mvaranda]

Hello,

I am working on a multi-purpose player which needs to figure out whether the server is seekable or not. So I issue the http request having the header with "range:0-"

Most servers are OK with this. However, my player does not work with the link:
http://winnfm.primcast.com:9486/;stream.mp3

After investigation I found that the server seems to do not handle well the range last-byte-pos. The server does not deliver the payload getting stuck until it times out.

The HTTP spec states the following:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14

14.35.1 Byte Ranges

If the last-byte-pos value is absent, or if the value is greater than or equal
to the current length of the entity-body, last-byte-pos is taken to be equal to
one less than the current length of the entity- body in bytes.

Examples of byte-ranges-specifier values (assuming an entity-body of length
10000):

- The final 500 bytes (byte offsets 9500-9999, inclusive):
bytes=-500
- or bytes=9500-

Question: There is any plan to change this behaviour?

Thanks a lot,
Marcelo

BTW... here is the reader reply (showing v1.99Beta):

49 43 59 20 32 30 30 20 4f 4b 0d 0a ICY 200 OK..
69 63 79 2d 6e 6f 74 69 63 65 31 3a 3c 42 52 3e icy-notice1:<BR>
54 68 69 73 20 73 74 72 65 61 6d 20 72 65 71 75 This stream requ
69 72 65 73 20 3c 61 20 68 72 65 66 3d 22 68 74 ires <a href="ht
74 70 3a 2f 2f 77 77 77 2e 77 69 6e 61 6d 70 2e tp://www.winamp.
63 6f 6d 2f 22 3e 57 69 6e 61 6d 70 3c 2f 61 3e com/">Winamp</a>
3c 42 52 3e 0d 0a <BR>..Winamp</a>
69 63 79 2d 6e 6f 74 69 63 65 32 3a 53 48 4f 55 icy-notice2:SHOU
54 63 61 73 74 20 44 69 73 74 72 69 62 75 74 65 Tcast Distribute
64 20 4e 65 74 77 6f 72 6b 20 41 75 64 69 6f 20 d Network Audio
53 65 72 76 65 72 2f 4c 69 6e 75 78 20 76 31 2e Server/Linux v1.
39 2e 39 62 65 74 61 3c 42 52 3e 0d 0a 9.9beta<BR>..v1.
69 63 79 2d 6e 61 6d 65 3a 77 69 6e 6e 66 6e 0d icy-name:winnfn.
0a .cy-name:winnfn.
69 63 79 2d 67 65 6e 72 65 3a 4d 69 73 63 0d 0a icy-genre:Misc..
69 63 79 2d 75 72 6c 3a 68 74 74 70 3a 2f 2f 77 icy-url:http://w
77 77 2e 77 69 6e 6e 66 6d 2e 63 6f 6d 0d 0a ww.winnfm.com..w
63 6f 6e 74 65 6e 74 2d 74 79 70 65 3a 61 75 64 content-type:aud
69 6f 2f 6d 70 65 67 0d 0a io/mpeg..ype:aud
69 63 79 2d 70 75 62 3a 31 0d 0a icy-pub:1..
69 63 79 2d 62 72 3a 39 36 0d 0a icy-br:96..

[DrO]

SHOUTcast doesn't work that way. it's just a constant stream of data and although like HTTP it is not a straight HTTP server - it's not parts of files so what you're trying to access will never be provided.

[mvaranda]

Thanks DrO. I do not want to actually get any specific range for real.
However, I need to get a sense about the range by looking at server's reply.

The problem is that SHOUTcast server gets stuck upon my range request.

Can SHOUTcast server just ignores range request?

I have 1 million clients whose may be willing to listen SHOUTcast powered radios in the last 6 weeks and the number will definitely grow a lot. Do you have a private email address?

[DrO]

it should be ignoring the range request header anyway (though you're testing against a beta version of the DNAS server that i don't believe was ever officially supported or even how it came to be).

if you're targeting anything against a DNAS server that is reported as v1.x then if there is a bug in it and the handling of that header value then there is no way to fix them (the v1 DNAS no longer gets development updates). if it's an issue with the v2 DNAS then something could be done about it (though not currently as i'm working on other projects so work on that is in hiatus at the moment) and ofcourse this is all dependent on if there is an issue in getting the stations to update their servers (which is a monumental issue at best).

the fact the DNAS server is providing the header response implies that it is ignoring the range request header, you should then have started receiving the audio data once it had completed (as what is shown in the output above looks correct up to what is shown). as the audio data follows after the header has been received and it will just keep providing the audio data on the socket connection without further headers.


i don't give out my email on the forum, though you can follow up via a pm though at the moment there isn't too much i can really do if there are issues (as covered above).

[mvaranda]

Thank once again. My private email is mv_emailATyahooDOTcom

I would appreciate if you could write to me there.

I had my player working with SHOUTcast when I was requesting a huge range:
"Range:0-1024000000000000"

However I had to reverse my request to "Range:0-" as some servers times out waiting to that amount of payload to be available.

Anyways... we will have 1 million less potencial listeners to some radio stations powered by some versions (or all) of SHOUTcast after my toda's patch to my player. Maybe it is worthy to investigate it further.

If you are interested then please write to my private email (from your private one).

Regards,
Marcelo

[DrO]

i'm not sure how that is going to help with things as i'm not actively focused on SHOUTcast at the moment (am only keeping an eye on the forum and replying as time allows) so i wouldn't be able to viably help looking into debugging issues further.

my gut feeling is that it's more likely you're not handling the response from the DNAS server correctly rather than it being the DNAS server not liking the range response header based on you having been provided with the response in the first post.

additionally i have absolutely no idea who you are / work for so i'm sorry but i'm not going to commit myself to an unknown (is why i had mentioned to pm me as a starting point) since if this is a business related thing, that is outside of my responsibilities.

[mvaranda]

Thanks DrO.
All I can tell in this forum (without violating NDA's) is that my player is running in more than a million clients and the number will grow significantly in the next months to come.

If anyone related to SHOUTcast server cares about increasing the acces to its server please be welcome to write to me: mv_email@yahoo.com

I will be please to disclose details about my player.

Regards,
Marcelo

[DrO]

that's why i'm saying send me a pm (private message via the forum) so it's not publically open (as in all honesty i wouldn't currently email that address as no offence but i've seen too many look like it from spammers).

it is not a matter of not caring, it is time and logistics as although i'm the current SC tools dev, i'm working on other projects (Winamp + Cloud) so i don't have a full focus on SC at the moment, hence if you pm me something, if it's applicable then depending on management we may be able to allocate some time to look into the issue sooner rather than later.