Consuming the stream¶

Sometimes, some modules require "Consuming" the stream to function properly. This means that instead of processing the tracks one by one, it will instead gather all the tracks generated by the seeders before continuing. However, this can result in infinite loops (or a really long generation time).

A fruity example¶

As an example, let's make some jam. Our process would be something like this:

1. Grab a fruit
2. Throw it away if it's bad
3. Peel it
4. Remove the seeds
5. Throw it into the pot
6. Repeat until all the fruits are in the pot and cook the fruits
7. Put the jam into a jar

Here, at instruction 6, we are forced to process all the fruits from our basket (the seeder) before we can continue.

But what happens if our basket contain infinite fruits? We are stuck endlessly filling the pot, and cannot proceed.

How to not get stuck¶

The answer is quite simple, don't use an infinite seeder with a consumer directly. Some modules can remove the infinite nature of seeder by either limiting the amount of tracks passing through, or only using a window of it

See Limiters

Surprise infinite seeders¶

Having no infinite seeders doesn't mean that consumers are totally safe either. Seeders are labeled "infinite" if their average use cases result in very large amounts of tracks. This means that, sometimes, some edge cases might occur where a safe seeder can still generate a lot of tracks.

For example, listen_seeder is generally safe. But if the user as a lot of listened tracks, it may start to slow down the radio.

A good rule of thumb is to not let the radio generation take more than 5 minutes. In most cases, assuming all the metadata is cached. However if the radio is expected to fetch data, you might want to include it. Past this time, the radio would benefit from limiters