Fix: typos (#2743)

doc/ethereum.md

@@ -39,7 +39,7 @@ The following options can be used to set the max gas price to `<MAX_GAS_PRICE>`,
 The following options can be used to get the min gas price:
 
 - `curl localhost:7935/minGasPrice`
-- Run `livepeer_cli` and observe the min gas price in the node statts
+- Run `livepeer_cli` and observe the min gas price in the node stats
 
 The following options can be used to set the min gas price to `<MIN_GAS_PRICE>`, a Wei denominated value:
 

doc/go.md

@@ -16,7 +16,7 @@ There are a few ways to manage different Go versions:
 1. [go install](https://go.dev/doc/manage-install)
 2. [gvm](https://github.com/moovweb/gvm)
 
-Using `gvm` has the benefit of automatically aliasing `go` to whichever version of Go you are currently using as opposed having to use a command like `go1.10.7`.
+Using `gvm` has the benefit of automatically aliasing `go` to whichever version of Go you are currently using as opposed to having to use a command like `go1.10.7`.
 
 **gvm: Installing arm64 binaries on >= macOS 11**
 

doc/gpu.md

@@ -38,7 +38,7 @@ CUDA | Nvidia
 10.2 | 440.33.01, 440.118.02
 11.1,11.2 | 460.39
 
-Nvidia's 450.xx drivers can occassionally lead to stuck transcoding sessions.
+Nvidia's 450.xx drivers can occasionally lead to stuck transcoding sessions.
 Refer to this [forum post](https://forum.livepeer.org/t/working-around-occasional-transcoding-issues-with-nvidia-driver-450/1219) on how to switch to a different driver version.
 
 All Nvidia chipsets from [the Maxwell series](https://developer.nvidia.com/maxwell-compute-architecture) and later, that have NVDEC/NVENC cores, should theoretically be supported by go-livepeer.

doc/httpcli.md

@@ -7,11 +7,11 @@ By default, the CLI listens to localhost:7935. This can be adjusted with the -cl
 
 
 
-`/getLogLevel` returns currrent verbosity level in the body of response
+`/getLogLevel` returns current verbosity level in the body of response
 
 `/setLogLevel` sets verbosity current level. Level to set should be provided in body of the request, encoded as `application/x-www-form-urlencoded`. Parameter should be named `loglevel`.
-It can be used from command like this this:
+It can be used from command like this:
 
 `curl -F loglevel=6 http://localhost:7935/setLogLevel`
 
-Log level should be integer from 0 to 6, where 6 means most verbose logging.
+Log level should be integer from 0 to 6, where 6 means most verbose logging.

doc/ingest.md

@@ -68,7 +68,7 @@ Streams can be authenticated through a webhook. See the documentation on the
 The RTMP stream can be played back, or pulled from Livepeer by another part of
 the ingest infrastructure. To prevent unauthorized RTMP playback of streams
 whose name is known, a stream key is randomly appended to the playback URL at
-ingest itme. However, the broadcaster can control the stream key by
+ingest time. However, the broadcaster can control the stream key by
 appending the key to the RTMP URL.
 
 
@@ -122,7 +122,7 @@ segment to a path ending with ".mp4" rather than ".ts", such as:
 http://broadcasters:8935/live/movie/14.mp4
 ```
 
-Possble statuses returned by HTTP request:
+Possible statuses returned by HTTP request:
 - 500 Internal Server Error - in case there was error during segment's transcode
 - 503 Service Unavailable - if the broadcaster wasn't able to find an orchestrator to transcode the segment
 - 200 OK - if transcoded successfully. Returned only after transcode completed 

doc/multi-o.md

@@ -24,7 +24,7 @@ livepeer \
 
 ## Single Orchestrator with Redeemer
 
-This setup allows an operator to use a seperate Ethereum account for redeeming winning tickets on-chain and paying for that transaction while the ticket recipient is still the operator's on-chain registered Ethereum address.
+This setup allows an operator to use a separate Ethereum account for redeeming winning tickets on-chain and paying for that transaction while the ticket recipient is still the operator's on-chain registered Ethereum address.
 
 The Orchestrator node will still be responsible for calling `reward`*.
 
@@ -112,4 +112,4 @@ livepeer \
     -ethOrchAddr <ORCHESTRATOR_ON_CHAIN_ETH_ADDR (also the recipient address)> \
     -redeemerAddr <REDEEMER_HTTP_ADDR> \
     -pricePerUnit <PRICE (wei/pixel if '-pixelsPerUnit' is not set)>
-```
+```

doc/networking.md

@@ -5,12 +5,12 @@
 ![broadcaster-transcoder network v2 1](https://user-images.githubusercontent.com/292510/41455677-c8437268-7032-11e8-9ce8-bfdd9b6e3fc0.png)
 [Sequence diagram source](https://sequencediagram.org/index.html#initialData=C4S2BsFMAIBkQG6QA6UgJ2gOUsA7gPboDWIAdgObQIBMAUHcgIbqgDGIzZw0ASpBRABnYOgCedAELoCTACZsmIjAFoAfP0EjxALmgB5dGwAWkbU2BE+kAI51Nw0WJXrpshUuAY9hk2dEWVvxCyAxu8orK6Oq+puaW6DoAOmQAKuhMZEJsBHIY1nbhHlEAPC6x-hkJOumZ2bn5AJJkAGYEDAzgBAShRZFe0Wq1WTl5idAAygIAtpDcBVIyEZ4YZSrD9WN6UxSz88Ghc3J0QA)
 
-For a reference each message used by Livepeer, refer to the [Protocol Buffers definitions](https://github.com/livepeer/go-livepeer/blob/master/net/lp_rpc.proto).
+For a reference to each message used by Livepeer, refer to the [Protocol Buffers definitions](https://github.com/livepeer/go-livepeer/blob/master/net/lp_rpc.proto).
 
 
 ## Broadcaster to Registry
 
-The broadcaster does an on-chain lookup to retrieve the orchestrator's ServiceURI in order to discover prices, capabilities and to initiate an transcoding job.
+The broadcaster does an on-chain lookup to retrieve the orchestrator's ServiceURI in order to discover prices, capabilities and to initiate a transcoding job.
 
 ## Broadcaster to Orchestrator:
 
@@ -144,7 +144,7 @@ message TranscodedSegmentData {
 
 Currently, any errors are dumped directly into the response in stringified form. This gives broadcasters more information to diagnose problems with remote transcoders. However, we may not want to return such details forever, as this may leak internal information that is best left private to a transcoder.
 
-Broadcasters can use the difference in time between the request submissing and the 200ok to approximate the upload time. The time between the 200ok and receiving the response body approximates the transcode time.
+Broadcasters can use the difference in time between the request submission and the 200ok to approximate the upload time. The time between the 200ok and receiving the response body approximates the transcode time.
 
 There is an end-to-end request timeout of 8 seconds, However, issues are likely to appear earlier, and any issues will likely to lead to gaps in playback and stuttering. For example, live streams that consistently take 4+ seconds (the segment length) to upload and transcode will be outrun by players.
 
@@ -187,11 +187,11 @@ message Ticket {
 }
 ```
 
-The `Redeemer` will send back an empty message, `QueueTicketRes` on success as well as a `200 OK` status. Upon error a `500 Internal Server Error` error code will be returned along side the error. 
+The `Redeemer` will send back an empty message, `QueueTicketRes` on success as well as a `200 OK` status. Upon error a `500 Internal Server Error` error code will be returned alongside the error. 
 
 ### gRPC `MaxFloat`: `MaxFloatReq` -> `MaxFloatUpdate`
 
-`MaxFloat` is a unary RPC method that is called by an Orchestrator when it requires the max float for a sender but no local cache is available. It's request takes in a sender's ethereum address:
+`MaxFloat` is a unary RPC method that is called by an Orchestrator when it requires the max float for a sender but no local cache is available. Its request takes in a sender's ethereum address:
 
 ```protobuf
 message MaxFloatReq {
@@ -209,7 +209,7 @@ message MaxFloatUpdate {
 
 ### gRPC `MonitorMaxFloat`: `MaxFloatReq` -> stream `MaxFloatUpdate`
 
-`MonitorMaxFloat` is a server-side streming RPC method that is called by an Orchestrator to receive max float updates for a sender. The stream will remain open until either the client or the server closes the stream or connection. 
+`MonitorMaxFloat` is a server-side streaming RPC method that is called by an Orchestrator to receive max float updates for a sender. The stream will remain open until either the client or the server closes the stream or connection. 
 
 The request follows the same format as the `MaxFloat` method:
 

doc/redeemer.md

@@ -12,7 +12,7 @@ _Max float_ is the guaranteed value an Orchestrator will be able to claim from a
 
 ## TicketQueue
 
-1. The `ticketQueue` is a loop that runs everytime a new block is seen. It will then pop tickets off the queue starting with the oldest ticket first, and sends it to the `LocalSenderMonitor` for redemption if the `recipientRand` for the ticket has expired. 
+1. The `ticketQueue` is a loop that runs every time a new block is seen. It will then pop tickets off the queue starting with the oldest ticket first, and sends it to the `LocalSenderMonitor` for redemption if the `recipientRand` for the ticket has expired. 
 
 2. When the `LocalSenderMonitor` receives a ticket from the `ticketQueue` it will substract `ticket.faceValue` from the outstanding `maxFloat` as long as the ticket is in limbo. 
 
@@ -30,7 +30,7 @@ _Max float_ is the guaranteed value an Orchestrator will be able to claim from a
 
 2. A second RPC call to `MonitorMaxFloat(sender)` will open up a server-side gRPC stream to receive future update. 
 
-_If this call fails the response from step 1 is returned, but not kept in cache to to prevent it becoming stale due to not being able to receive further updates_
+_If this call fails the response from step 1 is returned, but not kept in cache to prevent it becoming stale due to not being able to receive further updates_
 
 3. The `Redeemer` goroutine started by the RPC call in step 2 will start a subscription to listen for max float changes from the `LocalSenderMonitor` for the specified `sender` using `LocalSenderMonitor.SubscribeMaxFloatChange(sender)`.
 
@@ -53,7 +53,7 @@ _Each open server-side stream will have its own subscription that will be closed
 
 So far we've discussed `LocalSenderMonitor.addFloat()` and `LocalSenderMonitor.subFloat()` being responsible for triggering `LocalSenderMonitor.SubscribeMaxFloatChange(sender)` notifications, but these can also be triggered by certain Ethereum events related to the Livepeer protocol: 
 
-- FundReserve: When a broadcaster funds it's reserve the `maxFloat` allocation increases by the added reserve divided by the active Orchestrator set size.
+- FundReserve: When a broadcaster funds its reserve the `maxFloat` allocation increases by the added reserve divided by the active Orchestrator set size.
 - NewRound: If the active Orchestrator set size changes, the `maxFloat` will become the current broadcaster's reserve divided by the new active set size. Since this event impacts all participants in the protocol the `Redeemer` will have to send updates for _every_ `sender` it is keeping track of. 
 
 ![Ethereum Events](./assets/redeemer/eth-events.png)

doc/reliability.md

@@ -12,7 +12,7 @@ The `BroadcastSessionsManager` stores orchestrators in two lists, a `sessList` a
 
 ## Orchestrator List Refresh
 
-The orchestrator list is refreshed when the number of sessions in `sessList` is less than double the `HTTMPTimeout` in seconds (hard-coded to 8 seconds at the moment) divided by the lenght of segments (hard-coded to 2 seconds at the moment) OR less than the size of the OrchestratorPool saved on disk, whichever is less (i.e. when its length is less than what is required to keep in memory). This happens at startup (as described above), and when an orchestrator is selected for individual transcoding in `selectSession`.
+The orchestrator list is refreshed when the number of sessions in `sessList` is less than double the `HTTMPTimeout` in seconds (hard-coded to 8 seconds at the moment) divided by the length of segments (hard-coded to 2 seconds at the moment) OR less than the size of the OrchestratorPool saved on disk, whichever is less (i.e. when its length is less than what is required to keep in memory). This happens at startup (as described above), and when an orchestrator is selected for individual transcoding in `selectSession`.
 
 ## Orchestrator Selection