[iFixRobots]

Videos sent from Beeper reach GroupMe's own apps as an empty player, and Beeper shows them as a broken file. The roadmap lists this as "GroupMe can't play it back".

One thing we do differently from GroupMe's web client is the upload session request. The web client sends the video's dimensions, and we never do:

(type === "image" || type === "video") && dimensions && (r.width = dimensions.width, r.height = dimensions.height)

The video's width and height from the Matrix event now go into the upload session. To keep the call readable, the session fields are passed as one UploadRequest.

I haven't proven this fixes playback. It's the remaining difference between our upload and the web client's (apart from blur_hash), so it needs a device check before the roadmap row changes.

	Before	After
Upload session for a video	No dimensions	Width and height, like the web client

Changelog: Internal, until playback is confirmed on a device.

Before / after

I haven't run this on a device yet. It needs a staging bridge build, a video sent from Beeper, and a check that it plays in GroupMe's app.

Stacked on #31.

Tag @indent to continue the conversation here.

[indent]

Issues

1 potential issue found:

• Any m.audio event, not only voice messages (MSC3245Voice), is sent as a GroupMe voice note, and its caption is dropped. Plain audio files previously returned ErrUnsupportedMessageType. This comes from the voice-note work now included because the PR targets main.
  _{Found by Indent Review Agent}

↑ Select any checkbox above to have Indent auto-fix the issue

CI Checks

All CI checks passed on 0531b35.

Review agents

Select any unchecked box below to run or rerun that agent.

Found issues (1)

• Indent Review Agent · No issues found in the video dimensions change.

Full results

Indent Review Agent

• Summary: No issues found in the video dimensions change.
• Last ran on commit: 0531b35f
• Latest result

  {
    "summary": "No issues found in the video dimensions change.",
    "findings": []
  }

[indent]

🟡 Bug · Plain audio files are sent as voice notes and lose their caption

Every event.MsgAudio is routed to uploadMatrixMedia → voiceNoteAttachment, whether or not the event has MSC3245Voice. Before the voice-note work, a plain audio file (e.g. an .mp3 with a caption) failed with ErrUnsupportedMessageType and the sender got an unsupported notice. Now it uploads with Extension "mp3" and arrives in GroupMe as a voice note, and the case event.MsgAudio: text = "" branch drops the caption silently. Capabilities only advertise CapMsgVoice with audio/mp4, so plain audio is outside the declared contract.

Handle MsgAudio as a voice note only when content.MSC3245Voice != nil; otherwise return ErrUnsupportedMessageType or send it as a file and keep the caption.

_{Found by Indent Review Agent}

[indent]

Valid, though it comes from #31 rather than this PR. I fixed it separately in #33: audio without MSC3245Voice fails as unsupported again.

[Fizzadar]

Tested live on a self-hosted bridge (main vs this branch, retested after main was merged in): the upload now carries the dimensions - GroupMe stores the video as 640x360.original.mp4 instead of original.mp4 - and it plays through in GroupMe web with the right aspect ratio, bytes intact on the Beeper side.

Web played fine on main too so the empty player only shows on GroupMe's mobile apps, still worth a device check but merging as the upload request now matches the web client. LGTM!