Ticket #494 (closed defect: fixed)
Zope ftp rejects m4v files coming from plumiftp
| Reported by: | mike | Owned by: | |
|---|---|---|---|
| Priority: | major | Milestone: | 4.1 RC 1 & EM Staging Update |
| Component: | VideoUploading | Severity: | |
| Keywords: | Cc: | ||
| Who will test this: | And |
Description
We should find the cause of this and provide a workaround in plumiftp.
Attachments
Change History
comment:2 Changed 3 years ago by anna
- Milestone changed from 4.0 RC 1 to 4.0 RC1 EM Update & Tickets
comment:3 Changed 2 years ago by anna
Would test this but can't get FTP to work just yet (see EM tracker).
comment:4 Changed 2 years ago by anna
Hmm, came to test this today and got this error while trying to connect via FTP (using Cyberduck on Mac):
FTP Error: Data connection already open. Transfer starting. Data connection already open. Transfer starting.
comment:5 Changed 2 years ago by mike
- Status changed from new to closed
- Resolution set to ready for testing
This(the error) is a cyberduck bug: http://groups.google.com/group/pyftpdlib/browse_thread/thread/c9adfbd85d6d350c
The "Data connection already open. Transfer starting" is not an error but cyberduck mistakenly thinks it is and bails out. I can connect with gftp without problems. Can you try with another client?
comment:6 Changed 2 years ago by anna
- Status changed from closed to reopened
- Resolution ready for testing deleted
Just tested with Filezilla. The FTP connection worked fine, have uploaded video (m4v file) but this has not appeared in /videos folder yet.
The file is called "lepidopter-trim-desktop.m4v". It disappeared from the FTP directory into which it was uploaded, but when I view this page I can't see the file: https://www.engagemedia.org/Members/anna/videos/@@folder_contents?pagenumber=1&sort_on=getObjPositionInParent
comment:7 Changed 2 years ago by anna
- Milestone changed from 4.0 RC1 EM Update & Tickets to 4.1 Beta 1
The file still hasn't appeared in my folder, so I'm assuming this error with m4v files is still present. However I'll bump this to 4.1 as 4.0-final has already been released. We should just note this as a known issue, and resolve it in 4.1.
comment:8 Changed 2 years ago by anna
Oddly I just tested again with Cyberduck and i uploaded files (other than m4v) successfully, which then appeared successfully on the site. Was going to make a note in the manual not to use Cyberduck, but it seems the problem only came up once.
So yeah, only remaining problem seems to the original issue - m4v files aren't picked up and processed.
comment:9 Changed 2 years ago by and
- Milestone changed from 4.1 Beta 1 (New Features and Fixes) to 4.1 RC 1 & EM Staging Update
comment:10 Changed 2 years ago by mike
- Status changed from reopened to closed
- Resolution set to ready for testing
Fixed in demo.plumi.org and reported the issue upstream (on zope.contenttype) for a proper fix.
comment:11 Changed 2 years ago by and
Just double checking if it's at demo.plumi (as that is a little unusual) or is it at testing? Just so I know i'm checking the right thing.
comment:12 Changed 2 years ago by mike
It's at demo.plumi.org since it is a production setup (with FTP). Testing is a dev setup. We just updated that code locally and restarted the instance, so we didn't have to upgrade demo. For reference, the issue was solved and a new zope.contenttype version has been released with the fix: https://bugs.launchpad.net/zope.contenttype/+bug/717289
comment:13 Changed 2 years ago by and
- Status changed from closed to reopened
- Resolution ready for testing deleted
Cool. Worked when I tested. Closing.
comment:14 Changed 2 years ago by and
- Status changed from reopened to closed
- Resolution set to fixed
with the new ploneftp product and the latest zope this doesn't seem to be an issue anymore. I'll leave it open just to test it on staging.em.org once we start the migration and close it afterwards.