Julian Martinz

Members
  • Content Count

    21
  • Joined

  • Last visited

  • Days Won

    3

Julian Martinz last won the day on February 8

Julian Martinz had the most liked content!

About Julian Martinz

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Julian Martinz

    Memory leak

    You have to reset session at the beginning of your callback() with Session.reset() and it should work as expected
  2. @John maybe I don’t get the problem but can’t you just get the project via the entity you’re dealing with? Or are you just looking for a more convenient way? Best, Julian
  3. Hey Alican, I didn't read through the entire thread but I think all you wanna do is adding a reviewable version to an assetversion. If that's correct you just can use the encode_media helper method from the asset_version itself and call it a day. With that method the media will be uploaded and encoded. ... asset_version = session.create('AssetVersion', {'asset': asset}) asset_version.encode_media(local_path_to_media) Best, Julian
  4. Your PYTHONPATH has to be set accordingly. Which OS? And how do you start maya? If you start Maya from the same terminal-session from where you can import the api in an interactive python session, you should be able to import the api inside Maya as well. Edit: Obviously the PYTHONPATH has to be set in the bash-session (or whatever shell you use)
  5. hey @Lorenzo Angeli Okay think I got it. I thought of the proxy location as a mere "switch" that forwards the add_component method to one of the two locations and then the component is addaed to the actual location (server1.managed/server1.unmanaged). But what you are proposing is to actually add the component to the proxy-location and just leveraging the methods from the other (configured) locations. Did I get it? Best Julian
  6. Hey Lorenzo, That's absolutely fine .. but how can I create these two locations with the same name but different behaviour? When trying to create to locations with the same name the session will logically throw an error. Or are you talking about two entirely different location? To stick to my example: studio.server1.managed and studio.server1.unmanaged? If so that's actually not what I am after. The point is that I only want to differentiate on publish/component-creation. Once the components are published, you shouldn't be able to distinguish between components added via the unmanaged or via the managed location. So basically just as if you are adding components to a configured location or the same location after mixin in the unmanagedLocation mixin. Once added there is essentially no difference between the components. But maybe that's just not possible? Or maybe I am missing the point. Best, Julian
  7. Hey @Lorenzo Angeli, looking forward to your example. In the meantime I tried it myself and got a working version up n running. Unfortunately it doesn't really help me with the original problem. I can configure my proxy location to choose between distinct locations with different names like studio.server1 and studio.server2 (which is great btw and helps me solve some other issues I had). However, to choose between a managed and unmanaged version of the same location I'd have to create both instances beforehand, which afaik is not possible as they are essentially the same? Or at least I don't know how. What would work is creating two distinct locations studio.server1 and studio.server1.unmanaged. But that's not really what I am after. And that brings me back to my original question: Is there any way to revert a location instance back to the state it was before mixin in the unmangedLocationMixin? The only solution I can think of right now would be to reconfigure my locations by emitting an 'ftrack.api.session.configure-location' event. But that doesn't seem right .. - Julian
  8. Hey Lorenzo, thanks for the reply. I think @JPrydz mentioned that concept before. You don't happen to have a code example ready? Or at least a draft or a hint? After a short glance at the location class I'd start by overriding/extending the add_component method and implement the logic there. Does that sound sensible? Best, Julian
  9. Is there an option to revert a location to default after setting it up to be unmanaged with the ftrack_api.mixin() method? I have to publish components to the same location during a session. Some of them are already where they belong so I want to add them through the unmanaged location. For others (especially those created by the official plugins // publishers) I'd like to rely on the default behaviour. - Julian
  10. Hey Lorenzo, Thats basically what I was planning to do (except for the threading part in the action .. but guess that's the only viable way). Thanks for the reply. - Julian
  11. I am about to shift some specific actions from running locally on user-workstations to one or two central worker-clients. Some of these actions will run a little bit longer and won't be discoverable during processing. To keep it simple, maintainable and scalable I'd like to avoid setting up threading/multiprocessing mechanisms inside the action and do that on a higher level instead. Is there a canonical way to pull this off? If I understand it correctly the event.stop() method will only work if I register the listeners from one single process. So multiple-docker containers or multiple hosts won't work because this would lead to multiple actions with the same name showing up for users. Is that correct? Anything else to watch out for?
  12. Ah ok .. guess that’s by design. you could setup an event handler that is listening to status changes and sets a ‘latest_approved’ flag on the most recent approved version. Then you could use that attribute in your queries. Quite involved for what you want but it should work. Would be welcome if something like that could be accomplished with the filter queries instead.
  13. I may be wrong but can’t you combine the query filter with the built-in latest version filter and are done?
  14. Digging around I found the answer to my question by myself. For reference it is possible to modify the labels on review-session-objets. More information can be found here http://ftrack-python-api.rtd.ftrack.com/en/1.7.0/example/review_session.html?highlight=reviewsession and in the action here https://bitbucket.org/ftrack/ftrack-recipes/src/master/python/actions/annotate_review_clips/
  15. Hey Johan, Actually, this is exactly what I (and Tim, if I understood him correctly, too) want to do. The question is where to find the default one. Best, Julian