(video-player) Playback service and storage

[OchiengPaul442]

Description

This PR enables view progress saving for all videos viewed within the app, so that any user can return to any video at any time, see their progress and resume playback from that position.

Video Player Service:

• A new service file has been created to handle the logic for video playback. This service is responsible for managing video states and interacting with the database.

Database Schema:

• A new Schema folder has been added. It contains the database schema needed to track video playback. The schema defines the structure of the video playback documents that will be stored in the database.

UI Display:

• Used material UI progress bar to display video progress.

Discussion

• This PR is addressing issue feat(video-player): playback service and storage #241: playback service and storage
• closes feat(video-player): playback service and storage #241

Preview

• N/A

Screenshots / Videos

Recording.2024-04-19.134003.mp4

[chrismclarke]

Hi @OchiengPaul442 - I started to take a look at this yesterday but ran out of time. All looking great, I have a few minor bits of code tidying intended which I'll just push to the branch, and I found a fix for the issue I think you picked up on for how to set the player time when starting to play for first time (requiring a small timeout) - I've also been testing on Android and have a few minor fixes to include.

If possible I'd say best to hold off on any more commits you have planned to push to the branch, as they will likely conflict with the review updates. I'll try to get them merged by the end of the day

[OchiengPaul442]

Hi @chrismclarke, Thanks for the review.
I’ll hold off on any further commits to the branch as requested.

[chrismclarke]

Thanks @OchiengPaul442 - I think the schema looks exactly what we need and I also appreciate the small UI progress bar you added.

I've made a few minor updates just to mention for your info:

1b359df - I noticed you had included the rxjs update method - I think that method is more designed for bulk updates to all docs retrieved from a query or computed update (e.g. +1 to all values), there's a separate patch method that handles single doc specific value changes that I've used instead. I've also used incrementalPath which supposedly handles concurrent updates a little bit better (e.g. if the video player gave frequent progress updates, not sure if actually required)

6b408dd - Just code tidying to rename the schema and collection files to more generic names, just to make it easier to replace if we ever need a v1 schema or v2

bcd4c48 - related to the android playback issues discussed on slack. This is a super messy commit I'm afraid, as I had first tried a bunch of different things which I then needed to revert. The main takeaway is removing use of jeepCapVideoPlayerExit for setting state as that is the one event that doesn't correctly identify the current player id. I also added a small workaround to better detect when the player is ready on android to be able to update the currentTime to allow the user to immediately play a video starting at the saved timestamp (previously there was the 500ms delay you had imposed to work around the issue)

But otherwise I've now tested and find both web and android video players running smoothly to toggle between multiple videos, starting and resuming from the saved states which I think is a huge user experience improvement for sure so thanks for all your work on this