error opening file

This is a problem, it appears, with Drupal 5.3 and the drupal_query_string_encode. There is a similar problem here http://drupal.org/node/180506 .

Find this code in audio/players/1pixelout.inc

 $flashvars = drupal_query_string_encode($options);

$output = <<<EOT

And insert this code

  $flashvars = drupal_query_string_encode($options);

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

  // '/' seems to encode as %252F, reverse this back to '/'
  $flashvars = str_replace('%252F', '/', $flashvars);

$output = <<<EOT

The patch is attached as well.

Enjoy!

i think that audio_query_string_encode() would be the correct place for this fix.

Where is that function? I can't seem to find it anywhere.

ok- now I see it in the latest dev version. My apologies.

I also see the notes in the code about this being a work-around for the issue in core.

Thanks!

This patch worked for me.

The patch worked for me on Drupal 5.5 thanks!

Thank you very much for this patch, it worked for my 5.x-1.0 version on drup5.5.

This patch worked for me, but when I upgraded to the latest 5.x-1.x-dev version from January 30, the "error reading file" came back. None of the players work, not just 1pixelout. I don't think it's a string encoding problem; if I try to load up the play URL directly (e.g., http://cabeki.openleftbox.com/audio/play/341), I get a "page not found" error. I'm running Drupal 5.7.

Thanks for any help.

I've confirmed that this issue does not occur with 5.x-1.x-dev from January 23rd (with the above patch). The 1pixelout player plays the file, and the play URL does load up the MP3 file.

I'm the same boat as CosmicVoyager in #9 above (audio 1.3, Drupal 5.7, then discovered the problem and found this post). I've tried the patch on 1.3, and on the Jan 30 dev snapshot - but don't have recourse to the Jan 23 dev snapshot, so I'm a bit stuck. Has there been any progress on tracking this down? What changed between Jan 23 and Jan 30?

I got things working again with (patched) dev snapshot from 30 January and Drupal 5.7. Don't know how, but the symptoms may be of help to someone sorting this out:

1. The site I was having problems with is just finishing development, so there weren't many content nodes yet and I decided to follow the 'best practices' found in http://drupal.org/node/53705 regarding multisite files and folders in Drupal 5.x and later.

2. Following the instructions in the above post meant changing the file-system setting from the default (files) to the recommended setting (sites/default/files).

**I did have ONE audio node in my development site prior to this, which had been working fine. I discovered that in {audio_files} there is a 'file location' entry for the node, and it seems to hard-code the entire file system path (i.e., it read files/audio/my_audio_file.mp3). So, I manually changed this entry to read sites/default/files/audio/my_audio_file.mp3.

3. The 'error opening file' problem reared its head immediately after making these changes (and yes, I had copied the original /files folder to the new location and re-set permissions so everything was writable).

**I eventually fixed the problem by deleting the audio file (using my ftp client), then editing my audio node and *replacing* the original file with a newly uploaded copy. Now the 1pixelout player works, as does the download. The potential downside: this process re-sets the downloaded and played stats.

So: in my case, at least, manually editing the {audio_files} table entries appeared to introduce errors in the url. I was able to reproduce the problem by duplicating (using Drupal's multisite capability) the site in a subdomain and again manually editing the {audio_files} table entry.

The fact that {audio_file} hard-codes the entire file system, path (rather than building it from the *system's* file-system setting, seems to pose a big problem for those of us working up development sites with the intention of moving them to live sites eventually. I recognise that some screwy configuration of my host's PHPMyAdmin installation is probably the immediate cause of my own issue, but I wouldn't have had to resort to manual database manipulation if {audio_file} was used differently.

A couple of weeks ago, I had a "what the heck" moment, and put back the Jan30 snapshot, and LO! it worked! I couldn't really explain why, and just put it down to bad drugs. However, chiebert's comment above reminded me that I had reorganized my directory structure before retrying the Jan30 snapshot. Previously I had everything in sites/www.mysite.org (modules, themes, files, etc.,). I moved modules and themes to sites/all, and files to sites/default. So it looks like there is something hardcoded in the audio module which only works with the default file structure.

Similarly I had the problem of the old mp3.swf player under 4.7 stopped working after switching to clean urls. I fixed it by adding a line to audio.theme:

$url = str_replace('%3A/%252F', '://', $url);

added immediately after:

$url .= '?'. drupal_query_string_encode($options);