Help / Troubleshooting
Reading the application log
When something goes wrong and you want to know why, Vesari Stylus has already written it down. The log is plain text, and it is worth a look before you report a problem.
Where the log lives
Open Settings, choose the Logs tab, then press the Logs button with the folder icon in the toolbar. File Explorer opens with the logs folder picked out. It sits inside the app's own data folder, %APPDATA%\com.garyd.audiophile-player, which you can paste into Explorer's address bar. Where Vesari Stylus keeps your files and settings covers the rest of what is in there.
Five files, not one
Each part of the app writes its own file, and a fresh set starts every day with the date on the end of the name.
| File | What it records |
|---|---|
audiophile-YYYY-MM-DD.log |
Startup, folder scans, watch folders, indexing counts, artwork, tag and sidecar writes |
audiophile-playback-YYYY-MM-DD.log |
Opening the output device, decoding and resampling, seeks, gapless chaining, device hand-offs |
audiophile-supertag-YYYY-MM-DD.log |
Super-Tag runs, and the MusicBrainz, AcoustID and Discogs lookups behind them |
audiophile-rip-YYYY-MM-DD.log |
The start of a rip, per-track results, stops and read failures |
audiophile-perf-YYYY-MM-DD.log |
Stage timings for a Super-Tag run. Nothing else writes here |
A file appears only on a day when that part of the app ran, so a day with no CD in the drive has no rip log. Open any of them in Notepad. Every line has the same shape:
[2026-08-19 14:02:11.518] INFO Scanning: D:\Music\Albums
The clock in the files is UTC, while the same entries in the app are stamped in your local time, so the two can sit hours apart.
One more file, perf.log, sits in the data folder itself rather than in logs. It is a spreadsheet-style list of CPU, memory and database-size samples with no file names in it, and it only fills while the resource sampler is running, which a Super-Tag run switches on.
Separate again is the log saved beside the music after a CD rip, rip-log.txt, or rip-log.partial.txt if you stopped early. The daily sweep never touches either, though a full re-rip clears the partial log it replaces. Reading the rip log & the "unverified" badge covers what it says.
The viewer inside the app
Under Application Logs on that same tab, entries appear as they happen, from all five categories in one stream, so you need not guess which file to open. Above the list sits the entry count, then the error and warning counts.
- All, Info, Warn and Error narrow the list by severity. Pressing Error is usually the fastest way to the moment it went wrong.
- All, Audio, Library and Meta narrow it by subject. These match on words in the message rather than on the file a line was written to, so treat them as a quick sieve, not an exact split.
- The search box filters on the words in a message.
- Clear empties the list on screen. It does not touch the files.
Two limits. The viewer holds the most recent 500 entries, and only from the session you are in. Anything older, or from a previous run, is in the files only.
How long they are kept
At every launch the app deletes any .log file in the logs folder that has not been touched for 30 days. The sweep looks at nothing else, so perf.log, your rip logs and the rest of the data folder are left alone.
What is safe to share
These files carry the full paths of your music, so folder names, drive letters and whatever your naming reveals. They also name your audio devices and the sample rates you played at. No password or API key is written into a log line; those live in the Windows Credential Manager.
Two ways to send one:
- Report a Bug, on the Support tab in Settings. Describe what happened and submit. Every log file touched in the last three days is bundled for you, each trimmed to its most recent portion, and the form says so on screen. You can attach up to six screenshots, or paste an image into the box. If it cannot be sent, the form tells you.
- Attach a file yourself. Pick the right day and subsystem, and if the paths bother you, edit it in Notepad first. Stripping paths makes some faults harder to trace, so make that trade knowingly.
Finding the moment it went wrong
- Note the time. The report form has a When did it happen? box and a Now button for exactly this.
- Open the Logs tab, press Error, then Warn, and read from the bottom.
- Search for a word from what you were doing, an album or device name.
- If it happened in an earlier session, open the file for that day instead, and read its timestamps as UTC.
If none of that explains it, send the report anyway. A log line that means nothing to you often means a great deal at this end. Is this a bug? How to report it covers what makes a report we can act on, and why the health counts can disagree covers the one case where a strange number is usually not a fault.