When uploading media directly would we need to perform any colorspace transform to comply with browser support? I’m assuming this was/is currently handled at the middle step on the Shotgun Servers. Is their a particular codec for movie files? etc…
1 Like
To be honest, we debated this heavily internally, but eventually chose not to ‘hide’ some default retry loop within the basic upload function because it came down to the caller knowing their retry context better than us. e.g. to block or not until success?, and we thought it best that people consider, and pick the best for their circumstance.
Failures are expected only as very infrequent exceptions, due to S3 availability, or networking gremlins - and we wanted to call out this fact since the upload is now happening direct to s3 - shotgun itself is no longer able to babysit its success.
I’d welcome thoughts on useful wrapper functions within the API that the community might make use of.
3 Likes
Hi Zoe!
Thanks for your honest reply. I can see your point and I appreciate your efforts to make this as flexible for the community as you can!
In my opinion you can keep the upload function as is and “just” add a convenience function (“upload_with_reties” ?) that catches maybe 80 percent of the retry scenarios. This way everybody could choose what fits for their specific needs and implementation. I know there is more to this then simply adding this functionality, just my 2 cents… 
For what it’s worth here is my current (untested) implementation:
def shotgun_upload_with_retry(shotgun, entity_type, entity_id, path, field_name=None, display_name=None, tag_list=None,
retries=1):
"""
:param shotgun_api3.Shotgun shotgun: A shotgun API instance.
:param str entity_type: Entity type to link the upload to.
:param int entity_id: Id of the entity to link the upload to.
:param str path: Full path to an existing non-empty file on disk to upload.
:param str field_name: The internal Shotgun field name on the entity to store the file in.
This field must be a File/Link field type.
:param str display_name: The display name to use for the file. Defaults to the file name.
:param str tag_list: comma-separated string of tags to assign to the file.
:param int retries: How often to retry to upload. Can be between 0 and 3.
:returns: ID of the Attachment entity that was created for the image.
:rtype: int
:raises ShotgunError: When an error occurred during upload after the maximum retries have been reached.
"""
retries = max(0, min(retries, 3))
retry = 0
while True:
retry += 1
try:
return shotgun.upload(entity_type=entity_type, entity_id=entity_id, path=path,
field_name=field_name, display_name=display_name, tag_list=tag_list)
except ShotgunError:
if retry > retries:
raise
Cheers,
Fabian
5 Likes
Hi Zoe,
Just to verify, the version of tk-core (>v0.18.149) is the only adjustment which is needed for SGTK. Is this correct?
I’m asking because we have a customized tk-config-default2, with a couple of customized frameworks and apps. Currently we are two versions behind the official release. Do we need to update to the latest version of tk-config-default2?
Thank you
Christian
2 Likes
Hi Christian, correct, tk-core v0.18.149 (even though it is well behind the current official release) is sufficient to be compatible with requirements for direct upload.
3 Likes
Great! Thank you.
1 Like
Dear community,
Due to the exceptional circumstances created by COVID-19, we are postponing this deprecation to April 21, 2020.
The main post regarding the schedule has been updated accordingly: Deprecation of old versions of Shotgun API, RV and iOS - April 21 2020
2 Likes
Sorry for being off topic, but if Shotgun is moving to python API 3.0, wouldn’t that mean it is now actually compatible-“able” with Blender? Blender dropped 2.0 quite of a while ago…
1 Like
Thanks for the dialogue here, Fabian, and your sample implementation to illustrate what you’re thinking of. It’s great to be able to take this back to the team, although it will be some time before we get around to revisiting what’s included in the API.
2 Likes
The latest Shotgun Python API versions are compatible with Python 3 as of v3.1.0. These latest versions of the Shotgun Python API are compatible with both Python 3 and Python 2.
If Blender includes a Python 3.x environment you should be able to use the latest version of the Shotgun Python API without issues as of Jul 29, 2019 and with version v3.1.0 or newer.
2 Likes
Thank you!
Last time I check this Shotgun was on Python 2.0 which Blender did not support anymore.
Time to email Ton Roosendaall
Blender Foundation just made official the development of an internal asset manager in 2020, so it might be the right time.
In my opinion the largest reason Blender does not penetrate more bigger business at the moment is the lack of effective pipeline integration. If Shotgun gets in it’s game, that door will open.
2 Likes
FYI!
2 Likes
This might be a daft questions, but generally speaking I talk to the API via inbuilt methods in apps:
# via the self._app handle we can for example access:
# - The engine, via self._app.engine
# - A Shotgun API instance, via self._app.shotgun
# - A tk API instance, via self._app.sgtk
So when I’m using self._app.shotgun will that be automatically using API3, assuming my core is up to date? Thanks very much.
3 Likes
Hi @jhudsonFP,
First off, welcome to the community!
To answer your question, yes, your usage will leverage the copy of the Shotgun Python API which is included with your Toolkit setup so assuming your Tooklit core is up to date you should be ok.
4 Likes
Hi @bouchep, thanks very much!
2 Likes
Is there an event for when an image field is no longer transient?
I’m hitting errors about this for my daemon plugin that shares thumbnails from publishedfiles to the entity.
1 Like
Hi @jhultgre,
So the short answer is yes, there is an event when the image field is populated by the transcoder and isn’t transient anymore.
The above screenshot shows two events on the image field of a Version entity. The first event shows the value being set to the transient URL. The second event shows the URL changing from the transient value to the storage value.
The unfortunate news is that you’d still need to query the URL value as there is nothing in the event itself to distinguish between an event that sets the transient value to an event that sets the permanent value as evidenced by the event_type and meta fields.
In short, you’ll need to keep processing all events but you’ll need to make sure the URL isn’t the transient one before you issue the share_thumbnail() call.
3 Likes
Reviving this super old thread because as far as I can see ShotGrid has not included any retries for uploads in any SGTK code. What is the timeframe on this? Is there maybe still a chance that you can add the retries by default as I suggested.
Thank you.