Mixxx

Bug #1329202
Comment #1

Comment 1 for bug 1329202

Revision history for this message

Kevin Wern (kevin-m-wern) wrote on 2015-11-08: Re: Live Broadcasting - Mount is not escaped when sending metadata

#1

https://github.com/mixxxdj/mixxx/pull/771

This is my best attempt at the feature, but I'm not sure if I understand the problem, or if querystring mounts are even supported. I know that by running an Icecast server locally that this seemed to be the previous behavior:

- Mixxx keeps the mount (say, /live?stream_id=1&tracking=2, as in Marco's example), the same. shout uses the mount for the base of the request, which is SOURCE (mount) HTTP/1.0.
- Icecast, using the httpp library, parses this request. httpp splits the URI at the first '?', retaining only the resource and moving the parameters to an AVL tree of variables after parsing. So at this time, a resource /live is generated.
- Mixxx, using the original string, updates the metadata with libshout. The url is parsed by httpp in Icecast, which is split again at the first '?'. The nested query string does mess up the results (because it naively splits at '&' and '='), but the main thing that matters is that the requested mount path to update would look something to the effect of '/live?streamid=1'.

So the real issue is that the requested mount point does not match the one originally generated. With the current fix, the server can generate the correct mount point, but requires listeners to escape the characters in the URI, as well--and even then, the file version of the streams don't work. On the server itself, stream files and admin requests are generated using the unescaped string, which means the links like /live?stream_id=1&tracking=2.m3u do not work. The fix I added really only serves to make mixxx handle querystring items more gracefully (and send metadata correctly in the cases Marco described), while retaining all the flexibility of the original setting,

I'm not sure if I understand how Marco is using the above mount point, because it seems to not be usable in Icecast2. I think that the correct behavior would be either:
- Remove the query string and leave only the resource when the mount point is set in preferences (or do this in a later step and retain it in the dialog).
- Figure out some way to combine the admin querystring and the custom querystring, in the case where the server admin wants to have custom settings. I do not know how useful this would be.

I don't know, what you guys think would be best?

https://github.com/mixxxdj/mixxx/pull/771

This is my best attempt at the feature, but I'm not sure if I understand the problem, or if querystring mounts are even supported.  I know that by running an Icecast server locally that this seemed to be the previous behavior:

- Mixxx keeps the mount (say, /live?stream_id=1&tracking=2, as in Marco's example), the same.  shout uses the mount for the base of the request, which is SOURCE (mount) HTTP/1.0.
- Icecast, using the httpp library, parses this request.  httpp splits the URI at the first '?', retaining only the resource and moving the parameters to an AVL tree of variables after parsing.  So at this time, a resource /live is generated.
- Mixxx, using the original string, updates the metadata with libshout.  The url is parsed by httpp in Icecast, which is split again at the first '?'.  The nested query string does mess up the results (because it naively splits at '&' and '='), but the main thing that matters is that the requested mount path to update would look something to the effect of '/live?streamid=1'.

So the real issue is that the requested mount point does not match the one originally generated.  With the current fix, the server can generate the correct mount point, but requires listeners to escape the characters in the URI, as well--and even then, the file version of the streams don't work.  On the server itself, stream files and admin requests are generated using the unescaped string, which means the links like /live?stream_id=1&tracking=2.m3u do not work.  The fix I added really only serves to make mixxx handle querystring items more gracefully (and send metadata correctly in the cases Marco described), while retaining all the flexibility of the original setting,

I'm not sure if I understand how Marco is using the above mount point, because it seems to not be usable in Icecast2.  I think that the correct behavior would be either:
- Remove the query string and leave only the resource when the mount point is set in preferences (or do this in a later step and retain it in the dialog).
- Figure out some way to combine the admin querystring and the custom querystring, in the case where the server admin wants to have custom settings.  I do not know how useful this would be.

I don't know, what you guys think would be best?