• Content Count

  • Joined

  • Last visited

Everything posted by AnthonyM

  1. Thanks @Remus Avram and @lorenzo angeli This post will help me when I do future installs I'm sure
  2. Bingo. Libpng12 fixes it. Dang, always forget about libpng vs libpng12. Thanks! Maybe we can get that listed as a dep. somewhere?
  3. 0.7.5 - I've also tried to run it on two different fresh installed vm's with slightly different presets (install groups, like development) to see if that was it. It prints: <function _pyside at 0x7ffb1c179b18> Edit: Also tested 0.7.4 and no go. So weird that this doesn't work.
  4. It's a clean install of CentOS, so I didn't have anything installed in the path. I've installed PyQt4 4.10.1 and PySide 1.2.4 now. Same error. I opened up the and, imported those's and I didn't get any errors. I can import both PySide and PyQt fine. I'm confused though, shouldn't the connect package 'binary' downloaded from the downloads page work out of the box without dependencies?
  5. Yes, libpng-1.5 is installed. Edit: Update: I've installed a fresh Gnome Desktop centos 7.4 on a virtual machine and Connect throws the same error. Libpng is installed on that as well.
  6. On a fresh install of CentOS 7.4 I can't run Connect. After the first failure I installed PyQt4, PySide2, and qt4 but still happens. Traceback (most recent call last): File "/home/anthony/Downloads/ftrack-connect-package/", line 29, in <module> File "/home/anthony/Downloads/ftrack-connect-package/", line 108, in <module> File "/home/anthony/Downloads/ftrack-connect-package/", line 14, in <module> File "build/bdist.linux-x86_64/egg/QtExt/", line 25, in <module> File "/home/anthony/Downloads/ftrack-connect-package/", line 251, in <module> File "/home/anthony/Downloads/ftrack-connect-package/", line 248, in _init ImportError: No Qt binding were found. Any thoughts?
  7. I was banging my head against the desk over this same problem yesterday. Through some random things I did I got it to work. Here is what I did that seems to make it go: Try commenting out the ftrack_api.mixin(location, ftrack_api.entity.location.UnmanagedLocationMixin). I'm not 100% sure why this doesn't work but as soon as I did that I got the files to publish to the correct spot on my local file server. Next, the I think wasn't being found. I built connect from source and for some reason the built-in resolver was working - which is the bit that resolves the path from web to local I believe. I threw it into a path that connect could pick up and it all started working. If only using the api maybe you need to get a resolver into your pythonpath? Not sure if that will help you but thought I would post here for the next time I have to reinstall, ha!
  8. I'm trying to get our assets published correctly and synced with google drive. We have no central location and are all "cloud" based (pardon the buzzword). Correct me if I'm wrong but if we use the Central Storage Scenario then we will essentially have two copies of the same file on disk. One at the sandbox location that the artist is working from and then one at the publish location that ftrack uses (/projectname/component). Is that correct? I can see that becoming very hard to manage as far as disk space and what not. If I don't want to do it that way we can use the unmannaged option, where it publishes in place, right? The problem I have with that is no matter what I do I can't get osx to recognize the published file path. Has anyone else run into that? I've tried symbolic links and using bindfs to no avail. I guess I'm kind of lost... So to wrap up my rambling post, how would you go about using Google Drive as your central repo for publishing? Thanks for reading! Any insight is appreciated!