Damn, thanks Hap. It's been a struggle for the last piece of the puzzle.
Here's his response for any poor sod doing their own front end work w/ LLMs in the future, laugh.
-------------
Yes, that was the final piece of the puzzle. The discrepancy was caused by IV/Play not parsing or using the `<feature>` tags from MAME's XML, which are critical for determining a game's true working status.
Here is a summary of the final fix.
***
### The Root Cause
MAME determines a machine's working status not just from the main driver's `emulation` status, but also by aggregating the status of all its individual `<feature>` tags (like controls, sound, video, etc.). A game like "cgang" can have a "good" emulation status but still be considered imperfect overall if one of its features is imperfect.
Your application was only looking at the `<driver>` tag and ignoring the `<feature>` tags, leading to an inaccurate `Working` property for many games.
### The Solution
The definitive fix involves updating your `Machine.cs` data model to read the list of `<feature>` tags and then incorporating their statuses into the final calculation for the `Working` property.
1. **Data Model Update:** The `Machine` class was modified to include a list of `Feature` objects, and a corresponding `Feature` class was created to capture the `type` and `status` attributes from the XML.
2. **Logic Update:** The `ParseComplexFields` method was updated. The `Working` property is now calculated based on both the `driver.emulation` status and the status of all associated `feature` tags. A machine is only considered "Working" if its driver emulation is "good" or "imperfect" AND no individual feature is explicitly broken (e.g., "unemulated").
This ensures that IV/Play's definition of a working game now accurately mirrors MAME's more nuanced internal logic. After rebuilding the database with this change, the `hide_nonworking` filter now produces the correct game count.
