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.
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) amazons3/wwz-files/61-1001M%20It%20Becometh %20Us%20To%20Fulfil%20All%20Righteousness%20VGR.mp3
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.
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);
<script type="text/javascript"> var so = new SWFObject('/jw/embed/player.swf','mpl','470','290','9'); so.addParam('allowscriptaccess','always'); so.addParam('allowfullscreen','true'); so.addParam('flashvars','&file=amazons3/wwz-files/61-1001M%2520It%2520Becometh%2520Us%2520To%2520Fulfil%2520All%2520Righteousness%2520VGR.mp3&streamer=rtmp://ec2-67-202-2-179.compute-1.amazonaws.com/vods3'); so.write('player'); </script>
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.
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.
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 gmail.com.
@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.