1pixelout can't find file

Hi.
I am having exactly the same problem.
Wijering's flash player plays the mp3 fine, but the 1pixelout player says "Error opening file".
Did you fix it? Anyone else?
Cheers.

Same here. I just get an error when tryinf to play it.

Same problem. Only Wijering's player works. The demos on emspace are also broken for me:

http://emspace.com.au/node/25

I've tried it in Firefox 2.x and Safari 3 on my Mac, and IE7 on Windows. Behavior is the same every time: The object displays "buffering" for a brief moment, then shows the message "error opening file."

I get similar behavior with the default viewers and with Simpleviewer, but, as noted, Wijering's player works.

OK, I know what's causing this, but haven't yet dug in to how to fix it -- or, more importantly, determined why anybody can ever get any of these players to work at all.

Here's the deal:

When SWFTools is writing out the OBJECT tagset, it encodes the URL for the audio file so that it looks like this:

http%3A/%252Fdomain.tld/path....

I copied the source code, pasted it into the body tag and edited the URL in the source so that it read as follows:

http://domain.tld/path....

Now it works, for that instance.

I looked at the page source for the examples on emspace.com.au, and they have the same issue.

Yeah, I was having that problem as well with the single file/older players

Here is my ugly solution:

swftools.module
Around line 430 (my version) in function swftools_swftools_embed, right above the html embed writer:

$foo = array('%3A/%252F');
$bar = array('://');
$P['flashvars'] = str_replace($foo, $bar, $P['flashvars']);

Thanks, I took a quick look at it and didn't know where to begin.

Does anybody know why the protocol punctuation gets encoded that way? What does it mean? Jeroen's viewer can handle it just fine, but it looks to me as though it means nothing.

cross posting this solution from http://drupal.org/node/191279#comment-750952:

The below function (line 725 of swftools.module) seems to be the culprit:

function _swftools_get_flashvars_string(&$flashvars) {

foreach ($flashvars AS $var => $value) {
$flashvars[$var] = str_replace(array('&', '=', '?'), array('%26', '%3D', '%3F'), $value);
}
$encoded = drupal_query_string_encode($flashvars);

// '#' seems to encode as %2523, reverse this, using a more robust hex prefix..
$encoded = str_replace('%2523', '0x', $encoded);

return $encoded;
}

So add ugly hack there:

function _swftools_get_flashvars_string(&$flashvars) {

foreach ($flashvars AS $var => $value) {
$flashvars[$var] = str_replace(array('&', '=', '?'), array('%26', '%3D', '%3F'), $value);
}
$encoded = drupal_query_string_encode($flashvars);

// '#' seems to encode as %2523, reverse this, using a more robust hex prefix..
$encoded = str_replace('%2523', '0x', $encoded);

// begin hack
$foo = array('%3A/%252F');
$bar = array('://');
$encoded = str_replace($foo, $bar, $encoded);
// end hack

return $encoded;
}

This seems to filter down better for javascript and raw embedding, you can remove the other location of the hack.

I am guessing it is the:

$encoded = drupal_query_string_encode($flashvars);

But not up for hunting that down today.

This is another instance of the encoding issue that is reported a few other times in the issue queue.

It's fixed in the latest dev code, so I'll set this one to "patch (code needs review)" and it can be closed when testing is finished.

Setting to fixed as new releases of SWF Tools 5.x-2.0 and SWF Tools 6.x-1.1 are now available which address this issue.