|
2 | 2 |
|
3 | 3 | Release history for the DaVinci Resolve MCP Server. The latest release is summarized in the root README; older entries live here to keep the README focused. |
4 | 4 |
|
| 5 | +## What's New in v2.71.1 |
| 6 | + |
| 7 | +`Timeline.DeleteClips` can lie about whether it worked. #111 recorded four |
| 8 | +behaviours from a live edit session; #114 mitigates the first of them. Both by |
| 9 | +@billcarroll. |
| 10 | + |
| 11 | +### DeleteClips readback-and-retry |
| 12 | + |
| 13 | +`Timeline.DeleteClips` can return `False` on a first call even when every item |
| 14 | +passed is a valid, present `TimelineItem`, with an identical retry succeeding. |
| 15 | +`_timeline_delete_clips_verified` reads the tracks back on a `False` and retries |
| 16 | +once if the items are still there. All four timeline call sites route through |
| 17 | +it: the `delete_clips` action, `lift_range`, `duplicate_clips` and `copy_range`. |
| 18 | + |
| 19 | +The readback is deliberately **tri-state**. A walk that raised, enumerated no |
| 20 | +track at all, or covered items whose unique ID cannot be read is `unknown`, not |
| 21 | +`absent` — so an unverifiable delete is never reported as success, and never |
| 22 | +spends a second destructive call buying information it cannot read. An earlier |
| 23 | +draft collapsed unknown into absent, which turned a failed delete into a |
| 24 | +reported success; that is the exact silent-lie class this series exists to |
| 25 | +remove, so it is worth naming. |
| 26 | + |
| 27 | +The `ripple=True` non-idempotence of a retry is recorded in the docstring rather |
| 28 | +than claimed to be solved: if the first call deleted some items and left others, |
| 29 | +the retry passes the original list back in, stale handles included. It could not |
| 30 | +be made to misbehave against a fake. |
| 31 | + |
| 32 | +### Four edit-session behaviours recorded |
| 33 | + |
| 34 | +- **`DeleteClips` flaky first attempt.** The entry states plainly that the cause |
| 35 | + is **unknown**, and specifically that this is *not* the |
| 36 | + `ProjectManager.DeleteProject` shape — that one has an identified mechanism |
| 37 | + which retrying does not clear, whereas a single retry cleared this in the one |
| 38 | + instance seen. One observation is not a mechanism. |
| 39 | +- **`DeleteClips` leaves linked audio.** The API deletes exactly the items |
| 40 | + passed; the UI's linked-selection behaviour does not apply, so orphaned audio |
| 41 | + collides with later appends. |
| 42 | +- **`AppendToTimeline` mixed-fps duration floor.** Source-to-timeline frame |
| 43 | + conversion rounds down, landing a planned range one frame short. |
| 44 | +- **`ImportMedia` current-folder only.** No destination parameter; imports land |
| 45 | + in the current bin. |
| 46 | + |
5 | 47 | ## What's New in v2.71.0 |
6 | 48 |
|
7 | 49 | Keyed metadata getters honor a list of keys, and `delete_timelines` names the |
|
0 commit comments