Jump to:

After upgrading to 6-2.3 from 6-1.3, the player for single mp3s is rendering as Flowplayer3, and doing so with the wrong path. It's trying to read from sites/default/files/sites/default/files - a duplicate path which doesn't exist. It seems to be assuming that the mp3 in a post is mixed media rather than just an mp3.

I see

You are missing some Flash content that should appear here! Perhaps your browser cannot display it, or maybe it did not initialise correctly.

I'm renaming this thread as I have now seen this report in a few places.

For some reason, for some users, the file path to an audio file is being presented as sites/default/files/sites/default/files.

I have never seen this behavior locally, but it is clearly something that is not affecting everyone, but is relatively common. Therefore I am going to use this thread to try and track down why it is happening.

Based on the post above, for this user, things were ok at version 6.x-1.3, but broken in 6.x-2.3. That at least might pin down what code was changed and shed some light on the change.

Please can anyone else being affected by this bug report in this thread so I can try to establish a picture of what is causing the bug to appear.

First I tried installing WYSIWYG API and TinyMCE and it was working ok, although you have to use the [swf] filter format rather than <swf> (but that's ok, the [swf] filter is now working properly. As an aside [] is the preferred Drupal way to write a filter, so I'm going to start promoting that syntax from now)

As a test I tried locally using the swf filter, not in a WYSIWYG editor, but setting <swf file="">, ie passing an empty file. That resulted in the message No player is configured to play a series mixed media files. Check the SWF Tools file handling settings on the configuration page..

If I then do what you have done and configure a media player for mixed media then it tries to render the empty file and I get the player trying to play http://localhost/drupal6/sites/default/files/sites/default/files, exactly the error that is being reported.

So, what does this mean. I think the issue might be related to users that are using WYSIWYG editors that change the input and result in a filter string that SWF Tools no longer recognises. It must be recognising the swf part since it is trying to render something, but it I suspect it is not properly detecting file="somefile". So SWF Tools tries to render an empty file. In turn, SWF Tools doesn't know what to do with a "nothing" so it interprets it as mixed media (so I need to fix it to intercept an empty file to make it clear what is wrong, but park that for now).

The linked thread also suggests that " can be encoded to &quot; and if that is happening then that will break the filter. A patch is provided to fix it.

I simulated this scenario by creating an input filter using &quot; instead of ", and again, I get the error message as the filter doesn't find the file. Using the suggested patch makes it work properly.

I then ran a test using FCKeditor, and without the patch the filter fails. With the new patch it works fine.

So I am now fairly sure that the issue here is the WYSIWYG editors cleaning the code in a way that the SWF Tools processor didn't like.

As this looks like the probable fix I have committed it on branches DRUPAL-5 and DRUPAL-6--2. If people experiencing this issue could pick up the latest code and give it a go I'm very hopeful this will fix your issue.

I have also changed the wording in the help and filter tips to show the filter in the new, preferred [swf] format and I will get round to amending the documentation to encourage use of this format.

The only thing I don't understand is that the filter processor didn't change between 6.x-1.3 and 6.x-2.3!

Please can you post your findings - to me this patch looks good locally so I plan to make a new release very soon, but would appreciate any feedback on whether it works for other users.

In code there are a few calls to file_create_path and file_create_url ... could it be that somewhere a '/' got into the $file which bumps it into the file system.
That could explain the duplication of the file system path.

I seem to be getting this when trying to refer to a manually made (or generated by swf tools) playlist, manually ftp transfered to the playlists directory which refers to files manually ftp transfered to default/files/(directory_name), using the [swf file="playlists/playlist.xml"] command typed in the body of the content. Being a newby, I don't know if this is exactly related, but I see the error in recent log report. Even though error reporting is set to both screen and log file, I don't see the error on the page, just get no audio, although the player seems to show up.

Also, when using [swf files="file1.mp3&&file2.mp3&&file3.mp3"] I do get an error on the page which states "cannot display the player because the file amp; does not appear to exist."

I'm getting this error--with all other input filters turned off with an input profile that does not include a WYSIWYG editor. Has there been any progress on finding the cause, or do I just need to use a different video player?

I am experiencing this same problem. Has anyone found a solution? Instead of 1 pixel out player being called to play my .mp3 file (even thought that it how I have the file handling set up) it tries to use FlowPlayer3. With Flowplayer it can not find the correct mp3 file I am pointing it to. Instead it looks in "sites/default/files/sites/default/files" which is not the path I have set up.

I'm getting this issue as well while creating a Playlist via views in the latest 6.x-3.x dev build (Fantastic work on this BTW). Works in the node as the CCK field. Not sure if this should go here, just wanted to report this though.

@casaswing - do you know what filename you are expecting to be returned from your view? And what are you passing to SWF Tools from Views (what field / from what module).

Looking at the SWF Tools code again the most common cause of this error is going to be because SWF Toos gets an empty string as the filepath. That causes the first "sites/default/files". But the way the function tries to build a valid path it loops through the function again, so it adds another "sites/default/files".

Another cause could be an invalid or bad path. There is a relatively recent change on the dev branch which you may or may not have. I discovered that filefield will pass paths that contain spaces, and this caused one of the validity checks to fail. Spaces are now encoded. I think when I've seen this before the error was due to spaces in the filename.

Note to self / others. The function that is probably doing this is swftools_get_url_and_path($file). The functions takes the parameter $file and tries to return a filepath, and a fileurl.

This function does the following checks:

Check if $file is a valid FULL url. If it is return this as fileurl.

Check if $file is a valid, fully qualified (starts with /) local url. If it is return $file as fileurl, strip the basepath(), and use this as filepath.

Check if $file is in the local file system, and if it is then create a relative url and return this as fileurl.

We now know we have a don't have a relative url to the file system (we probably have someFilename.xxx). If a remote media path is set then build a url using it and return that as fileurl.

At this point we conclude $file is not a full url, it is not a fully qualified local url, it does not point to something in the file directory, and it does not refer to remote media. So we now try to MAKE a path that points to the local file system, and we call the function again to try and get a result.

This is how SWF Tools handles the case of $file="mySWF.swf". On the first pass it gets built in to a path to the local system on the first pass, and is expanded to a proper url on the second pass.

This relies on the Drupal function file_create_path($dest). This returns the file system path if $dest equates to false (the function tests for !$dest). So an empty string would satisfy that condition and cause the files directory path to be returned.

If the SWF Tools function were passed a "bad path" then this would fail all checks on the first pass, it will call file_create_path($file), and that could return FALSE. That result is looped through the function again. All checks fail but this time file_create_path($file) will return the directory path since !$file is true. A third pass would result in the "double" reference to the files directory.

I'm passing FLV files named Real8mmTest.flv, via a CCK file field with a Display Type of SWF Tools - No Download Link. So in the node itself, the video is playing fine (some playlist items are showing up on the node, but the video is playing).

In Views, I'm calling the file field itself (Not the data or the delta). Much like the other reports earlier, Its treating the field as a Mixed Media type and through Firebug, while the CCK field picks up the file and the file name, the views field does not, I will send screenshots when I can.

I'll read through what you wrote and check with my build to make sure things are in order. If it seems like I'm doing anything wrong, please let em know. Thanks.

I reviewed the file paths for my build. I had some underscores before, but no spaces, so I reloaded the videos with no underscores, Video names were like...

testvideotwo.flv

Same results, Still s/d/f/s/d/f path.

I still have the latest dev on the page (dated 4/14/10) and I see that the function swftools_get_url_and_path($file) replaces spaces with a %20. No spaces on my filenames.

I have attached a small zip package with some screenshots. One with the Page Display type of Unformatted (where the Video Works) and one with the Page Display type of SWF with the settings field exposed. In addition, I have the front end source code being generated for these displays. I have screenshots of the Front End Display and the Views UI for this view and display. Not sure if this is going to help, but thought it may be useful. Front end is a mess becuase I haven't gotten to do much with it.

Problem is valid_url is too strict; it does not allow spaces. swftools_get_url_and_path means 2 things. It gets a valid URL and valid path. due to url encoding these 2 strings may not be the same; thus they need to be treated differently. Patch makes this work for me.

I have tried both mikeytown2's patch (thanks!) and unpatched versions with clean urls both on and off: the error still persists. The players still cannot access the files: I've tried feeding null "", xspf playlist (in the default - ie. site\default\files dir), and mp3s both singly and in lists. Every argument fed to the input filter makes it believe that I want to load a list of files. I've tried this with both a player defined for the list type, and none selected. When one is defined, the player loads and has no access to the files, when one is not defined it demands that I select a player to handle a list of mixed media. I have tried overriding the player using methods="someplayer", and the player overrides properly, but irrespective of the player tried (Flowplayer3, WPAudio, XSPF Player) there is no on-server access to the files.
Has anyone managed to get around this with the dev version? Or managed to get playlist working through php?

Even though no player works through the java input filer, I can still successfully call a single mp3 to play through

<?phpprint swf('somesong')?>

, though feeding an xspf playlist causes the player to load and believe that I want to stream the files local to my server.

I am having this same issue (/sites/default/files/sites/default/files), and I would say its a pretty major defect as all this video content is now not displayed just out of the blue. I think this should be looked at fairly urgently.

Hey Mike... I tried to replace that file.. cleared caches etc.. but still same issue.... its a very strange prob.. cause if I reupload the vid it will work for a little while... then all of the sudden out of the blue.. all the vids on site go to that wierd url sites/default/files/sites default/files...

It's really hard to debug if I can't repo your issue.file_directory_path() is the function that generates sites/default/files/. Found in swftools_get_base().

In order to debug start picking apart swf(). Good luck. I will say that swftools_get_url_and_path() is where the error is most likely as my patch fixed this for me; as this is where I ID-ed this last time.

Trying to get playlists working for a series of .flv files and I have the same problem. I've set up a content type and used File Upload and the individual videos play fine (if output is set to SWF Tools), but when I try to use a series of them in a playlist (using Path to file as output) I get the following error:

I'm currently working in a sandbox environment where my test sites are located as http://xx.xxx.xx.xx/[site] - but still, the base URL should work correctly. I see others have encountered the base URL issue (I've encountered it in another context here: http://drupal.org/node/1030482) - any suggestions? Thanks much!

In my case (with swftools 2.5/flowplayer3 and video 6.x-4.2-beta2) it turned out to be caused by video.module passing image path already containing 'sites/default/files/' and swftools prepending it again in flowplayer3_swftools_flashvars()

<?php// If an image was supplied to be the splash then put this first in the list // This code doesn't seem to be working - the player objects to { url: '' }if (isset($vars->othervars['image'])) {$playlist[] = array(// Get url, checking for file existence, and using a relative url if possible.'url' => swftools_get_media_url(swftools_get_media_path() . $vars->othervars['image']),'autoPlay' => 'true', ); }?>

@Stuart
I too am having a similar problem (path = "sites/default/files/sites/default/files") and none of the solutions suggested above has worked for me.

My problem occurs within views, when I:
(a) select style = "SWF Tools", and
(b) set my field display to "path to file"

It seems that filefield is generating the correct path:
If I change the views style to "unformatted", and leave the field display as "path to file", then my view displays the correct paths, eg "sites/default/files/flv-1.flv".

In an effort to see whether some other module was causing the problem, I created a very basic drupal installation, with a minimal set of modules. Unfortunately, the problem did not go away. I will describe my minimal installation, in the hopes that this will help you reproduce the problem.

Libraries
=====
I added flowplayer to the library: sites/libraries/flowplayer3/flowplayer-3.2.7.swf
I added swfobject2 to the library: sites/libraries/swfobject/swfobject.js
I am attaching a zip of my libraries folder.

Settings
=====
I made these changes to the default admin/settings/swftools settings:
-- embedding method: swfobject2
-- flowplayer3 player: flowplayer-3.2.7.swf
-- file handling: flowplayer3 for all options
-- swf tools cache: disabled
For all other modules, I used default settings.

CCK
===
I created a "media" node-type with one filefield-type field, "myvideo". I used the default filefield settings.
I created two media-type nodes, each containing one uploaded flv file

Views
====
I created a view with one field and one page display.
Field:
-- I added the "myvideo" field, with display = "path to url". All other settings are default.
Page display:
-- I added a page display, and set style to "SWF Tools", with default settings

I added some debug code to swftools and discovered a problem that may help explain the "sites/default/files/sites/default/files" problem.

The template file:views-view-swftools.tpl.php
calls this function:swftools_views_add_playlist_element(&$files, $key, $options, $work)
which is supposed to fill $files with the playlist information. In particular, this function is supposed to fill the filepath:$files[$key]['filepath'] .

Just to confirm, I am experiencing the same issue. Tested in clean installs and pre-existing players in the beta stream and the issue appears to persist regardless of how clean the Drupal installation is. I suspect the latest comment above is on the right track... still testing on this end.

More for documentation sake as it doesn't help much but this is what I find in the Drupal error log each time the player (JW Player 5) loads:

I'm getting the same issue. I've created a simple view (output last ten mp3 files, only one field : file - not data -, Path to file format, style SWF Tools) and I get the following error when I go to the page of the view:

Spent the last week trying to get SWFtools and Flowplayer3 running on D6.28 just to play a simple MP3 audio file on a static page using inline embedding, no views, no filefield, just swf file='myfile.mp3' and using the SWFtools input filter, and the error sequence outlined in post #58 still happens. Installation is SWFtools 6.x-2.5 and Flowplayer3 3.2.16. Can this actually be the case on an issue that was originally created March 13 2009??? Pardon my rudeness but WTF? Ordinarily I'd be glad to post additional info, full version and installation details, blah blah but this is kind of ridiculous. OTOH if this is a dead issue, nothing to see here move along citizen, that's ok too but would love some advice on a currently working solution to simple playback of sound files (mp3) on D6. Client is a non-profit and we're trying to get ready for the move to D7 but will that help either? BTW if I use double quotes on the mp3 filename I get the does not appear to exist error. I've also created the (duplicate) directories so /sites/default/files/sites/default/files does exist on the site and has a copy of the mp3 in it as well. Didn't help.
Regards,
H. Johnson
Metadata Labs