tokejepsen

Using partial to reuse the same session works! The memory footprint does not increase, in the simple test case in the original post.

Good point. Havent been able to trace down the memory leak, so if you have some pointers that would be great!

Hey Steve, I tried 1.8.2 and it does not fix our issue. Since other people are not experiencing the same thing, I'm suspecting it might be our environment. Would greatly appreciate if someone could test on their end with this (conda) environment? name: ftrack-pipeline-environment channels: - defaults dependencies: - certifi=2019.6.16=py27_0 - pip=19.1.1=py27_0 - python=2.7.16=hcb6e200_0 - setuptools=41.0.1=py27_0 - sqlite=3.29.0=h0c8e037_0 - vc=9=h7299396_1 - vs2008_runtime=9.00.30729.1=hfaea7d5_1 - wheel=0.33.4=py27_0 - wincertstore=0.2=py27hf04cefb_0 - pip: - arrow==0.14.2 - backports-functools-lru-cache==1.5 - cachetools==3.1.1 - chardet==3.0.4 - clique==1.5.0 - ftrack-python-api==1.8.2 - google-api-python-client==1.7.9 - google-auth==1.6.3 - google-auth-httplib2==0.0.3 - google-auth-oauthlib==0.4.0 - httplib2==0.13.0 - idna==2.8 - jsondiff==1.2.0 - oauthlib==3.0.2 - pyasn1==0.4.5 - pyasn1-modules==0.2.5 - pyparsing==2.4.0 - python-dateutil==2.8.0 - requests==2.22.0 - requests-oauthlib==1.2.0 - rsa==4.0 - six==1.11.0 - slacker==0.9.65 - slacker-log-handler==1.7.1 - termcolor==1.1.0 - uritemplate==3.0.0 - urllib3==1.25.3 - websocket-client==0.56.0 prefix: C:\Users\admin\miniconda\envs\ftrack-pipeline-environment

Hey, I've been trying to figure out why our Ftrack event listener machine is running out of memory. Seems like the event listener is holding onto something, so it does not get garbage collected. Take a simple event listener like this: import ftrack_api def test(event): session = ftrack_api.Session() session = ftrack_api.Session(auto_connect_event_hub=True) session.event_hub.subscribe("topic=ftrack.update", test) session.event_hub.wait() It initially starts at 27 Mb, but with every ftrack event that triggers it, a couple of Mb get added. It never gets back down to 27 Mb. Anyone experiencing the same?

There is a useful thread here for this: https://forum.ftrack.com/topic/1045-multiple-instance-of-ftrack-connect/

Nice mockup! I would suggest for backend, that we can reference git repository online and offline for this.

Ahh, I see. Yeah, you can do that. You can also have a separate python script in the same folder as "djvview.py", which contains "modify_launch ". Which might make it easier to update "djvview.py" in the future. Or have a completely separate folder with "modify_launch " which is added to FTRACK_CONNECT_PLUGIN_PATH. This way is probably better if you are working with git.

Do you mean you added that to https://github.com/tokejepsen/ftrack-hooks/blob/master/djv_plugin/resource/hook/djvview.py ?

Cool Let me know if you have any issues.

Hey, Noticed on long action labels, the text gets cropped off. See attached image.

I've found that if this value is not set to True, then the version won't show up in the Ftrack UI. The version will still exist in the database though.

Hey, I was wondering whether Nuke 11 is officially supported? I have seen various commits/branches on Bitbucket about it, but an initial test showed that Nuke crashes when trying to show any of the "Asset Manager" or "Asset Importer".

You cannot (as far as I know) name the tasks in the templates. This was one of the reasons why I created https://github.com/tokejepsen/ftrack-hooks/tree/master/batch_tasks

Good point! We'll probably use that then instead. Specifically we are using https://github.com/pyblish/pyblish-ftrack, where we allow the users to specify the version number, but we can just -1 internally as a way to let the plugin know to create the next available version.

Hey, If you have an entity selected in overview, then right-click > Actions on a different entity, you will get the actions for the selected entity and not the entity you right-click on. Either the behaviour should be that right-click selects as well, or right-click > Actions will know which entity is right-clicked on.