-
Notifications
You must be signed in to change notification settings - Fork 73
Collecting Logs
How to capture a diagnostic report and attach it to a bug report. Playback problems depend heavily on your media, server, and device, so a log is usually the difference between a bug being fixed and being closed unsolved.
Two things about Moonfin's logging decide the whole procedure:
- It's off by default. Nothing is being recorded right now.
- It's kept in memory only. There's no log file on your disk to go looking for, and closing or restarting the app throws the buffer away.
So you can't collect a log for something that already happened. You have to turn logging on first, then make the problem happen again.
The buffer holds the most recent 2000 entries. If you reproduce the problem and then keep using the app for a while, the interesting part can be pushed out, so send the report soon after.
- Go to Settings > About > Diagnostics & Logging. You can also type
logs,report, ordebuginto the settings search to jump straight there. - Turn on Enable diagnostic logging.
- Repeat the actions that cause the problem, all the way through to the failure.
- Don't restart the app. Go straight back to Settings > About > Diagnostics & Logging.
- Press Copy all logs and paste it onto the issue, as described below.
The Reports heading shows how many entries were captured. If it says zero, logging wasn't on while you reproduced the problem, so start again from step 2.
The report has to end up on the GitHub issue itself. Nothing in the app sends it to us.
Press Copy all logs. The whole report goes to your clipboard, and you paste it into a GitHub comment inside a fenced code block:
```
paste the report here
```
This is the route to use. It works on every platform and every server type, and it works even when you're not signed in to a server at all, which makes it the only option for login and connection problems.
To send a single line rather than everything, tap any entry under Recent logs to copy just that one.
This button uploads the report to your own server, the one you're signed in to. It doesn't send anything to the Moonfin developers, and the filename it shows you afterwards, something like upload_Moonfin_1.0.0_20260802.log, is meaningless to anyone who can't read that server. Posting the filename on an issue achieves nothing.
It's worth using in one situation: you administer that server, and you'd rather attach a file than paste a wall of text. In that case send the report, then open Administration > Logs, find the file, and use Save log file to write it to disk so you can drag it onto the issue.
The button is disabled when:
- you're on Emby. Report upload is a Jellyfin feature.
- logging is off, or no entries have been captured yet. The button's subtitle tells you which.
Under Recent logs, the Filter control limits the list to one category: General, Media, Seerr login, Network, Authentication, Playback, or Sync.
The filter changes what you see on screen. Copy all logs and Send report to server always send the complete report regardless of the filter, which is what we want, so please don't try to trim it by hand.
Every report starts with a short header:
Moonfin diagnostic report
Generated: 2026-08-02T14:03:11.482
App: Moonfin 1.0.0
Device: Living Room TV (a1b2c3d4)
Entries: 412
Platform: android
============================================================
Then one line per entry, in the form <timestamp> <level> [<category>] <message>, with any error indented underneath on its own line.
Playback entries carry a lot on their own, which is why a report is worth attaching even when the failure looks obvious:
- The playback decision for each item, saying whether it direct played, direct streamed, or transcoded, and what the server gave as its reasons
- The audio path, naming the decoder in use and whether the track was bitstreamed to a receiver or decoded and sent as PCM
- On Android TV, what the Dolby Vision chain did with a Profile 7 file, which route it settled on, where the metadata came from, and what the converter produced
- Playback errors with the underlying cause rather than a bare message, which is usually enough to name the failure without a second round of questions
Reports are written for humans, so have a look before you post one publicly. They can include your server's address, device name, library and media titles, and request URLs. They don't include your password. If something in there is sensitive, replace it with REDACTED rather than deleting the line, so the surrounding timing still makes sense.
Clear captured logs discards everything currently held. Useful when you want a clean report containing only one reproduction: clear, reproduce, send.
Turning Enable diagnostic logging back off stops collection. It's fine to leave it on if you're chasing an intermittent problem, though remember that the buffer still doesn't survive a restart.
Administration > Logs shows your server's logs, not the app's. Those are Jellyfin's or Emby's own, they need admin rights, and they are useful for a different class of problem, transcoding decisions in particular. A client report you uploaded with Send report to server also lands there, which is why the instructions above point you at that screen to retrieve it.
Attach the report to a new issue using the Bug: Playback template, and fill in the media details it asks for. The log tells us what the app did, and the media details tell us what it was trying to play. Both together are what makes a playback bug actionable.