Name is required.
Email address is required.
Invalid email address
Answer is required.
Exceeding max length of 5KB

Spaces not allowed in filenames, even URL encoded?

I have a Wowza server (latest version) on EC2/Amazon S3.

Files that have spaces in the filename won't play for me, even using the online wizard.
I've tried URL encoding the spaces (%20), but it still doesn't work.

Any idea?


This works:
But this doesn't:
amazons3/wwz-files/61-1001M It Becometh Us To Fulfil All Righteousness VGR.mp3

And neither does this:

I've verified both files exist on S3, with the exact same casing.

The error is always "Stream Not Found"

9 Community Answers

JW Player

0 rated :

Also, I forgot to mention - The URL encoded file works with Wowza's sample RTMP player perfectly...

The line didn't wrap properly above, truncating the URL.
Here it is in full (remove spaces)

JW Player

0 rated :

This is a long, sad story. You see, in the beginning of time, browsers replaced the space character with the plus character. Then people wanted plus characters and other "special" characters, like non-ASCII characters in their URIs. So urlencoding was born.

Some severly brain-damaged browsers and servers still don't deal with this correctly.

*_Usually,_* you can deal with this by *_double-urlencoding_* the URL/URI.

For the JW FLV Media Player, all URL/URIs that have the special characters ( ? = & ), *MUST* be urlencoded because those characters are also used to assemble the flashvars string.

Example:bc.. "file="

So you can see that the special characters within the URI are urlencoded, but the special characters that are used to assemble the flashvars string are NOT urlencoded.

Now back to the brain-damaged...

Some browsers and/or servers will un-urlencode the string, messing things up.

One way to deal with this is to *double-urlencode* the string.

Here's an example where I an assembling an email string that has spaces and was being broken on those spaces by the email client. You can see the JavaScript method *encodeURIComponent()* is nested within another *encodeURIComponent()*, resulting in *double-urlencoding* and the string is treated as one long URI by the email client.bc.. window.location = 'mailto:' + document.eMailer.address.value + '?subject=Video%20Link&body=' + encodeURIComponent(location.href + '?title=' + *encodeURIComponent(player.getPlaylist()[currentIndex].title)* + '&file=' + player.getPlaylist()[currentIndex].file);

SoforaJWFLVMediaPlayerfileURL/URIwithspaces:bc.. 'file':encodeURIComponent(''+*encodeURIComponent('RockVideos')*+'&year=1975');

Where the portion of the URI with the spaces 'Rock Videos' is being *double-urlencoded*.

I hope this gets you started. You will have to experiment on your own particular combination of code, server, and all of the brain-damaged browsers.

*_Good Luck!_* :D

JW Player

0 rated :

I actually already tried double-URL encoding them... It didn't work in the wizard. URL-decodes (apparently recursively) all incoming flashvar strings.

These do not get re- URL-encoded during RTMP. Look at the following code, and note the lack of a URLEncode() around the 'url' variable:

/** Set streaming object **/
169 public function setStream():void {
170 var url = getID(model.playlist[model.config['item']]['file']);
171 stream = new NetStream(connection);
172 stream.addEventListener(NetStatusEvent.NET_STATUS,statusHandler);
173 stream.addEventListener(IOErrorEvent.IO_ERROR,errorHandler);
174 stream.addEventListener(AsyncErrorEvent.ASYNC_ERROR,metaHandler);
175 stream.bufferTime = model.config['bufferlength'];
176 stream.client = new NetClient(this);
177 video.attachNetStream(stream);
178 stream.soundTransform = transform;
180 var res:Responder = new Responder(streamlengthHandler);
183 clearInterval(timeinterval);
184 timeinterval = setInterval(timeHandler,100);
185 };

JW Player

0 rated :

Here's the code I generated from the wizard.

<script type="text/javascript" src=""></script>

<div id="player">This text will be replaced</div>

<script type="text/javascript">
var so = new SWFObject('/jw/embed/player.swf','mpl','470','290','9');

JW Player

0 rated :

Here's the patch (

This seems to fix the issue. Note that some streaming servers work without URL encoding - and some don't. Different versions of Wowza do and don't - the latest build seems to require them.

I highly reccomend integrating this into the next version.

public function setStream():void {
var url = getID(escape(model.playlist[model.config['item']]['file'])); //we must escape the path before calling getID, or the colon (after mp3:) will be encoded too.

JW Player

0 rated :

Unfortunately, I can't get the position/length numbers to display properly after rebuilding the project. I downloaded the right font (I think - it didn't throw any missing font errors). They're offset vertically.

JW Player

0 rated :

Well, I have never had a problem on Apache-2.2.11, LightTPD-1.4.20, Red5-0.7.0, or nginx-0.7.38.

I've never used Wowza.

JW Player

0 rated :

Nathanael: did you end up fixing your problem ?

JW Player

0 rated :

Well, I traded it for another - the position/length number display issue. if anyone knows how to fix the font issue (I downloaded the suggested one) and insert that one line of code above, I'd be very thankful... my e-mail is nathanael.jones at

@lefTY Yeah, I think the latest version of Wowza now requires URL encoding - I guess the 4 you listed don't.

The filenames are URL decoded at the beginning, so I don't see any reason why URL encoding them should cause a compatibility issue. And official word on this issue? Any patch date?

This question has received the maximum number of answers.