Document Mediasite and Zoom download edge cases from recordings backfill
This commit is contained in:
1 parent
c40a01aecf
commit
e1d8b4a1fa
2 files changed
+11
-1
No files matched your search
@@ -247,3 +247,7 @@ OPMG-GB-2250-89F26_9-19-2026.mp4
|
||||
- **Channel pages may list recordings from multiple course sections or
|
||||
semesters.** Cross-check presentation titles against the current course
|
||||
code before downloading everything in a channel.
|
||||
|
||||
- **Two presentations can share one title.** A course with morning and afternoon sessions on the same day (e.g. `MGMT-GB-2259-89S26_1/9/2026` at 9:00 AM and 1:15 PM) produces two presentations with identical titles and near-identical durations. Check `Presentation.AirTime` and give the files distinct names (e.g. add `_pm`). To tell which one an existing local file came from, compare bytes from inside an `mdat` box of a camera-stream segment with the local file; matching on the start of a segment, or on screen-stream segments (static slides repeat across sessions), gave false results.
|
||||
|
||||
- **Older Mediasite launch links can fail.** Spring 2025 courses at NYU used a launch link that lands on `/Mediasite/Lti/Catalog` with "You were not authenticated successfully"; later courses' links work. Mediasite's site search (`/Mediasite/MyMediasite/search/...`) does not return course-channel presentations for students, so there is no workaround from the student side.
|
||||
@@ -33,7 +33,9 @@ Opening it renders Zoom's LTI app in an iframe from `applications.zoom.us/lti/ri
|
||||
|
||||
Drive this app through the UI (clicks inside the iframe), not its JSON API. The app calls endpoints such as `/api/v1/lti/rich/recording/COURSE?...`, `/recording/file?meetingId=...` and `/recording/pwd?meetingId=...`, but re-issuing those from the frame with `credentials:'include'` returned `403 {"errorMessage":"Sorry, your session was expired..."}`: the app sends a session token that a plain fetch doesn't carry.
|
||||
|
||||
Clicking a card's play icon opens a popup window whose first real URL is the recording's play page (`https://{school}.zoom.us/rec/play/{id}`). Capture that URL from the browser's target-created/target-changed events; it is the same kind of URL a share link resolves to, so continue at §1 with it. [Not yet tested: downloading through a play URL captured this way. The download below was verified starting from a share link.]
|
||||
Clicking the play icon on a **`Recording-N (size)`** card opens a popup window whose URL is the recording's play page (`https://{school}.zoom.us/rec/play/{id}`). The unlabeled first card (the shared-screen thumbnail) opened nothing when clicked. Capture the popup URL from the browser's target-created/target-changed events, close the popup, and continue at §2 with the URL. Verified 2026-10-23 on 35 recordings across 5 courses. A meeting can have more than one `Recording-N` card; click each one and download each as its own file.
|
||||
|
||||
Driving notes: the Brightspace launch through `/d2l/lti/authenticate` can take 20+ seconds before the `applications.zoom.us` frame appears, so wait up to a minute. Clicking the Cloud Recordings tab sometimes does not register; check that `[role=tab][aria-selected=true]` reads "Cloud Recordings" and click again if not. A "No Data" text from the hidden Meetings tab can be on the page before the recordings table loads, so don't treat it as an empty list until the Cloud Recordings tab is the selected one.
|
||||
|
||||
The LTI app shows no download button when the host has disabled downloads, which is the common case for course recordings.
|
||||
|
||||
@@ -45,6 +47,10 @@ That is a stop-and-ask moment: tell the user to sign in to Zoom in their own bro
|
||||
|
||||
Observed with the omp Chrome relay: the tab sitting on the Zoom sign-in page closed itself about 2 seconds after loading (cause unknown, possibly another extension). If a tab disappears right after a redirect to `zoom.us/signin`, that redirect is the finding: the user is not signed in to Zoom.
|
||||
|
||||
### Recording registration pages
|
||||
|
||||
Some share links open `.../rec/component-page?...componentName=recording-register...` ("{host} shared a recording with you ... Fill out the request form"). The form asks for first name, last name and email; for a signed-in user Zoom pre-fills them from the account. Submitting sends those details to the host and account owner, so ask the user before clicking Register. After Register, the page redirects to the normal `/rec/play/` page and §2 onward works unchanged.
|
||||
|
||||
## 2. Get the MP4 URL from the play page
|
||||
|
||||
With the user signed in, opening the share link redirects to:
|
||||
|
||||
Reference in new issue
Block a user