Page History

State Model

...

This state machine describes the state transitions per player session in the Rialto Client.

...

format	SVG
title	sdfg

@startuml

hide empty description

state All {

...

.

...

PlantUML Macro
title Rialto client player session state machine
@startuml hide empty description state All { All --> Failure: server.failure All --> [*]: client.stop(), server.PLAYBACK_STATE_STOPPED state Seekable { [*] --> Buffering: server.NETWORK_STATE_BUFFERING / server.NETWORK_STATE_BUFFERING Buffering --> Playing: server.PLAYBACK_STATE_PLAYING Playing --> Buffering: server.NETWORK_STATE_STALLED Seeking --> Buffering: server.PLAYBACK_STATE_FLUSHED Seekable --> Seeking: server.PLAYBACK_STATE_SEEKING All --> Eos: server.PLAYBACK_STATE_EOS } } @enduml

State diagram snapshort since PlantUML not rendering correctly above:

Image Added

State Behaviour

...

The following table defines how various calls should be handled by Rialto client depending on the state of the player session:

Rialto Client State	setPosition	haveData	needData
Buffering	Process normally	Process normally	Process normally
Playing	Process normally	Process normally	Process normally
Eos	Process normally	Unexpected, log warning & discard	Unexpected, log warning & discard
Seeking	Process normally	Expected, log info & discard*	Expected, log info & discard*
Failure	Unexpected, log warning & discard	Unexpected, log warning & discard	Unexpected, log warning & discard

*Due to race conditions between client & server it is possible to get stale needData() & haveData() notifications and these should be ignored.