Intro/Credits Backup & Restore (New Plugin)

[guilty57 9]

Intro/Credits Backup & Restore - open-source replacement for the intro/credits backup plugin

Hi all,

The "Intros Backup/Restore" plugin that many of us have relied on to back up and restore intro/credits chapter markers hasn't seen an update in a while, and I know several people here have been running into issues or just waiting on fixes that haven't come.

I ended up writing an independent, open-source replacement from scratch, built purely against Emby's public plugin SDK - no code from the original plugin, just the same general idea (export markers to JSON per episode, restore them back later).

What it does:

• Backs up every TV episode's intro/credits chapter markers to one JSON file per episode
• Restores markers from those JSON backups, matching episodes by TVDB ID + season + episode number
• Before each backup run, zips up whatever was already in the backup folder into a timestamped archive first, so nothing gets silently overwritten
• Optional companion .nfo output alongside the JSON
• Both backup and restore run as normal Emby scheduled tasks - no custom in-app dialogs, just Dashboard > Scheduled Tasks like anything else

Scope: TV episodes only for now - movie intro/credits markers aren't handled.

 

Settings:

Scheduled Task:

Requirements: Built and tested against Emby Server 4.10.0.18. You'll need the .NET 8 SDK (or Docker) to build it, and you'll need to copy three DLLs from your own Emby install to build against (not redistributed in the repo for licensing reasons - the README walks through exactly where to find them on Synology/Docker/Windows/Linux installs).

It's MIT licensed, so do whatever you want with it. Source, build instructions, and a v1.0.0 release are all here:

https://github.com/guilty57/credits-intros-backup-restore

Happy to hear feedback, and PRs are welcome if anyone wants to extend it (movie support would be the obvious next step).

[crusher11 1236]

Is there a reason this isn't just being offered as a .dll I can drop into my plugins folder, as with all other Emby plugins? I don't know my way around building things or whatever.

I had the old backups plugin, so I have a section like this in the NFO file for each episode:

  <markers>
    <introstart>771144278</introstart>
    <introend>875621889</introend>
    <creditstart>0</creditstart>
  </markers>

Will this work to restore them?

[guilty57 9]

Check the repo. I’ve uploaded the .dll. But read the information about the server version.

[guilty57 9]

On restoring from your old NFO files: Honestly, no — not as-is. A few things to know:

• This plugin's restore task only reads from JSON backup files in a folder you configure (IntroBackupPath), not from NFO files sitting next to your media
• The optional NFO output this plugin writes is also a different, simpler schema (<intros><introstart>...), and it writes them into that same backup folder, not into your media folders
• There's currently no code path that reads the old plugin's per-episode <markers> NFO block from your media library at all

So your existing NFO files with <introstart>/<introend>/<creditstart> won't be picked up by either the backup or restore task right now.


Here is a simple tool for a quick migration.

 

python3 migrate_nfo_to_json.py \
  --source /path/to/old/nfo/folder \
  --output /path/to/new/json/folder \
  --map introstart=introstart,introend=introend,creditstart=creditstart \
  --emby-url http://SERVER_IP:PORT \
  --api-key YOUR_API_KEY

 

migrate_nfo_to_json.py

Edited July 14 by guilty57

[crusher11 1236]

Storing the data centrally rather than with the media doesn't seem like the best choice to me.

[guilty57 9]

v1.1.0 is out - a few improvements based on feedback here, thanks all.

What's new:

• Media-folder storage option: JSON/NFO backups can now be saved next to each episode's own video file instead of (or alongside) a centralized folder - if you'd rather the marker data travel with your media, this is for you
• Removed the redundant "Also write a companion .nfo file" checkbox - NFO output is now driven purely by whether a destination (path or media-folder option) is actually configured
• Per-episode backup writes are now resilient to permission errors - one folder's issue no longer aborts the whole run; it's logged and that episode is skipped, with a summary count at the end
• Added a README "Permissions" section covering common Linux chown/chmod fixes and Synology's ACL-override behavior (synoacltool), since that's the most common thing that trips people up
• Custom icon instead of the default folder icon
• Clearer task descriptions and a distinct scheduled-task category label so it doesn't get lost next to the commercial plugin's similarly-named tasks

Release (with a prebuilt DLL, tested against Emby Server 4.10.0.18) and full changelog here:

https://github.com/guilty57/credits-intros-backup-restore/releases/tag/v1.1.0

Repo: https://github.com/guilty57/credits-intros-backup-restore

Still open to feedback - the storage-alongside-media suggestion in this thread was exactly what prompted this release, so keep it coming.

[crusher11 1236]

Is it still writing its own NFO, or does it now write to the media's existing NFO?

What's the best way for me to go about handling my existing backups and intros? I have some intros that aren't backed up, because they were marked after Cheese's plugin stopped working, and I don't want to lose those, but I also want to restore the intros I did have backed up with Cheese's plugin and have since lost.

I'm still on .17 for now, so I can't install this until I have time to do a full server update.

[guilty57 9]

 

NFO behavior: It writes its own, separate NFO file - not the media's existing/scraper NFO. Two things worth being precise about:

• Schema is different from Cheese's plugin - mine is <intros><introstart>...</introstart><introend>...</introend><creditsstart>...</creditsstart></intros>, whereas his used <markers><introstart>....
• Filename is also different from the video's own basename - it's {SeriesName} ({TvdbId}) S{SS}E{EE} - {EpisodeTitle}.nfo, even in "save next to media" mode. So it sits alongside the video as an extra file, it doesn't touch/overwrite whatever NFO your metadata scraper (NfoMetadata plugin etc.) already writes for that episode.

Migrating your situation - this is exactly the scenario I built a separate migration script for. Here's the order I'd do it in, since it matters:

• Back up what's currently live first. Run the "Backup Intro/Credits Markers" task now, pointed at a fresh folder. This captures the intros you set after Cheese's plugin died (the ones with no backup anywhere yet) before anything else touches them.

• Convert Cheese's old NFO backups separately. There's a standalone script for this (not part of the plugin, one-time tool): migrate_nfo_to_json.py (I'll attach it to the repo's Discussions/Issues if it's not obvious where to find it - let me know). Point --output at a different folder than step 1's, not the same one.

• Merge carefully, don't just dump both folders together. For any episode where step 1 already produced a JSON (meaning it currently has live markers), skip step 2's file for that same episode - you don't want an old Cheese backup silently overwriting a marker you set more recently. Only bring over step 2's files for episodes that have no file from step 1 (i.e. markers you'd lost entirely).

• Then run Restore once against the merged folder.

The reason for the ordering: Restore replaces whatever intro/credit markers currently exist for an episode with whatever's in the backup file - so if you restore an old file for an episode that already has newer markers set, you'd lose the newer ones.

On the version question: the prebuilt DLL in the release is only built/tested against 4.10.0.18 - I haven't verified compatibility with .17 or earlier. Building from source against your own server's SDK DLLs (steps are in the README) would be the safer bet if you don't want to wait for the full update, since it compiles against whatever version you're actually running.

Happy to help further if the merge step above needs more detail once you're looking at your actual folder contents.