With most stream names, this works fine, but if the broadcast stream name contains a space (or various other non-alphanumeric characters), then we get an error reported at the origin:
Invalid LiveMediaStream URL[wowz://originhost:1935/origin/Testing12/Test Test] : java.net.URISyntaxException: Illegal character in path at index 44: wowz://originhost:1935/origin/Testing12/Test Test|at java.net.URI$Parser.fail(URI.java:2829)|at java.net.URI$Parser.checkChars(URI.java:3002)|at java.net.URI$Parser.parseHierarchical(URI.java:3086)|at java.net.URI$Parser.parse(URI.java:3034)|at java.net.URI.<init>(URI.java:595)|
We're passing the URL encoded stream name to the repeater, but it looks like it's decoding it before passing it on the the origin. If we double-encode the stream name (Test Test —> Test%20Test —> Test%2520Test), we can play it, but surely we shouldn't need to?
In my tests, I was able to publish a stream "test test" (space between the two words) and playback using the url encoded version via the
test players (i.e. test%20test) as expected. My suggestion would be to eliminate the use of spaces or setup a custom module to do so from published stream names.
That would work fine if we had a small number of stream names we know in advance, and we could set up specific aliases for those stream names which have odd characters in them. However, that's not the case for us, since our broadcasters can make up whatever stream name they like.
On the other hand, the module you suggest using includes the full source, so we could try to modify it to do the appropriate aliasing itself, automatically. We need to figure out how hard that will be to do first, though...