Page 1 of 1

API Request: different content type for stream method

PostPosted: Fri Jun 04, 2010 11:30 pm
by nickcurran
I'm writing a Silverlight 4 app that works as an out of browser, cross-platform Subsonic client. I'm running in to a problem that I believe would be solved by a different content type from the stream.view response.

Silverlight has a component that handles streaming, and it expects a resource that has an audio type, e.g. "audio/mpeg."

So while stream.view has content type "application/octet-stream" and download had "application/x-download" - and these are both fine...

Is there any chance we could have a third request method? I suggest "resource.view" that featured a content type that corresponded to the file's type.

I'd be happy to experiment with this myself. Is there a "how to get started" with the source code? I haven't done much Java work.

I love Subsonic, and I thank you much for the fine work you've done. Any advice you could provide here would be much obliged.

Thanks,
Nick

PostPosted: Sun Jun 06, 2010 8:29 pm
by sindre_mehus
Hi Nick,

There if fortunately a work-around for this: You can add a "suffix" request parameter, and the content type will be set properly.

For instance: "&suffix=mp3"

I hope to fix it in the next Subsonic version so that the content type is always set correctly.

Hope this helps. Looking forward to see the Silverlight app in action!

Sindre

PostPosted: Sat Jun 19, 2010 1:59 am
by nickcurran
Thanks, Sindre.

That was helpful. Now when I use the basic streams with the Content Types, it seems to work.

However, I'm still having a couple of issues. These might be Silverlight limitations, but perhaps you can think of something else?

1: The last 6-10 seconds seems to get cut off from every track. Is this perhaps because Content Size isn't included? Is there a way to get Content Size in the response header?

2: No transcoded streams seem to work. This I don't understand at all, perhaps a stream timing issue?

Thanks again,
Nick

PostPosted: Sun Jun 20, 2010 2:31 pm
by sindre_mehus
Hi,

Unless I'm sadly mistaken, the content length is set for all non-transcoded streams. This probably explains why the transcoded tracks fail.

I'm not sure why it cuts off, but I would check two things: that the content length is correct, and that the ID3 duration tag is correct.

Sindre