Welcome to the Panopto Community

Please note: All new registrants to the Panopto Community Forum must be approved by a forum moderator or admin. As such, if you navigate to a feature that is members-only, you may receive an error page if your registration has not yet been approved. We apologize for any inconvenience and are approving new members as quickly as possible.

Fix Bug of Sessions_UpdateSessionMetadata Endpoint Not Working For Copied Sessions

Jake LoosJake Loos Tyro
edited January 13 in API

As a result of the January 8th update, the API endpoint for updating a session's metadata no longer works for sessions that have been copied; renaming it to remove the " (copy)" that now appears at the end of its name doesn't work, nor does moving it to a different folder.

Comments

  • Hiroshi OhnoHiroshi Ohno Panopto Employee

    Hi Jake,

    Thank you very much for the report. We are going to look at this and update here.

    You said "sessions that have been copied". Can you tell me how you copy the sessions? Did you do so from session list in Panopto UI? Or something else? This may or may not be relevant to the problem, but I want to collect a data point in advance for our investigation.

  • Hi Hiroshi, I'm Jake's co-worker and am happy to elaborate.

    We copy the sessions manually from the Panopto UI into different folders based on their tags. We then have a script that, with the resulting sessions, renames and moves them into different folders in other places. Before this past Saturday's update, this script was working perfectly; now, it seems that the endpoint in question only works for sessions that aren't the result of the manual copy of a different session.

    Hope this helps!

  • Hiroshi OhnoHiroshi Ohno Panopto Employee

    Thank you very much for the additional information. This helps expediting reproducing an issue on our end.

  • edited January 13

    Happy to help! More specifically, the PUT request returns a 404 error on the ID of the resulting session (one that is the result of being copied from another one). Our hypothesis is that these resulting sessions are ID-mapped to the sessions that they are copies of, and that the public-facing ID (the new one that was created as a result of the copy) isn't the one that corresponds to this endpoint.

    Please keep us updated as you look into this issue — thanks!

  • Hi @Hiroshi Ohno, any update on this issue? We just tried again to run the script and are still getting 404 errors.

  • Hiroshi OhnoHiroshi Ohno Panopto Employee

    Hello Sergio,

    We are still investigating this issue and we don't have ETA for it. Our support team will reach out the point of contact of your organization as soon as we have an updated status.

  • Hiroshi OhnoHiroshi Ohno Panopto Employee

    Hello again,

    We were able to identify the problem and the fix is scheduled to be released by the end of next seek. Thank you for your patience.

  • Thank you for the update, @Hiroshi Ohno! We're eager for the release.

Sign In or Register to comment.