I have an application that uses Paperclip to upload and transform both image graphics (pngs, gifs, jpgs) and video files (flv, mov, et al) in the same ActiveRecord class.
Because I am working with files that need to be processed with ffmpeg, I have written a custom processor to deal with the videos. In the model where Paperclip is implemented, I have a lambda that determines whether the attachment is an image or video, then chooses the processor accordingly.
:processors => lambda{ |a| a.kind == "video" ? [:video_thumbnail] : [:thumbnail] }
Initially, the uploaded attachments are processed and saved as expected. So, I can upload a video file and have the process turn out a jpg thumbnail image of the correct size, or upload a graphic file and have each style turn out as expected. So, I'm at least confidant that ImageMagick (and it's path) and the custom processor are working as expected.
The problem arises when I first upload an image then try to immediately upload a video, or vice versa. When it's image then video file types, I get the standard "identify: no decode delegate for this image format" (Apache error log), "Paperclip::NotIdentifiedByImageMagickError: /tmp/... is not recognized by the 'identify' command." (rails app log).
When it's video then image files, I get an ffmpeg error. Basically, instead of the standard Paperclip processor calling 'identify' (ImageMagick) for a jpg, the video processor is running 'ffmpeg' and trying to do video stuff.
I can upload as many image files as want, in any combination of jpg, png, etc.; I can upload as many movies as I want, in flv, mov, mp4, etc format. But, if I need to switch processors after using one, the other type does not work. And it fails every single time in the production environment: Rails 2.3.5 on with Apache and Passenger 2.2.11 on Ubuntu with ImageMagick 6.5.1-0. This does not ever happen on my local instance of the rails app, on my MacBook but also running with Passenger/Apache/Rails.
There is a simple workaround for the user, which is a shift refresh of the page. At first, this fact baffled me more, but then I realized the refresh caused new PIDs to be assigned to the resource. The Apache log shows the PIDs on refresh or after the idle Passenger apps are destroyed:
Forwarding /mystories/themes/13/edit to PID 31722
I can also see that the same PID from the previous upload, and therefore the same (Passenger) application, is assigned when an upload process fails. On upload of the "wrong" type, the log shows that the failing resource is being sent to the same process id as the previously successful one. It makes sense to me that a new PID forced by the refresh or idle time would then cause the previously failing upload to work, because the failure was actually generated by the wrong command being called.
So, now I'm stumped, because I've run into the roadblock of not understanding whether the Passenger assignment of apps is a symptom or a cause of the problem. I know the basic logic of the lambda works, because a video is sent to the video thumbnail processor and images to the standard Paperclip processor in a "fresh" environment. I feel like I want to blame Passenger for the issue because the destruction of the idle apps also cause a fix of the issue... but I just don't know.
Any insight would be much appreciated.