Forum Discussion
Storyline Media Organization
There's no official documentation of the internal XML and as far as I know there never has been. I've been mapping it while building some free tools, so here's what I can confirm from pulling apart real project files.
Your search and replace approach is sound. The reason editing both files works is that the media list in theme.xml is a byte-for-byte duplicate of the one in story.xml, so they have to be kept in step or the two lists disagree.
The useful bit you may not have found yet: every <media> element carries an md5Checksum, and its <stream> value is the MD5 of the file as packaged under story/media. The packaged filenames (the generated R5XcGWXUIVZV.jpg style names) appear nowhere else in the XML, so that checksum is the only reliable join between the metadata holding your source paths and the actual bytes. I tested this across a batch of my own projects and every checksum matched. For your Python scripts, hash the packaged files and join on that.
Usage is not recorded in the slide XML at all. It lives in the OPC relationship files: story/slides/_rels/slideN.xml.rels, with the same pattern for slideLayouts and slideMasters. Look for Relationship Type="media"; the Targets are absolute paths like /story/media/xxx.jpg.
A few smaller findings. Slide display names are the name attribute on the <sld> root element of each slide part. Scene names sit in story.xml under sceneLst, and the <sldId> values inside a scene are relationship ids you resolve through story/_rels/story.xml.rels. And if a file contains question banks, those are <scene> elements under quizMgr > bankLst rather than sceneLst.
On your point 2, honestly, I don't think that one is fixable from outside. The refusal to re-import binary-identical files is SL's own import logic. What you might be able to fix is the false 'newer' flags client side maybe...
Your point 3 is the one I built a tool for, originally for my own use. It's a browser tool, drop several .story files in and it hashes everything under story/media, joins the checksums back to the recorded source paths, and walks the rels for slide, layout and master usage. It reports which files are shared across modules, which are stored twice inside one module under different generated names, which have the same source filename but different contents (the nasty one for a team sharing source media), and which are referenced by nothing. On four of my own recent projects it found 63 media files collapsing to 56 unique assets, 14 of them referenced by nothing at all! Runs entirely client side in the browser tab. There's a CSV export. It's 100% free to use...