Posted by sime on February 13, 2010 at 2:06pm
5 followers
Jump to:
| Project: | FlashVideo |
| Version: | 6.x-1.5 |
| Component: | CCK Plugin |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
At about line 416 of the flashvideo.module you have this:
<?php
// They want to use the video thumbnail as the intro image.
$video['flashvars']['image'] = check_url(preg_replace("/\.flv|\.mp4/", ".jpg", $video['file']));
?>My CCK field that is storing the thumb (files/flashvideo/thumbs) is using a different path to flv (files/flashvideo/flv). The line above means that this fails, it expects my thumb to be in the same directory.
Comments
#1
Good catch sime.
Yeah, what this is doing here is taking a best guess what the intro image should be. This works fine for the non-File field module, but seems to break the FileField implementation. I assume that you are using FileField? If this is the case then I plan on fixing this once I can find enough time to fix some of the other FileField path related issues.
Thanks,
Travis.
#2
No worries travist. I'm working around it happily.
I notice looking through the code a lot switch() statements between filefield and upload module support, definitely can get a bit hairy. Can't wait for D7 when there is a standard model for files in core!
#3
subscribing
#4
In case anyone is interested, I posted a potential fix for this as part of the monstrous patch I posted in #811844: Adding MP4 (H.264) encoding options (+ bug fix / feature req notes)
My proposed solution goes something like... call flashvideo_get_thumbnail from within flashvideo_get_video and save that as $video['thumb'] to be used by the flashvars
Since within flashvideo_get_video we know the parameters we need to get the thumbnail, this seems easier than fixing it in the flashvars directly...
if someone is interested in further cleaning it up, the relevant parts should be:
(this is just a direct copy of the relevant parts of that patch - and it's still not completely clean, most of the changes around 455 could be stripped out and/or simplified)
Index: flashvideo.module
===================================================================
--- flashvideo.module (revision 1.73.2.118)
+++ flashvideo.module (working copy)
@@ -413,7 +413,7 @@ function flashvideo_get_flashvars($video
else {
// They want to use the video thumbnail as the intro image.
- $video['flashvars']['image'] = check_url(preg_replace("/\.flv|\.mp4/", ".jpg", $video['file']));
+ $video['flashvars']['image'] = $video['thumb'];
}
}
@@ -455,8 +455,9 @@ function flashvideo_get_flashvars($video
}
// Set up the markup and actual data arrays.
- $markup = array('@video', '@thumbnail');
- $actual = array($video['file'], check_url(preg_replace("/\.flv|\.mp4/", ".jpg", $video['file'])));
+ $markup = array('@video', '@thumbnail', '@filename');
+ $video['file'] = str_replace('@filename', basename($video['file']), $video['file']);
+ $actual = array($video['file'], $video['thumb'], basename($video['file']));
return str_replace($markup, $actual, $flashvars);
}
@@ -2172,6 +2192,7 @@ function flashvideo_get_video_object($no
}
}
+ $video['thumb'] = flashvideo_get_thumbnail($node, $params, TRUE);
return $video;
}
#5
Does that work? I know I applied your mega-patch, but I haven't seen thumbnails start to work. I'll double check. I think I'm still getting DB entries with a double // (or was it \\?) in the image path. I was eventually going to hunt down the issue. May be a Windows thing.
#6
Paths being incorrect in the DB is going to be a separate issue of some sort...
Essentially, this particular subsection of my mega-patch relates only to the actual display of thumbnails, once they are stored correctly in the DB.
It just makes flashvideo_get_video_object return the value of flashvideo_get_thumbnail in $video['thumb']
So, if your DB paths have a double // in them, not just your display paths... well, there are a few things that could be causing this that I can think of:
A Windows problem should not be considered out of the possibility - I'm running and testing everything on linux...
Could be an incorrect directory separator related to windows, or maybe even an escaping problem in the SQL query?
I'm run everything on linux/pgsql and haven't done any testing on other environments...
If you're up for debugging, I would suggest inserting dsm statements and figuring out when exactly the image path becomes corrupted - chances are pretty good it's somewhere in flashvideo_convert
Are you using FileField with tokens? If so, this may be related: #812510: Proper token generation for FileField paths without 'Convert video immediately'
(and the patch in there breaks importing without the followup: #812562: Making flashvideo_import respect FileField path settings for original video)
There's also a few other issues related to FileFields that may be applicable... like #481116: Removing a video and re-attaching it does not work when CCK options are in use might also be related...
There's some CCK permissions stuff at #453722: Field to specify thumbnail time on video upload that might be related too...
And if I remember correctly, the 1.x-dev version contains a change that relates to this as well, having to do with path selections...
#7
+1
#8
yeah, my issue ended up being that i forgot to specify a folder under the files directory for the filefield i'm using to store the thumbnail.
i thought that by leaving the field blank, the files directory would be used. seems a folder needs to be specified.
so if anyone else is using filefield in conjunction with flashvideo, make sure you specify a subfolder in your files folder to hold the images. of course, it could either be the same or different than the one you store your videos in.