Privacy Policy

Last updated: September 17, 2026

AudiophileRadio.com ("we", "us", "our") operates the website audiophileradio.com and the AudiophileRadio mobile & TV app (Android & iOS). This page explains what data we collect, why, and how.

1. At a glance

We do not require an account. We do not collect your name, email address, phone number, precise location, contacts, or any advertising identifier. We do not use third-party analytics or advertising SDKs; the one third-party component in the app is the crash reporter in § 13. The app's preferences and personal lists live on your device, and uninstalling removes them — unless your phone's own backup has copied them to your Google account (§ 3).

What we do have is what any web server has: a log of the requests made to it, including the IP address they came from, kept for 52 days (§ 2, § 5). The rest of this page is the detail, and where the detail is less flattering than the summary we have tried to say so.

2. Website – server logs

Our web server (like every web server on the internet) automatically records standard access logs: your IP address, browser type, pages visited, the page that linked you to us if there was one, and timestamps. These logs are used to diagnose technical problems and to produce anonymous, aggregate usage statistics for our own use, such as how many people visited the site or listened to a station each day. Those statistics contain only totals: no IP addresses and nothing that identifies a person or a device. The logs themselves are deleted after 52 days. They are never shared with third parties.

Two details for completeness. The server keeps a second, much smaller log of errors, which records the same IP address when a request fails, and it is deleted on the same 52-day schedule. And we take a copy of our databases every night in case the server is lost; those copies are kept for two weeks on the server and are pulled to a machine at home, where they are kept for up to a year and then deleted. The databases they contain hold no visitor identities beyond what § 6, § 7 and § 10 describe.

3. Mobile / TV app – what stays on your device

The app stores the following on your device, in Android/iOS shared preferences and its cache directory. None of it is sent to us, or to anyone else, except where a line below says otherwise — and except for your phone's own backup. Android copies app data to your Google account by default and restores it after a reinstall; that is between you and Google, but it means "uninstalling removes it" is only true if that backup is off. It covers your settings and lists; the cached images and the chime below are kept in a cache folder that Android leaves out.

  • Favourite tracks – for each track you mark: the artist, the title, when you added it, the station you heard it on, and the cover and preview links we found for it. The list itself stays on your device, apart from two things. One: at the moment you favourite a track, that single artist and title are sent to our server to look up a cover image and a preview link for it (§ 4). Nothing in that request says who or which device asked — but it is a normal web request, so the artist and title appear in that day's server log next to your IP address and stay there for 52 days like every other line (§ 2). We also keep the answer for a few months so the next person to favour the same track costs us no second lookup; that cache is filed under a one-way code made from the artist and title, and holds the image, preview and store links we found. Two: if you use the transfer feature in § 10, the whole list is uploaded for a few minutes so another device can collect it.
  • Listening time – per-station listening duration, used only to sort the station list on your screen.
  • Cached station list – the catalogue returned by our server, kept for fast app startup and refreshed when it changes.
  • Version-check cache – the most recently fetched minimum and latest version numbers plus a timestamp, so we don't re-check on every launch.
  • Cached cover art – JPEG images of recently shown album covers. Capped at 80 MB; automatically pruned on a least-recently-used basis.
  • Welcome chime audio – a tiny FLAC file used to warm up the audio pipeline on app start.
  • Your settings – Bit-Perfect on or off, the adaptive-buffer level, the last station you played, whether you dismissed the battery-optimisation prompt, and similar preferences.

Uninstalling the app removes all of the above.

4. Mobile / TV app – what we send to our server

While the app is open — or while it is playing in the background, which is most of the time it is useful — it talks to our server for the following:

  • Station list – a single request to audiophileradio.com/api/stations.php at startup, returning the catalogue of supported stations.
  • Version check – a lightweight request to audiophileradio.com/api/min_version.php at most once every 24 hours, returning the minimum and latest supported app versions plus a download URL. Used to surface an "update available" prompt when relevant.
  • Now-playing metadata – the slug of each station whose current track appears in the app at that moment (the one playing on your device plus the ones visible on the home grid). Sent to audiophileradio.com/backend/nowplaying.php and audiophileradio.com/backend/all_nowplaying.php approximately every 20 to 30 seconds. The grid's request stops when you background the app or leave that screen; the one for the station you are actually listening to carries on for as long as it plays, because the track name on your lock screen, in the car and on your headphones comes from it. It stops when you stop.
  • The welcome chime – a tiny sound file fetched once and then kept on your device, used to wake the audio pipeline so the first station starts quickly.

These requests carry no account identifier, no user identifier, and no advertising identifier — the app does not use any. Standard HTTP metadata (IP address, User-Agent) reaches our web server and ends up in the access logs described in section 2.

Since version 1.1.4 the app sets its own User-Agent, for example AudiophileRadio/1.1.4+70 (androidPhone). It carries two things: the app version, and which kind of screen it is running on (phone, TV, car, or car dashboard). It is there so that we can tell how many people are still on an old version or are listening in the car — today only by reading the log by hand; the nightly statistics in section 2 do not break it down. It contains nothing that identifies you or your device, and it is the same string for everyone using that version on that kind of screen. It is sent only to audiophileradio.com. When the app connects to a radio station it sends a different, fixed line that names the app alongside a generic browser, which some stations require in order to serve anything at all. It never carries your real version or your screen, and on some reconnections nothing is sent and the station sees whatever the audio engine says by default. Bit-Perfect mode (§ 7) uses a third fixed line of its own. Cover-art services receive no app identifier whatsoever.

5. What our logs can tell about listening

An earlier version of this section described sending us a record of each track played, for a most-played chart. It was never built; there is no such feature and nothing on our server that would accept one. If we ever add it, this page changes first.

What is worth saying instead is the thing that follows from § 2 and § 4 together, and that a careful reader deserves to be told plainly. While you listen, the app and the website ask our server every half minute or so what is playing on that station, and they ask by name. Each of those requests is a line in the access log next to your IP address. So for 52 days our logs do contain, in principle, which station a given address listened to and for how long.

We do not use them that way. Each night a program reads the previous day's log, works out in memory how many separate people listened and for how long, and writes down only the totals — visitor counts, per-station counts, and a histogram of how long sessions lasted. No addresses, no sessions, nothing per person is kept (§ 2). There is also a live count on the owner's own statistics page, which reads the last couple of minutes of the log to show how many people are listening right now; it displays numbers, never an address, and stores nothing.

But "we choose not to" is a weaker promise than "we cannot", and you should know which one this is. If you want the stronger one, the honest answer today is that we do not have it: the raw address sits in the log for 52 days because that is what we use to investigate abuse and to debug the rate limiter. Shortening that, or blanking the last part of each address once a week has passed, is on our list.

6. Buffering diagnostics (website and app)

To find stations that stream poorly from particular parts of the world, the website and the app watch for a station falling behind while you are listening. On the website that means counting the seconds in which the sound arrived slower than it was played; in the app it also means counting the times the stream was cut and had to be reconnected. If enough of those pile up — three is the threshold — a small anonymous report is sent when you leave the station, close the tab or switch away from it. It contains the station, those counts, the total time lost, and whether you were listening on the website, a phone, a TV or in the car. It carries no account, no user or device identifier, and nothing about which track was playing.

From the IP address that reaches our server (the same metadata noted in section 2) we derive a country, so we can tell that a station rebuffers for listeners in one region but plays cleanly elsewhere. We store the country and the buffering counts. We do not store your IP address with these reports; in its place we keep a one-way code that changes every day, which lets us count how many separate listeners were affected without following anyone from one day to the next. Being exact, as in § 5: the report arrives as an ordinary web request, so for 52 days it sits in the server log beside the address that sent it and could in principle be matched back. What we store in the report cannot be turned back into an address. We do hold the key that made it, so someone with an address in hand could check whether it matches — we do not do that. After 52 days the log line that would tie an address to a report is gone, but the reports themselves are kept (below) and the key does not change, so that check would remain possible for any past day. It is a check, not a way of turning a report back into an address. Country lookup uses the free DB-IP database (db-ip.com), which is a file sitting on our own server — your address is never sent anywhere to be looked up.

These reports are not deleted on a schedule. Each is a handful of numbers and a country, and we keep them so that a station's behaviour this winter can be compared with last winter's. Because the code changes every day, two reports from different days cannot be recognised as coming from the same listener. The same is true of the converter reports in § 7.

7. USB DAC compatibility (experimental Bit-Perfect mode)

Bit-Perfect mode is off unless you turn it on. It sends audio straight to a USB digital-to-analogue converter at the station's own sample rate instead of through Android's audio mixer. It is experimental: it works with some converters and not others, and we have no way to know which without hearing from the people who try it.

So when you use it, the app sends one short anonymous report per converter model: the USB manufacturer and product identifiers and names, a few technical capabilities read from the device itself, whether our driver could take it over, your phone model and Android version. It carries no account, no user or device identifier, and nothing about what you listened to. The same country lookup and daily one-way code described in section 6 apply, with the same caveat about the server log. The app sends this once per converter and outcome, not every time you listen. Turning Bit-Perfect mode off in Settings stops it entirely.

8. Radio streams

When you play a station, your device connects directly to that station's streaming server. We do not host, encode, store, proxy or rebroadcast any radio audio — every stream plays directly from the station's own server. The station operator's privacy policy applies to that connection. The station's own server may log your IP address according to its own policy. Many station streams use plain HTTP rather than HTTPS; the app accepts this so the catalogue can stay inclusive. Station availability and content are the responsibility of the station operators.

9. Cover-art metadata sources

We resolve album covers and artist portraits for currently-playing tracks via the iTunes Search API, MusicBrainz (and the Cover Art Archive), Last.fm, and the English Wikipedia API. These lookups happen on our server, not on your device: what we send them is the artist and title the station is broadcasting (the Cover Art Archive gets only a record number from MusicBrainz), never anything about you. Last.fm additionally receives our own API key. Wikipedia is asked only for an artist name, and only on classical stations.

We then hand the resolved image address back to the app or to your browser, whichever asked, and it downloads the picture straight from wherever it lives — usually mzstatic.com (Apple), coverartarchive.org, last.fm, upload.wikimedia.org, or the station's own server. That is a direct connection from your device to them, so those companies see your IP address and that the request came from our site — we set a header that stops the exact page being passed on, and the app sends no such information at all. This applies to the website exactly as it does to the app. For some artists we serve hand-curated portraits from audiophileradio.com instead, and then nobody else is involved.

Two further services appear when you favourite a track (§ 3). We ask the iTunes Search API for a cover and a thirty-second preview, and if it has no preview for it — which happens for tracks it knows as well as ones it doesn't — we ask Deezer instead. Both receive the artist and title, nothing more. If you then play that preview, your device streams it directly from Apple's or Deezer's own servers, so they see your IP address for those thirty seconds.

10. Favourite-track transfer feature

The app can transfer your favourite-track list from one device to another via a six-character pickup code. The list is uploaded to our server, held briefly, and deleted on first read or after 15 minutes — whichever comes first. The pickup code is the only credential, so it is shown to you as transient and meant to be used immediately. We do not retain the data beyond that window.

Two things we would rather spell out than leave you to assume. The clearing-out is lazy: an expired list is removed the next time somebody uses this feature, not by a clock, so in a quiet week it can sit in the database a while longer and be caught by that night's backup (§ 2). And because the code is short enough to guess, the endpoint keeps a note of the IP addresses that have tried recently, so that someone working through the possibilities is slowed down and then refused. Those notes cover every request to this feature, not only the guesses, and they are cleared by that same lazy sweep. They are not the only address we hold outside the server logs: a failed login to the admin area writes one to a small file that is tidied up irregularly, and that file is not backed up. The transfer notes are, since they sit in the database we copy every night — so one of those addresses can outlive the original in a backup, for as long as § 2 says those are kept.

11. App permissions

On Android, the app declares the following permissions:

  • INTERNET – required to fetch station streams and the catalogue.
  • FOREGROUND_SERVICE and FOREGROUND_SERVICE_MEDIA_PLAYBACK – required so audio keeps playing when the screen is off or the app is in the background, as Android requires for any media-playback app.
  • WAKE_LOCK – keeps the audio thread alive while playing.
  • ACCESS_NETWORK_STATE – added by the audio engine we use, which adapts how much it buffers to the kind of connection you are on. The crash reporter reads it too, to note whether a crash happened on Wi-Fi or mobile data.
  • REQUEST_IGNORE_BATTERY_OPTIMIZATIONS – lets the app ask you, once, to exempt it from battery optimisation. Some phones stop background audio after a while otherwise. It only opens Android's own dialog, and saying no is fine — the app keeps working. If you decline, it may ask again a fortnight or a month later, depending on how you declined; once you allow it, it stops asking.

The app does not ask for permission to post notifications, even though it shows one while playing. Android exempts the media notification of a playback service from that permission, so asking would gain nothing and would put an extra dialog in front of you on first run.

One permission is asked at the moment you need it rather than declared up front: if you turn on Bit-Perfect mode (§ 7), Android asks whether this app may talk to the USB converter you have plugged in. That prompt comes from Android, not from us, and it covers that device only.

On iOS, the app uses standard AVFoundation playback APIs and declares no microphone, camera, location, contacts, photo-library, or tracking permissions.

12. Cookies

The public website sets no cookies at all — not tracking ones, not advertising ones, not even its own. One cookie exists in the admin area, which needs a password and which no visitor has any reason to find; it lasts up to 30 days, though the login it belongs to stops working after 12 hours. The mobile / TV app uses no cookies either.

The website does keep three small notes in your browser's own storage. They never travel to us as values, they are not identifiers, and clearing your site data removes them:

  • whether you dismissed the notice about Safari, and the one about iPhone and iPad, so we don't show them again;
  • a marker the site owner's own browser sets, by visiting a page only he can reach, so that his listening is left out of the visitor counts in § 2. It is the one note that changes what your browser asks for: those requests carry a flag our statistics look for and skip.

13. Third-party services

We do not use Google Analytics, Facebook Pixel, or any other third-party analytics or advertising service. The app contains no advertising SDKs and shows no ads.

For crash reporting we use Sentry (sentry.io), hosted in the European Union (Frankfurt). When the app encounters an uncaught error, Sentry receives: the error type and message, the call stack, and the sort of context any crash reporter collects — device model and make, OS version, app version, language and time zone, whether you were on Wi-Fi or mobile data, free memory and battery, and whether the device is rooted — together with an installation identifier, made once and normally replaced by a new one if you reinstall, though your phone's own backup may restore the old one (§ 3). The SDK also pings Sentry when the app starts and stops, carrying that same installation identifier and version, so that crash rates can be expressed per launch rather than in a vacuum. We never deliberately send it your listening history, your favourites, your IP address (we switch that off explicitly), screenshots, or a picture of the screen's layout.

One honest caveat, because "never" is a strong word. A crash report contains the error message and the call stack, and when the thing that failed was playback, the message can contain the address of the stream that failed — which names the station you were listening to at that moment. We discard the common network errors before they are sent, but we cannot promise that no playback error ever carries a station address into a crash report. It would be one station at one moment, in a report nobody reads unless the app broke; it is not a listening history. We would rather write that down than claim a guarantee we have not proved.

Crash reports are retained by Sentry for 90 days and then deleted. You cannot currently opt out of crash reporting in the app; if you object, the app can be uninstalled.

Everyone else your device talks to, it talks to directly, which means they see your IP address and we see nothing of it:

  • the radio station you are listening to, for as long as you listen (§ 8);
  • the cover-art hosts in § 9, once per picture, from the website as well as the app;
  • Apple or Deezer, if you play a thirty-second preview (§ 9);
  • Google, if you open audiophileradio.com/app — that address is a signpost that sends you on to the Play Store, and it appends a note saying where you came from (for example, a link we posted) so we can tell which posts bring people in. It says nothing about you;
  • Sentry, for the crash reports and start/stop pings described above. Its servers see your address in transit, as any server does; we have told it not to record one.
  • Spotify, YouTube Music or YouTube, if you tap one of those buttons on a favourited track. We hand them the artist and title as a search; they are companies you are most likely signed in to, so they will know it was you who searched. That happens only when you tap.

14. Children's privacy

The app and website are not directed to children under 13. There is no account, no sign-up and no user-generated content, so we never knowingly ask anyone for personal information. A child using the site or the app leaves the same thing an adult does and nothing more — a line in our web-server logs (§ 2), and, if they use those parts of the app, the same favourite lookup (§ 3), buffering report (§ 6), converter report (§ 7), transfer (§ 10) or crash report (§ 13) that anyone else leaves.

15. Your rights

We hold very little about you, but not nothing, and we would rather be exact than flattering. Our web server writes an access log entry for every request: your IP address, what was requested, and what your browser says it is. Those logs are kept for 52 days and then deleted (§ 2). An IP address is personal data under the GDPR, so the rights to access it, correct it or have it deleted do apply to it. The same is true of the short-lived rows described in § 10.

What we do not have is any way to connect that to you as a person. There is no account, no email address and no profile, and nothing we issue that follows you between visits — the one identifier in play is the crash reporter's, which belongs to Sentry and never reaches these logs (§ 13). So we cannot look you up by name. We can only search by IP address and a time window. If you want to exercise one of those rights, write to us (§ 17) with the address you used and roughly when, and we will tell you what is there and delete it. Two honest caveats: on a shared or mobile address we may have to ask what makes us confident it was yours, since the lines may be someone else's; and we do not edit the nightly backups in § 2, so a copy can outlive a deletion. Often the answer will simply be that the 52 days have passed and nothing remains.

Everything the app keeps on your device — favourites, listening time, caches (§ 3) — is yours and never leaves it except where this policy says otherwise. Uninstalling the app, or clearing its storage in your device settings, removes all of it at once.

16. Changes to this policy

If we make material changes, we will update the "Last updated" date at the top of this page and adjust the corresponding App Store / Play Store privacy disclosures.

17. Contact

Questions about this policy? Email us at hi@audiophileradio.com.