Video Block missing required metadata and using incorrect source in post_content after going Atomic when Gutenberg active

[mgozdis]

Expected behavior

A user reported issues with videos in new posts not displaying after their site went Atomic. Initially, this seemed related to metadata missing on the videos when site went Atomic. The metadata was fixed and this issue is now only happening when posting from the Android app and only when Gutenberg is activated. With Gutenberg deactivated on mobile, the videos work fine and post content also looks fine.

User expects videos to load as they always have when posting from Android app prior to upgrading their plan to Business.

Actual behavior

When posting from the Android app with Gutenberg active, the user can see the video while previewing. Upon saving, the post content is created with a video block like below. This has missing metadata (it does exist) and uses an invalid source that causes a 404 that prevents the video from loading on the frontend:

<!-- wp:video {"id":5080} -->
<figure class="wp-block-video"><video controls src="https://example.com/20200905_124552_dvd-mp4/"></video></figure>
<!-- /wp:video -->

When updating a different broken video post on Desktop, with Gutenberg active and without making any changes, the post content changes to something like this with additional metadata, and the video loads. Post content is similar when posting from the app with Gutenberg deactivated:

<!-- wp:video {"guid":"m64AHvMt","id":5207,"videoPressTracks":[],"videoPressClassNames":"wp-block-embed is-type-video is-provider-videopress"} -->

Prior to going Atomic, their post content on working videos looked like this:

<!-- wp:video {"id":4978} -->
<figure class="wp-block-video"><video controls src="https://example.files.wordpress.com/2022/12/20221202_194201.mp4"></video></figure>
<!-- /wp:video -->

Steps to reproduce the behavior

• With Gutenberg activated, create a new post
• Add a video block and Choose from device or Take a video
• Publish the post and view on frontend

We have been trying to gather device/OS information and the Android app version. It is not entirely known as they are frustrated and just want things to work. They last reported they are using a Samsung S20+ with everything fully updated.

[reginabally]

According to the logs in 5832652-zd-woothemes, the user was using the app version 21.3 on Samsung SM-G986B. I performed a test with an Atomic site with Gutenberg activated, but I couldn't reproduce the issue. The video block stayed in the editor after I uploaded the video from the Android app and published it from there.

Tested on app version 21.3, Android 13, Nexus 5X (Android Studio emulator).

[mgozdis]

I was able to reproduce this on Android 10 with app version 21.4 on a test Atomic site. On a new video upload directly from the video block, it consistently sets post_content incorrectly like this with a bad source:

<!-- wp:video {"id":527} -->
<figure class="wp-block-video"><video controls src="https://example.com/20230113_001041-1-mp4/"></video></figure>
<!-- /wp:video -->

Interestingly, if you create another post and select the same uploaded video from the media library instead, it works fine and sets the post_content correctly like this:

<!-- wp:video {"id":527} -->
<figure class="wp-block-video"><video controls src="https://videos.files.wordpress.com/8psLmguo/20230113_001041-1.mp4"></video></figure>
<!-- /wp:video -->

A workaround is to upload the video to the media library first, create a new post, add a video block, and choose the video from the media library. Uploading directly from the video block by choosing from device or taking a video and posting creates broken video blocks.

[igotdes]

This was also reported in #6089928-zen:

• AT site
• Jetpack - 21.9.1
• Samsung SM-S908E

I've also been able to consistently replicate the issue on my AT test sites with my SM-S918B/DS. The issue is still reproducible on version 22.2-rc-1 of the app.

In my tests, simply editing the post in a browser, waiting for the video to load, and updating the post corrects the issue.

This has also been discussed in p1681460173333039-slack-C0180B5PRJ4.

[dcalhoun]

I debugged this issue some today. I observed that media upload requests return a different URL value for Atomic sites when using the Android app:

https://sitename.wpcomstaging.com/vid_20230829_104009-mp4/

This notably different to the following returned for Simple sites when using the Android app or any site type when using the iOS app:

https://sitename.files.wordpress.com/2023/08/vid_20230829_103832.mp4

This difference aligns with the incorrect block meta data shared previously. It seems as though the unexpected URL originates in the new media API endpoint.

[dcalhoun]

Removing my assignment from this issue as I focus on other work.

For anyone who continues work on this issue in the future, my recommendation for next steps would be exploring the logic of the endpoint used for uploading media. We could use a WPCOM sandbox environment to explore if/how the endpoint might be overridden/extended and why Atomic sites return a different value.

[dcalhoun]

I re-engaged debugging this for this past week.

• Both the iOS and Android apps receive the same response from the server endpoint.
• iOS fetches VideoPress metadata and relies upon the returned VideoPress URL.
• Android does not appear to fetch the VideoPress metadata and relies upon the remote URL included in the initial media upload request.

For anyone who continues work on this issue, I recommend further researching:

• Does the Android implementation ever fetch VideoPress metadata?
• Does Android need the metadata to mirror the iOS implementation?
• Is there an alternative URL in the response that could to be used?
• Could the current URL succeed if additional logic was added to Android?

Removing my assignment from this issue as I focus on other work.

[SiobhyB]

I believe this will be resolved when the changes in Automattic/jetpack#35637 are included in the upcoming 24.4 release.

With that change, when VideoPress v5 is detected (the default for dotcom video uploads), the videopress.com URL along with all the video's metadata will be fetched. This works for both platforms and also on the web, with the video's always remaining visible and editable in the editor.

Let me know if anything further needs to be iterated on here, but I'll go ahead to close for now.