Cron is trying to upload non-existing videos [caused by the filefield decoupling]

Should be fixed in the latest commit. I simply changed the default video status for browser upload method to 'unknown', which is the step after 'upload_pending'. Only upload_pending videos are uploaded during cron.

I was dealing with this today. I determined the following (forgive me if this is all known/obvious).

- A single, empty entry is created in the CCK field table for when creating a node with a video_upload field.
- The same behavior is present in Filefield, so this is either a bug in Filefield that video_upload is also affected by, or it is something inherent in CCK.
- This field is, by default, getting the status "upload_pending" because that is the default status for a blank video_upload field, and/or because that is defined as the default value in the DB columns. This triggers the erroneous upload.

I made a quick hack for my site, which will only attempt an upload if an fid is present, but I will investigate a proper fix, and will try to see whether other CCK modules exhibit the same empty entry behavior.

I was just looking through the Filefield module, and noticed the following inline notes for hook_content_is_empty:

* The result of this determines whether content.module will save the value of
* the field. Note that content module has some interesting behaviors for empty
* values. It will always save at least one record for every node revision,
* even if the values are all NULL. If it is a multi-value field with an
* explicit limit, CCK will save that number of empty entries.

Thus, it seems as though this is a CCK behavior, and the best solution would be to ensure that those empty records do not have the upload_pending status set.

@bojan
I've attempted to debug by doing a side by side of pre-patched and post-patched states. They return different objects, pre-patch being delta=NULL, and post-patch being the item columns, as you identified. However, I can get exactly the same output from the patched state (delta = NULL) by adding a return; to the update hook (which is the only difference vis-a-vis the filefield integrated method).

I believe the problem here is that the default value of "video_status" is being set to "upload_pending" in video_upload_field_settings(). If I create an empty record directly on this table, no Drupal involved, it will take the upload_pending value. I believe this is the heart of the problem.

I haven't yet managed to figure out patching yet (I will!) but here's what I did:

video_upload_field_settings_alter()
'video_status' => array(
- 'default' => VIDEO_UPLOAD_STATUS_UPLOAD_PENDING,

video_upload_field_settings()
'video_status' => array(
- 'default' => VIDEO_UPLOAD_STATUS_UPLOAD_PENDING,

I don't see any reason that those columns would need that status as a default, as it seems like the widget, and various functions should be where the status is set. I don't think any functions depend upon status being not NULL (correct me if I'm wrong).

Then, the part that hung me up, was that after doing this, and manually altering my DB to reflect the new schema, I was still getting upload_pending inserted. Debugging my way through every place where that could have been inserted, I finally realized that my schema was cached. I deleted and recreated the field, and the problem went away.

A proper patch would, I think, include the DB update functions for .install.

When you upload a video file (direct method) won't you be submitting a CCK item array that now contains a valid item? It would contain an FID, get a false from hook_content_is_empty, and therefore, would be recorded with the video_status set on the form, which in this case, would be UPLOAD_PENDING. This would also make sense, you would only be recording items for UPLOAD_PENDING that actually have had a file uploaded.

Then in the case of the browser method, you would never have a video at state UPLOAD_PENDING, as it has passed that state from the beginning.

Most of my efforts have been concentrated on the browser method, but I'll ensure that my set up is working correctly on direct upload and post shortly.

@bojanz
I can confirm that the direct upload method is working correctly with the changes outlined above.

As to why the decoupling patch seemed to be the cause of the problem, no idea. Perhaps it had something to do with DB schema being cached from a working to non-working state?

Or, perhaps, before that patch content_is_empty was incorrectly returning false, leading to the record saving an empty string for video_status, which would cause the DB default value not to be invoked?

Here's my (first!) patch. Let me know if it seems to help.

Why is checking for the fid not a proper fix? I have the same issue, and cannot use this module till the issue is fixed. Will checking for the fid fix the problem in the mean time, or should I wait for a proper fix?