MeteorLight/README.md

# MeteorLight

Radio streamer ([kawa](https://github.com/Luminarys/kawa) drop-in compatible).

This project is a Work in Progress.

`TODO: proper handling of audio queue <-> data queue, timeouts, ICY metadata`

# Improvements / differences from Kawa
* Does not use libav ([see supported formats/codecs on Kirika](https://git.gammaspectra.live/S.O.N.G/Kirika#codecs-supported))
* Supports HTTP clients that have more than 16 HTTP request headers.
* Does not restart stream per-track, instead being a continuous stream without parameter changes.
* Normalized channels / sample rates for mounts.
* Implements ICY metadata
* Uses sample/timed packet buffers, instead of kawa byte buffers, which cause wild differences between endpoints. Mounts usually align within 0.2s of each other, depending on client.


## Dependencies
### Go >= 1.18

### [Kirika](https://git.gammaspectra.live/S.O.N.G/Kirika) dependencies
Kirika is a collection of audio utilities for decoding/encoding files and streams.

Check its native dependencies that must be installed before usage.

## Usage
Start by copying example_config.toml to the location of your choice and reading through it. Of importance are `queue.fallback`, and `queue.random_song_api`.

MeteorLight will search for `config.toml` in its working directory. Alternatively you can pass `-config "/example/path/config.toml"` to specify a different location.

Batteries are not included - MeteorLight needs to be paired with your own software to find songs to stream.
You will have to provide an external API that MeteorLight can query for songs to play and notify as new songs being played.

Before continuing, you will need to install the dependencies listed above.

### From Git repository
```shell
$ git clone https://git.gammaspectra.live/S.O.N.G/MeteorLight.git && cd MeteorLight
$ go run . 
```

### From Go run
```shell
$ go run git.gammaspectra.live/S.O.N.G/MeteorLight@<commit_hash>
```

## API
See [kawa API](https://github.com/Luminarys/kawa#api) for a general overview. Additional endpoints or changed ones are listed below.

Track blobs returned have a `queue_id` parameter, regardless of source.

### `NEW` DELETE /queue/<queue_id>
Unqueues the track with `queue_id` specified as a parameter.

#### Response
```json
{
    "success": true,
    "reason": null
}
```

### `CHANGED` POST /queue/head
Same as kawa's, but `queue_id` is added to response directly.

#### Response
```json
{
    "success": true,
    "reason": null,
    "queue_id": 3
}
```

### `CHANGED` POST /queue/tail
Same as kawa's, but `queue_id` is added to response directly.

#### Response
```json
{
    "success": true,
    "reason": null,
    "queue_id": 5
}
```