Collecting Logs

Collecting Logs

A log is usually the difference between a bug being fixed and being closed unsolved. This page shows how to capture one and attach it to a bug report.

The short version

1. Go to Settings > About > Diagnostics & Logging (or type logs into the settings search).
2. Turn on Enable diagnostic logging.
3. Make the problem happen again.
4. Don't restart the app. Go straight back to Settings > About > Diagnostics & Logging.
5. Press Copy all logs and paste the report into your GitHub issue, inside a code block:

```
paste the report here
```

That's the whole procedure. The rest of this page explains why it works this way and what else the screen can do.

Why you have to reproduce the problem

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 disk, and closing or restarting the app throws the buffer away.

So you can't collect a log for something that already happened. Turn logging on first, then make the problem happen again.

The buffer holds the most recent 2000 entries. If you keep using the app after reproducing the problem, the interesting part can get pushed out, so send the report soon after. The Reports heading shows how many entries were captured. If it says zero, logging was not on while you reproduced the problem, so start again.

Sending the report

The report has to end up on the GitHub issue itself. Nothing in the app sends it to the developers.

Copy all logs is the route to use. It works on every platform and every server type, and it works even when you aren't signed in to a server, 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.

Advanced: the "Send report to server" button

This button uploads the report to your own server, the one you're signed in to. It sends nothing to the Moonfin developers. The filename it shows afterwards, something like upload_Moonfin_1.0.0_20260802.log, is meaningless to anyone who can't read that server, so 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. 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), when logging is off, or when no entries have been captured yet. The button's subtitle tells you which.

Advanced: filtering and clearing

• Under Recent logs, the Filter control limits the list to one category: General, Media, Seerr login, Network, Authentication, Playback, or Sync. The filter only changes what you see on screen. Copy all logs and Send report to server always send the complete report, which is what we want, so please don't trim it by hand.
• Clear captured logs discards everything currently held. Useful for a clean report containing only one reproduction: clear, reproduce, send.
• It's fine to leave logging on while chasing an intermittent problem, though the buffer still doesn't survive a restart.

What a report contains

Every report starts with a short header (app version, device, platform, entry count), then one line per entry in the form <timestamp> <level> [<category>] <message>.

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 is sensitive, replace it with REDACTED rather than deleting the line, so the surrounding timing still makes sense.

Advanced: what the playback entries record

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: whether it direct played, direct streamed, or transcoded, and the server's reasons
• The audio path: 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

Advanced: server logs are a different thing

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.

Things that look like Moonfin bugs but aren't

Some of what Moonfin shows is passed straight through from another service, so a wrong-looking badge can mean that service is reporting something wrong. Worth ruling these out before capturing a log.

"4K - Deleted" on something you can actually play

If a title carries a 4K - Deleted badge but the 4K file is in your library and plays fine, check Seerr before anything else. Moonfin renders the availability Seerr reports, and Seerr tracks HD and 4K as two separate states. A title reported as available in HD and deleted in 4K renders exactly as that badge.

The usual cause is one physical Radarr added to Seerr twice, once as the normal server and once as the 4K server with a different quality profile. If the 4K entry loses its is4k: true flag, Seerr's scan can't tie the old 4K records back to it, so it returns available for HD and deleted for 4K even though the file is a real 3840 pixel wide copy that plays normally.

To check and fix it:

1. Open Seerr's Radarr and Sonarr settings and confirm the entry you use for 4K is still flagged as a 4K server. The API response for that service should carry is4k: true.
2. If it isn't, set it back and rescan. The title flips to available in HD and unknown in 4K, and the badge disappears.
3. Seerr recommends against adding the same physical Radarr twice as separate normal and 4K servers. Use two separate Radarr instances if you manage HD and 4K together.

Tracked upstream as seerr#2953, with a fix in seerr#2227.

Filing the issue

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.