A question that comes up constantly from small broadcasters is how to get a station into the radio apps people actually use. The answer is usually indirect. Most apps, Sentri Radio included, do not keep a hand curated master list of the world's stations. They read from open directories, and the route into the app is the route into the directory.
The largest of these is Radio Browser, a community maintained database with an open API and no registration requirement for lookups. Anyone can add a station, and an entry is a small set of fields: the stream URL, a display name, country and language, a homepage, a favicon URL, and a list of tags describing genre or format. Those tags matter more than they look, because they are what search and recommendation features in downstream apps operate on. A station tagged only with its own call sign will be found by people who already know it exists and by nobody else.
The single most important field is a stream URL that stays stable and answers directly. Directories run periodic automated checks, and a stream that fails those checks repeatedly is flagged as broken and drops out of default listings. The frequent causes are worth knowing in advance. A URL that returns a redirect chain may pass in a browser and fail an automated checker. A stream served over plain HTTP is blocked as mixed content by any web player running on HTTPS, which removes the station from browser based apps entirely even though mobile apps can still reach it. A server that requires a specific user agent, or that rate limits aggressively, will fail checks arriving from unfamiliar clients. Pointing the directory at a playlist file, a .pls or .m3u, rather than the underlying stream adds a layer of indirection that some players handle and others do not.
Now playing information is a separate mechanism, and it is the difference between a station that shows a song title and one that shows only its own name. The original method is ICY metadata, introduced by SHOUTcast and adopted by Icecast. A client sends an Icy-MetaData request header, the server responds with an Icy-MetaInt value giving the byte interval between metadata blocks, and at each interval the server injects a small block containing a StreamTitle field. The player strips those blocks out of the audio and reads the title. In practice the field is a single free text string, so the convention of writing artist, then a hyphen, then title is exactly that, a convention, and stations that write it differently produce parsing that looks broken to listeners.
Newer paths avoid the byte splicing entirely. HTTP Live Streaming carries programme information as timed metadata inside the media segments with precise timestamps, which removes the drift ICY suffers from when a player buffers heavily. Many stations also publish a JSON now playing endpoint alongside the audio, and Icecast, AzuraCast, and Radio Paradise all expose status APIs of this kind. Players that want artwork, album data, and links out to streaming catalogs generally read those endpoints and fall back to ICY for compatibility.
Two smaller details are worth setting correctly at the start. Serve a square logo at a reasonable resolution and give the directory its URL, because apps display that image everywhere the station appears and a missing one makes an entry look abandoned. Set the codec and bitrate fields honestly, because listeners filter on them and a station claiming a bitrate it does not deliver generates complaints rather than listeners.
Once the entry is live and passing checks, appearing in individual apps takes care of itself on their next directory sync. The listing signals most apps rank by, click counts and votes, then accumulate on their own from real listening.
References:
Radio Browser. API Documentation. api.radio-browser.info.
Xiph.Org Foundation. Icecast 2 Documentation: Server Statistics and Metadata.
Pantos, R., & May, W. (2017). HTTP Live Streaming. RFC 8216, Internet Engineering Task Force.