Welcome, Guest
Username: Password: Remember me

TOPIC: QNAP Copy Bug

QNAP Copy Bug 19 Dec 2018 20:51 #98231

  • nate.haustein
  • nate.haustein's Avatar
  • OFFLINE
  • Fresh Boarder
  • Posts: 16
  • Thank you received: 1
  • Karma: 0
We’re using a Qnap TVS-871T running 4.3.6.0776. Since 4.3.5 or so, we’ve noticed a peculiar bug involved with Final Cut Pro X and copying media.

First, the issue. When attempting to import media from a drive, be it one volume to another or a copy from the same drive into Final Cut, and the FCPX import preference is set to “Copy Media to Library”, media will remain half-copied, showing up blank in the timeline or browser. Upon investigating the file in Finder, the file will either: 1. Have a .fcpcopy extension added to the end, or 2. retains its name but hitting return to rename the file reveals a .fcpcopy extension. Upon removing the .fcpcopy extension in either case will result in the media becoming available again in Final Cut after a restart of the software. This behavior is exhibited both on audio and video, but seemingly not on still photos. It’s worth noting that if the FCPX import preference is set to “Leave Files in Place”, the media will behave correctly upon first import, but upon consolidation, it will also exhibit the same behavior as the “Copy Media to Library” setting.

We have dubbed this behavior “The Copy Bug” and it’s really interrupted our workflow. It also seems to affect timeline renders; any rendering that occurs will work at first and the render files will be present if the Library’s contents are explored in Finder, but upon FCPX restart, the timeline becomes unrendered. The files will remain in Finder, but any attempt to render again just adds new render files. It’s like it forgets. While we’re fortunate it’s not deleting our media or anything, it’s a nuisance that it happens every single time we drag footage into our projects. (This issue does not affect media imported from cards.

Next, some specs. We’ve noticed this behavior in both High Sierra and Mojave, so it doesn’t seem to be OS related but we understand it still might be. We’ve tested various versions of FCPX and it still occurs. We mount our Qnap raid using Qfinder’s particular Final Cut NFS format. One computer is connected directly via thunderbolt, 2 others are using thunderbolt to Ethernet adapters; the issue occurs regardless of connection. We believe the issue to exist somewhere in Qnap’s settings.

Interestingly, the issue does not seem to occur when mounting via SMB. However, this raises a new concern: FCPX libraries modified while on NFS will not open on an SMB mount, citing a permissions error. However a freshly created FCPX library will operate just fine in SMB.

Our question is twofold: what is causing this copy behavior to occur on NFS and how can we fix it, or alternatively, if we need to switch to SMB (which may be more beneficial in the long term), how do we prepare our media for the change from NFS to SMB?

Thank you in advance.
The administrator has disabled public write access.

QNAP Copy Bug 24 Dec 2018 10:43 #98290

  • ronny courtens
  • ronny courtens's Avatar
  • OFFLINE
  • Moderator
  • Posts: 4195
  • Thank you received: 887
  • Karma: 195
Hi Nate,

We don't see this issue with FCP X on other NAS systems, nor do we see the permissions issue when you move modified FCP X Libraries from NFS to SMB. So I agree with you that your problems are related to your QNAP. I would contact QNAP support to see if they have a solution. If you cannot find any answers there (their support is not really great), drop me an e-mail and I will get you directly in touch with a QNAP expert: This email address is being protected from spambots. You need JavaScript enabled to view it.

- Ronny
The administrator has disabled public write access.

QNAP Copy Bug 11 Feb 2019 13:56 #98895

Nate,

I am having a very similar issue. Did you ever get an answer or figure out the problem.

I also have the same questions about moving to SMB from NFP.

I would love to hear what you found out if you contacted QNAP.
The administrator has disabled public write access.

QNAP Copy Bug 15 Feb 2019 23:18 #98938

  • nate.haustein
  • nate.haustein's Avatar
  • OFFLINE
  • Fresh Boarder
  • Posts: 16
  • Thank you received: 1
  • Karma: 0
I haven't had the time to talk to QNAP about it, no. I did find that copying the library to an external hard drive, and then copying back to the QNAP and opening via SMB seems to reset the permissions and solves the issue. A stopgap, if you will.
The administrator has disabled public write access.

QNAP Copy Bug 16 Feb 2019 02:53 #98939

  • FernKraft
  • FernKraft's Avatar
  • OFFLINE
  • Gold Boarder
  • Posts: 208
  • Thank you received: 28
  • Karma: 5
Hey Nate,

Are you importing your media into the FCPX library? or are you importing to an external folder?

When the media is managed inside the FCPX library bundle, We've noticed issues over NFS that are VERY similar to what you are mentioning. Try moving the media to outside the FCPX library if this is the case. This fixed the problem for us.

I'd be cautious moving over to the SMB, as you will loose the ability of fcpx to hard link when copying between libraries, which for our team is very useful.

hope that helps,
Last Edit: 16 Feb 2019 02:55 by FernKraft.
The administrator has disabled public write access.

QNAP Copy Bug 20 Feb 2019 03:52 #98979

  • nate.haustein
  • nate.haustein's Avatar
  • OFFLINE
  • Fresh Boarder
  • Posts: 16
  • Thank you received: 1
  • Karma: 0
Thanks FernKraft. I didn't realize that SMB didn't use Hard Links. For the work we do, they help significantly with saving storage space.

The external media option worked for us too - thanks for suggesting that. Still, it USED to work fine before about August of 2018. I might submit a ticket with QNAP to see what the deal is - if it's just our box or if it's something a QTS update did a few months back.
The administrator has disabled public write access.

QNAP Copy Bug 04 Mar 2019 22:20 #99148

  • nate.haustein
  • nate.haustein's Avatar
  • OFFLINE
  • Fresh Boarder
  • Posts: 16
  • Thank you received: 1
  • Karma: 0
Quick update: QTS 4.3.6.0867 (build 20190228) has seemed to fix the issue for us. Maybe someone really is watching over us...
Last Edit: 04 Mar 2019 22:22 by nate.haustein.
The administrator has disabled public write access.