Help with use

I'm not sure if an admin user is in the authenticated category or some other separate one ut I ran cron as admin. Downloads are set to public. However, the log is revealing some information that I did not include in the first post (sorry I'm a bit noob at some of this).

Type tracknstack
Date Wednesday, July 20, 2011 - 04:07
User Juryiel
Location http://localhost:8082/admin/reports/status/run-cron
Referrer http://localhost:8082/admin/reports/status
Message Cannot apply replay-gain on sites/default/files/tracknstack/3-13111311411.wav
Severity notice
Hostname 127.0.0.1
Operations

Sounds cron-related too

Aha! I located teh download issue but not sure how to solve it. I'm using port 8082, so the link should look like:

http://localhost:8082/?q=tracknstack/download/10

instead, it looks like:

http://localhost/?q=tracknstack/download/10

without the port. if I put the port in there it works, but not sure how to make that automatic or to autodirect everything to that port. I wonder if the second problem is related to this as well.

EDIT: I temporarily set the port to default (80) for testing and though this does fix the downloading issue as demonstrated before, I still get the same errors about cron and stuck in Processing mixdown status.

Files with those types of names do exist. I tried running WaveGain on one of them (1.30) with the -g switch and it worked just fine. Could it be an issue with directory structure or some such? Also, where does WaveGain output files if I don't specify? I saw that Analysis of wave gain showed a higher gain after I applied a gian of 5 to it, but this does not appear to have been written to the file itself

Tried disabling wavegain and now sox gives this error:

Details

Type tracknstack
Date Friday, July 22, 2011 - 02:06
User Juryiel
Location http://localhost:80/admin/reports/status/run-cron
Referrer http://localhost/admin/reports/status
Message Cannot create wav mixdown (nid: 5; SoX status: 1)
Severity notice
Hostname 127.0.0.1
Operations

Ah I see, in that case WaveGain is working fine from command line. Well it seems that it isn't an issue specific to WaveGain in this case since SoX also fails when I remove WaveGain. The status is 1, and going by the Sox documentation:

"Exit status is 0 for no error, 1 if there is a problem with the command-line parameters, or 2 if an error
occurs during file processing."

So I guess some issue with the command line parameters? I have both WaveGain and SoX installed within the drupal site such that if the folder the site is located in is /drupalroot/ then the software is in /drupalroot/nondrupalstuff/sox/ etc. I'm mentioning this because I've had issues with this sort of stuff before where software needed to be outside of the site or in specific locations, etc.

Any more ideas? Thanks for your help so far btw :)

I'm using Sox version 14.3.2 and using standard wav files, which are supported. Hmm, I wonder what could be going on then. I don't think it's an issue with the programs themselves. The programs actually run from command line on those files just fine.

Also, the SoX error status was 1. An issue with teh files themselves during file processing would give a status of 2, whereas 1 seems to mean there is something wrong with the command line stuff entered, which is what made me think of directory issues. Not in so much that sox itself is in teh wrong directory but perhaps SoX in relation to the directory of the files. But it could be something else related to the command line. Could you show me what command is used to call SoX by the module specifically? I think looking at that will help me resolve the issue but I'm not sure where to find it.

I'm currently attempting to reprogram the module to output all of its command calls to sox on the webpage screen so I can see what is going on as it is hard to follow all teh variables in the .module file. I'll let you know how this goes, but it will take me a bit of time. Hopefully this will help track the problem down though.

I think I found the issue.

The command you posted above works great. Unfortunately, the command printed out when I do print($fullcmd) is instead:

/soxmix input_files output_file

There's no such thing as soxmix in my directory, but doing sox -m in command line works

EDIT: Ok apparently putting -m instead of soxmix doesn't work, what I meant was that instead, if I put this command in the script:

exec('D:\DAMP-Stack\Sites\acquia-drupal\nondrupalstuff\sox-14-3-2/sox -m D:/DAMP-Stack/Sites/acquia-drupal/sites/default/files/tracknstack/3-13111311410.wav D:/DAMP-Stack/Sites/acquia-drupal/sites/default/files/tracknstack/3-13111311411.wav D:/DAMP-Stack/Sites/acquia-drupal/sites/default/files/tracknstack/3-13111334110.wav D:/DAMP-Stack/Sites/acquia-drupal/sites/default/files/tracknstack/3.wav');

then the files get created just fine.

The original output of the $fullcmd from the default module instead gives this when I do a print

"D:\DAMP-Stack\Sites\acquia-drupal\nondrupalstuff\sox-14-3-2/soxmix" "D:/DAMP-Stack/Sites/acquia-drupal/sites/default/files/tracknstack/3-13111311410.wav" "D:/DAMP-Stack/Sites/acquia-drupal/sites/default/files/tracknstack/3-13111311411.wav" "D:/DAMP-Stack/Sites/acquia-drupal/sites/default/files/tracknstack/3-13111334110.wav" "D:/DAMP-Stack/Sites/acquia-drupal/sites/default/files/tracknstack/3.wav"

which I guess for whatever reason doesn't work when I do exec($fullcmd). I don't really get it but I'll keep messing with it

Furthermore if I define:

$fullcmd2='D:\DAMP-Stack\Sites\acquia-drupal\nondrupalstuff\sox-14-3-2/sox -m D:/DAMP-Stack/Sites/acquia-drupal/sites/default/files/tracknstack/3-13111311410.wav D:/DAMP-Stack/Sites/acquia-drupal/sites/default/files/tracknstack/3-13111311411.wav D:/DAMP-Stack/Sites/acquia-drupal/sites/default/files/tracknstack/3-13111334110.wav D:/DAMP-Stack/Sites/acquia-drupal/sites/default/files/tracknstack/3.wav';

and then I do print($fullcmd2)

I get:

D:\DAMP-Stack\Sites\acquia-drupal\nondrupalstuff\sox-14-3-2/sox -m D:/DAMP-Stack/Sites/acquia-drupal/sites/default/files/tracknstack/3-13111311410.wav D:/DAMP-Stack/Sites/acquia-drupal/sites/default/files/tracknstack/3-13111311411.wav D:/DAMP-Stack/Sites/acquia-drupal/sites/default/files/tracknstack/3-13111334110.wav D:/DAMP-Stack/Sites/acquia-drupal/sites/default/files/tracknstack/3.wav

Which is to say, there are no quotes between each file as there are with print($fullcmd). Somehow this is causing an issue, because again, exec($fullcmd2) works. More to come as I mess with it.

Ok, some findings:

If I replace the following:

/soxmix with /sox -m

and add the following line to remove the quotes before each time an exec($fullcmd, $output, $result) is called:

$fullcmd = str_replace('"','',$fullcmd);

Then the mixdown processes correctly and the file gets created. I'm going to guess the issue with WaveGain is similar. Any thoughts as to why this might be?

Sorry for all the posts. I'm also having another issue. The jPlayer won't load. There seem to be some problems. First off, in drupal 6, you cannot use drupal_add_js to load external javascript files I believe (e.g. the jquery you're using from google). Note that when you do that it's adding a / before the http. Instead you have to use drupal set html head: http://api.drupal.org/api/drupal/includes--common.inc/function/drupal_se... (maybe this was updated and I don't know). However, even with that, it still won't run. I tried jPlayer 1.2.0 and 2.0.0

Second, swfPath assumes that stuff is in http://site/sites/default/files/, such that if it's in http://site/stuff/jplayer/ instead, you get this:

swfPath: "http://localhost:80/sites/default/files/stuff/jplayer"

I changed the line $jplayer_url = file_create_url($jplayer_path) to:

$jplayer_url=url($jplayer_path) to deal with this but that has its own issues. For whatever reason it's not recommended to use this for css or js headers (see http://api.drupal.org/api/drupal/includes--common.inc/function/url/6#com...) but I don't understand enough to figure out why, seems to work for thsi particular case.

Still, the player won't load yet, so I'll keep looking around to find out other possible reasons.

Great, I'll give it a shot when it's released, and in the meantime I'll try to solve the jPlayer issues I still have. Just to clarify about the quotes: for whatever reason, when I have the quotes tehre it doesn't work, that's waht was causing the mixdown to fail. I know it's common for windows paths to use quotes when there are spaces, but maybe this is not supported by sox. So while I don't have a suggestion on how to deal with spaces in the path (I'll keep looking for one) on windows 7 at least, leaving the quotes in there prevents sox from finding the wav files specified.

Ok here's some additional info.

1. The reason the version check is not working is because $result is 1 when the file soxmix is not found (which coincides with a $result of 1 when the file is indeed found but there is a problem with the command line parameters). $result will vary from program to program and OS to OS so maybe that's not the best check to do. Instead, why not check if the file soxmix exists? Or, better yet, soxmix has been deprecated so the proper thing to do is to simply require everyone to use the latest version of SoX. Alternatively, perhaps using the command sox --version and going from that, however, take note that if you go even further back in sox (e.g. 12.17) there is again a lack of soxmix (at least on sourceforge). Soxmix seems to only exist between versions 12.18 and 13, so I really do think the best bet is to simply require an update to the latest version of sox instead of doing a check.

2. The issue with the quotes seems to be the -m. Command line arguments need to be outside quotes and the way I was replacing /soxmix with /sox -m it was keeping it inside quotes. So you'd do something like "D:\path\dir with spaces\sox\sox" -m "D:\stuff\file1" "D:\stuff\file2"

Hope this helps

There are several reasons the player fails in windows. Here they are (I was able to fix it)

1. For whatever reason (i don't know why) the jquery.jplayer.min.js script does not seem to like the leading "/" in the SRC. For example, if the player is under drupalroot/nondrupalstuff/flashPlayers/jPlayer, then:

script type="text/javascript" src="/nondrupalstuff/flashPlayers/jPlayer/jquery.jplayer.min.js?v"

will NOT work but

script type="text/javascript" src="nondrupalstuff/flashPlayers/jPlayer/jquery.jplayer.min.js?v"

WILL work. I don't understand this, because clicking on the first src link with the / will find the script just fine.

2. Similarly, the line:

script type="text/javascript" src="/http://ajax.googleapis.com/ajax/libs/jquery/1.6/jquery.min.js"

will NOT work, but the line:

script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.6/jquery.min.js"

does work (this actually makes sense). I'm not sure if you updated that in the new version, I will test it soon, but i mentioned it in a previous post.

3. To display the player in HTML5, you need the appropriate CSS file included for the skin, as well as teh graphics files for that CSS file. For example, for the player on the tracknstack site you'd need to include:

link href="jplayer.blue.monday.css" rel="stylesheet" type="text/css"

as well as the jplayer.blue.monday.css file obviously.

You also would need the file jplayer.blue.monday.jpg which you can get from jplayer's website. This image file contains the buttons and player images.

It might be a good idea to add a jPlayer Skin CSS field in the module settings where files like jplayer.blue.monday.css are included, since jplayer's HTML5 version is drawn using CSS files. And it might also be good to include the default jplayer.blue.monday.css file and the jplayer.blue.monday.jpg file as a default skin.

***EDIT: Sorry I made a mistake, the first item on the list was not an issue, just an issue on my part. However, I found another item that matters. ****

script type="text/javascript" src="/misc/jquery.js?v"

This line needs to be removed if you use drupal_set_html_head to load the jquery.js script from google's server. In other words, if you make the change in 2, the new jquery will load first, then the older version in drupal 6 will load overriding the new 1.4 (or 1.6 in my case) version. This version is 1.2.6 and will not be sufficient to run jPlayer.

OK, I was able to fix the player in version 2.7 of the module by downloading the jquery.min.js file from google to jPlayer's path and replacing the line:

drupal_add_js('http://ajax.googleapis.com/ajax/libs/jquery/1.4/jquery.min.js');

with the line

drupal_add_js($jplayer_path . 'jquery.jplayer.js');

drupal_add_js is unable to load external js files, while drupal_set_html_head does allow loading external files but loads before drupal_add_js, and later drupal_add_js loads drupal's default jquery version 1.2.6, overriding the new version and causing the player to fail.

I'm not sure what other solution there is until drupal upgrades jquery =/

But note, that in your -m implementation you still put the -m inside quotes, which does NOT work. The command needs to look like this:

"C:\path\sox" -m "C:\path\file"

Right now it looks like

"C:\path\sox -m" "C:\path\file"

My settings are fine, the issue I have is not with loading the player, but with making it work. Without the jquery.min.js file this doesn't work on jplayer version 2.0.0, because drupal's jquery.js is an old version. I can get the player to work great so long as I include an updated jquery. Maybe you are using the jQuery module with an updated jquery version?

Right, but the link to google api is not working on my end

If you read the documentation of drupal_add_js function, it states that it does not work for external .js scripts. Accordingly, on my server, it adds a backslash to the beginning of the google api link, which breaks it. I worked around this issue by downloading the google api jquery script and loading it up locally, but the module as-is does not work for me in terms of loading the google api jquery.

Note that this is only true for drupal 6. drupal 7 allows drupal_add_js to load external .js scripts.

It could be also that the browser you're using is defaulting to the Flash option, thereby making jquery irrelevant.

I also found yet another issue. IE9 does not support wav or ogg in html5 audio tag. Supposedly it will only support ACC codec (.m4a, .m4b, .m4p, .m4v, .m4r, .3gp, .mp4, .aac) and Mp3 formats. Is it possible to get something like m4a support for the HTML5 versions of jPlayer in IE9? Alternatively, a "Force jPlayer Flash version" would be welcome, which would force jPlayer to run in Flash mode in all browsers, so that it can support more formats than the audio tag of a given browser. This can be trivially done by setting the option nativeSupport:false in jPlayer options.

Ok I figured out the exec($fullcmd) problem for windows finally:

you have it mostly right but you need to add double quotes around the entire $fullcmd after you add double quotes to each of the paths, so I just added:

$fullcmd = '"' . $fullcmd . '"';

before each exec($fullcmd) and it works now. Not sure if this works in other OS like linux though.

See this post http://www.php.net/manual/en/ref.exec.php#80721

Just so you and other users know that although I fixed it on my end, this is actually not fixed in Windows 7 with module version 2.7 using Apache server. I outlined the fix (tested in Windows 7 system) in post #28 for anyone who needs it but as I am not an experienced developer and don't have a linux server, I cannot say whether my fix works for that. Thanks for the awesome module by the way.

Unfortunately I can't post a patch because I also made other changes to teh module on my end adding ffmpeg use for webm support, and it is currently incomplete.