Capture One 10.1 and NAS issues
Hi,
I've tried to update to CO 10.1 (and even tried 10.1.1 and 10.1.2) but there's a problem
with the folders I usually work that are on a NAS (Synology).
All the session folders appears with an exclamation mark (with the exception of the trash)
and if I try to navigate on the NAS in the Library all the folders appears without the arrow to open
even if they have subfolders. Sometimes the arrow appears but If I open the folder to see the subfolders the library
refresh and bring me back to the main folders.
We already experienced problems with the NAS with release 9.1 through 9.3 (CO used to crash after a while we worked
on the network folder or tried to navigate in the network storage) and they where solved with 10.0, now
there's this new issue.
I've opened a ticket but didn't received any response. Someone else with the same problem?
The OS is MAC OS 10.12 (same problem with 10.11), both iMac and Mac Pro affected.
I've tried to update to CO 10.1 (and even tried 10.1.1 and 10.1.2) but there's a problem
with the folders I usually work that are on a NAS (Synology).
All the session folders appears with an exclamation mark (with the exception of the trash)
and if I try to navigate on the NAS in the Library all the folders appears without the arrow to open
even if they have subfolders. Sometimes the arrow appears but If I open the folder to see the subfolders the library
refresh and bring me back to the main folders.
We already experienced problems with the NAS with release 9.1 through 9.3 (CO used to crash after a while we worked
on the network folder or tried to navigate in the network storage) and they where solved with 10.0, now
there's this new issue.
I've opened a ticket but didn't received any response. Someone else with the same problem?
The OS is MAC OS 10.12 (same problem with 10.11), both iMac and Mac Pro affected.
0
-
What is your support case number? You can find it under www.phaseone.com, My Pages, Support Cases. 0 -
Is the NAS mounted over SMB or AFP? 0 -
I've just checked to support page and I think that the ticket wasn't sent. I've submitted a new one today.
Anyway, is mount over AFP (tried SMB but it's really slow).0 -
SMB will be sped up with this trick:
sudo -s
echo "[default]" > /etc/nsmb.conf
echo signing_required=no >> /etc/nsmb.conf0 -
already tried smb, there's a lot of other problems... first of all when I shot tethered the files takes almost a minute to be available in capture one, with afp is almost instant... 1-2 sec.d 0 -
the speed of smb will be better than afp with the trick I described. The lines have to be copied in the terminal. 0 -
Some months ago, AFP corrupted my images now and then, only when reading from the NAS (writing was okay fortunately). All my problems went away after I switched to SMB (with signing off).
But.. yesterday Synology released a new DSM version which fixes some AFP problems: DSM 6.1.2 build 15132. But be aware, Apple is discontinuing the AFP support, everything will be SMB in the future. You'll have to switch sooner or later, why not now? 😉0 -
A few months ago I switched to using a NAS RAID (Western Digital) for being my primary photograph storage. "Current" folders remain on my internal Mac SSD to facilitate intensive editing. Previously I used a USB RAID as the primary storage.
With the earlier setup I was able to edit "archived" images directly from the RAID. The new NAS RAID was setup using AFP protocol. Despite seemingly adequate data rates, there was prolonged thumbnail and preview generation with frequent image corruption. I took to copying "old" folders back to the SSD for editing, and then copying back.
After reading the above topic I switched to SMB protocol and set signing to off. I can now directly edit images on the NAS with no corruption.
Thank you to everyone for the solution.
Regards0 -
Does someone who works with SMB protocol shoots with tethering?
Because I've already tested SMB deactivating signing and using SMB 2.0 protocol (via terminal) with CO 9.3 (because of the problem already mentioned) and regular editing was ok but had issues with tethering. Files took ages to transfer from the DB to CO... around 60 seconds (instead 2-3 sec) and wasn't a network speed issue (tested and was perfect). Only in CO working with tethering.
I'll try again with 10.1.2 but I want to know if someone already working with same config (Mac OS + NAS + SMB + Tethering).0 -
[quote="studiobaccega" wrote:
Does someone who works with SMB protocol shoots with tethering?
Because I've already tested SMB deactivating signing and using SMB 2.0 protocol (via terminal) with CO 9.3 (because of the problem already mentioned) and regular editing was ok but had issues with tethering. Files took ages to transfer from the DB to CO... around 60 seconds (instead 2-3 sec) and wasn't a network speed issue (tested and was perfect). Only in CO working with tethering.
I'll try again with 10.1.2 but I want to know if someone already working with same config (Mac OS + NAS + SMB + Tethering).
I'm working with the same config, without problems. But.. I store the files on the local internal SSD, not on a network drive via SMB.
But a related problem: when I have SMB shares active (mounted, accessible) Capture One (newest) gets slow, beach balling when switching tabs for example. I have to unmount (remove) the network shares and then the interface gets responsive again. Maybe it's related to your problem?0 -
Hi all,
I am experiencing similar problems and have just opened a case with phase one.
My setup at home is with COP10 on an iMac with High Sierra and internal SSD. The catalogue is on the internal SSD and the referenced raw files are all located on a mounted share from a Synology NAS. The share is mounted via AFP, since AFP is faster and more reliable on the mac than SMB (and YES, I have tried all of the improvements I can find on the net regarding SMB, but AFP still works more seamlessly on the macs).
The issue I am having seems to do with Capture One not always dealing with case sensitivity.
If I create a new folder on my NAS share and then add this folder as a reference to my catalogue, sometimes Capture One seems to add it referenced all in lowercase or only parts of the path!
For example, my share is mounted under "/Volumes/home/Bilder/". However, when I added the subfolder "2017 Versuchsbilder" to my catalogue, Capture One did this, but when I hover over that folder, I see that Capture One included it as "/volumes/home/bilder/2017 Versuchsbilder"! This means that when using AFP, Capture One cannot find my raw files! If I re-mount using SMB, then the files can be found because then "/Volumes/home/Bilder/2017 Versuchsbilder" is seen as the same as "/volumes/home/bilder/2017 Versuchsbilder" - but I do not want to rely on SMB and anyway, I think that if I add a path with mixed case, that Capture One should at least honour this case and not randomly change parts of the path to lowercase. Renaming the paths within Capture One also does not help.
I see this as a bug because it should not be that Capture One relies on the underlying file system or share being case insensitive.
One can of course argue about AFP vs SMB, but if in the future another protocol is used, we may have the same issues.0 -
Hello
I posted earlier (June) regarding implementing an SMB NAS connection after having serious problems (image corruption) with AFP while running CO 10.
I have since upgraded OS X to 10.13.1 and, after reading yesterday's posts, decided to check the write/read speeds to see if SMB still has a significant advantage over AFP, for my setup.
Results:
SMB as is 85 write 89 read
AFP 70 105
I then re-applied the SMB speed fix and got
SMB 85 103
From memory the speed advantage of SMB over AFP that I recorded earlier was greater. Maybe AFP has been improved with recent OS X releases.
Regards
Peter0 -
[quote="wombi1973" wrote:
...
The issue I am having seems to do with Capture One not always dealing with case sensitivity.
...
I had similar issues with case sensitivity on network drives after trying different protocols and trying imports with one or the other.
The cause was duplicate records in the Capture One sqlite database, table ZPATHLOCATION. It contained multiple records of basically the same path, but different case. After cleaning it up once using "DB Browser for SQLite" (backup you catalog before using it), everything is fine.
I settled with a NFS automount, which is more stable and faster than SMB here, YMMV though.0 -
I have a similar issue with my database. Is there any fix for this problem (did not tried yet to directly modify the DB 😄)?
Is it in CO11 corrected?0
Post is closed for comments.
Comments
14 comments