davinci-resolve-mcp 4.8.7 → 4.8.9
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +159 -0
- package/README.md +1 -1
- package/README.zh-CN.md +2 -2
- package/install.py +1 -1
- package/package.json +1 -1
- package/src/granular/common.py +1 -1
- package/src/server.py +1 -1
package/CHANGELOG.md
CHANGED
|
@@ -2,6 +2,165 @@
|
|
|
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 v4.8.9 — the offline suite's child processes no longer reach Resolve
|
|
6
|
+
|
|
7
|
+
Test-only. No tool, action or runtime code changed.
|
|
8
|
+
|
|
9
|
+
### Fixed
|
|
10
|
+
|
|
11
|
+
- **The control panels the suite starts connected to the open Resolve.** The
|
|
12
|
+
offline guard swaps the servers' entry points and installs its stand-in finder
|
|
13
|
+
inside the test process. None of it reaches a child process.
|
|
14
|
+
`server._open_control_panel` starts the real `src/analysis_dashboard.py` with
|
|
15
|
+
`subprocess.Popen`. That child imported Blackmagic's module and called
|
|
16
|
+
`scriptapp("Resolve")` through `_connect_resolve_read_only`: at startup, in the
|
|
17
|
+
inventory warm-up, and for `/api/boot`. Measured on v4.8.4 with a tripwire
|
|
18
|
+
standing in for the library, a full `python -m unittest discover -s tests -t .`
|
|
19
|
+
run made 6 calls from 3 panel children. Two children came from
|
|
20
|
+
`test_control_panel_ipv6_loopback`, whose docstring says "No Resolve". The third
|
|
21
|
+
came from `test_tool_argument_validation`, which calls every action with no
|
|
22
|
+
arguments, `open_control_panel` included. v4.8.5 attributed that third child to
|
|
23
|
+
`test_open_control_panel`, but every test there stubs the port probe and none of
|
|
24
|
+
them starts a panel.
|
|
25
|
+
- The guard now puts `tests/offline_child_site` first on PYTHONPATH, so every
|
|
26
|
+
Python child that inherits the environment runs its `sitecustomize.py` at
|
|
27
|
+
startup. That file answers `DaVinciResolveScript` and `fusionscript` with an
|
|
28
|
+
empty stand-in from a `sys.meta_path` finder, as the test process does. The
|
|
29
|
+
stand-in has no `scriptapp`, and its error names the guard. A panel started by
|
|
30
|
+
a test now reports `Resolve connection failed: DaVinciResolveScript is the
|
|
31
|
+
offline test guard's stand-in …` from `/api/boot`.
|
|
32
|
+
- It also refuses to launch the application through `subprocess` in a child.
|
|
33
|
+
A child that imports `src.server` and calls a tool falls through
|
|
34
|
+
`get_resolve()` to `_launch_resolve()` whenever Resolve is closed, and the
|
|
35
|
+
in-process swap of that function does not exist in a child. The check matches
|
|
36
|
+
the commands `resolve_runtime.launch_command` builds on each platform, any
|
|
37
|
+
other program inside an installation such as `fuscript`, and `open` or
|
|
38
|
+
`osascript` naming the app. Only the program is checked, so a Python child that
|
|
39
|
+
merely mentions the bundle path still runs.
|
|
40
|
+
- It runs the `sitecustomize` it shadows first, because Python loads only one.
|
|
41
|
+
Homebrew's Python ships one that rewrites `sys.prefix` and `sys.path`. A
|
|
42
|
+
developer's tripwire is often one too, and it typically chains to "the next
|
|
43
|
+
sitecustomize that is not me", which is now the guard. Before the guard
|
|
44
|
+
tracked what had already run, the two files chained into each other until
|
|
45
|
+
`RecursionError`. The tripwire then ended up answering the import, and the
|
|
46
|
+
guard was never installed. The chain now continues past the guard to the file
|
|
47
|
+
the tripwire would have reached, and the guard's stand-in goes in front last.
|
|
48
|
+
- The bridge redirect from v4.8.5 reaches children through the environment.
|
|
49
|
+
That covers the doctor probe as well. It replaces PYTHONPATH and so never runs
|
|
50
|
+
the new file, and it calls `connect_resolve(None)`, which is the bridge's route.
|
|
51
|
+
|
|
52
|
+
### Validation
|
|
53
|
+
|
|
54
|
+
- New `tests/test_offline_guard_child_process.py`, 14 tests. The main one starts the
|
|
55
|
+
real panel the way the suite does. Fakes shaped like Blackmagic's pair sit on
|
|
56
|
+
PYTHONPATH behind the guard: a `DaVinciResolveScript.py` loader that hands over
|
|
57
|
+
`fusionscript`, and a `scriptapp` that records every call to a file. The test
|
|
58
|
+
asserts that `/api/boot` names the guard's stand-in and that neither fake was
|
|
59
|
+
loaded. A control child without the guard does reach the fake `scriptapp`. The
|
|
60
|
+
other tests cover the stand-in answering both names again after a
|
|
61
|
+
`sys.modules` pop, a shadowed `sitecustomize` still running, and a chaining one
|
|
62
|
+
reaching the file after the guard. They also cover a second checkout's copy not
|
|
63
|
+
chaining in, the launch check against `launch_command` for three platforms and
|
|
64
|
+
both modes, other launch forms, ordinary children still running, a guarded child
|
|
65
|
+
refusing a bundle-shaped program that does not exist, and the PYTHONPATH
|
|
66
|
+
install and restore.
|
|
67
|
+
- With the PYTHONPATH export removed from `install()`, the panel test fails
|
|
68
|
+
("DaVinci Resolve is not connected"), and the tripwire records 4 `scriptapp`
|
|
69
|
+
calls from the panel child. With the chain tracking removed, both chaining
|
|
70
|
+
tests fail.
|
|
71
|
+
- Full suite, `python -m unittest discover -s tests -t .`: 3,770 tests. The 11
|
|
72
|
+
errors are the same as on v4.8.8 in this environment (no `numpy` or `requests`
|
|
73
|
+
in the venv, plus `test_offline_fallback` and `test_lut_file_controls`).
|
|
74
|
+
`python -m unittest discover -s tests` gives the same result. Both runs used a
|
|
75
|
+
scratch `sitecustomize` tripwire on PYTHONPATH, which chains to Homebrew's. It
|
|
76
|
+
answered the scripting modules with a recording module, refused native loads of
|
|
77
|
+
`fusionscript` and launches of the application, and redirected the bridge
|
|
78
|
+
config. It recorded no `scriptapp` call, native load or launch in the test
|
|
79
|
+
process or in any child it could see, and that includes 4 panel children per
|
|
80
|
+
run. The same tripwire on v4.8.4 recorded 6 panel-child calls.
|
|
81
|
+
- The tripwire could not see every child, and one of the children it missed
|
|
82
|
+
reached Resolve. `install.verify_resolve_connection` replaces PYTHONPATH with the
|
|
83
|
+
Blackmagic Modules directory, so its child loads neither the tripwire nor this
|
|
84
|
+
guard. `test_scripting_lib_discovery.test_the_live_probe_agrees_with_the_summary`
|
|
85
|
+
runs that probe for real whenever Resolve is installed. With Resolve open, each
|
|
86
|
+
of the four full runs behind this release most likely made one read-only
|
|
87
|
+
connection through it (`scriptapp`, `GetProductName`, `GetVersionString`). This
|
|
88
|
+
release does not close that path.
|
|
89
|
+
- Not covered: a child started with its own PYTHONPATH, as that probe and the
|
|
90
|
+
doctor probe are, with `-E` or `-I`, or with an environment built from scratch
|
|
91
|
+
does not run the file. Launches outside `subprocess` (`os.system`, `os.exec*`)
|
|
92
|
+
are not intercepted.
|
|
93
|
+
- pytest is not installed here, so the pytest path was not run locally. CI runs
|
|
94
|
+
`python -m pytest tests -q`.
|
|
95
|
+
- No Resolve behavior changed, so no live Resolve run is required. None was made.
|
|
96
|
+
|
|
97
|
+
## What's New in v4.8.8 — a test that reaches a Resolve launcher fails
|
|
98
|
+
|
|
99
|
+
Test-only. No tool, action or runtime code changed.
|
|
100
|
+
|
|
101
|
+
### Fixed
|
|
102
|
+
|
|
103
|
+
- **`test_granular_destructive_op.McpSchema` asked for a Resolve connection ten
|
|
104
|
+
times per run.** `test_every_hooked_tool_advertises_the_override_and_nothing_else_new`
|
|
105
|
+
called `hasattr(value, "__granular_destructive__")` on every global of every
|
|
106
|
+
granular module. Ten of those modules hold `resolve = ResolveProxy()`, and the
|
|
107
|
+
proxy's `__getattr__` calls `get_resolve()`, which falls through to
|
|
108
|
+
`_launch_resolve()` when nothing answers. Measured on v4.8.4 with the granular
|
|
109
|
+
`_launch_resolve` replaced by a counting stub: a full
|
|
110
|
+
`python -m unittest discover -s tests -t .` run reached it 10 times, once per
|
|
111
|
+
module, all from this test and from no other. With Resolve closed, each reach
|
|
112
|
+
would have run `open` on the application. Since v4.8.5 the guard's `get_resolve`
|
|
113
|
+
answers `None` first, so the launcher is no longer reached, but the scan still
|
|
114
|
+
asked for a connection. It now reads the marker with `inspect.getattr_static`
|
|
115
|
+
and asks for nothing. The new `test_the_module_scan_asks_for_no_connection`
|
|
116
|
+
fails if it asks again.
|
|
117
|
+
|
|
118
|
+
### Changed
|
|
119
|
+
|
|
120
|
+
- **A test that reaches a launcher now fails.** Until now the guard's stand-in
|
|
121
|
+
recorded the attempt in `LAUNCH_ATTEMPTS` and the test passed. pytest printed
|
|
122
|
+
the list in its summary without failing the run, `unittest` never read it, and
|
|
123
|
+
every entry recorded under `unittest` read `<unknown test>`. Now every
|
|
124
|
+
`unittest.TestCase` runs under a cleanup that fails it when an attempt was
|
|
125
|
+
recorded during the test or since the previous test finished, which covers
|
|
126
|
+
imports and class fixtures. Plain pytest functions get the same check from an
|
|
127
|
+
autouse fixture in `tests/conftest.py`. Each attempt fails exactly one test.
|
|
128
|
+
Each entry names the test and the module that called the launcher, for example
|
|
129
|
+
`tests.test_x.Case.test_y (called from src.granular.common)`. A test that calls
|
|
130
|
+
the stand-in on purpose deletes its own entry, as `test_offline_guard_granular`
|
|
131
|
+
already does, and passes.
|
|
132
|
+
|
|
133
|
+
### Validation
|
|
134
|
+
|
|
135
|
+
- New `tests/test_offline_launch_check.py` runs small inner tests that reach the
|
|
136
|
+
granular launcher through a `ResolveProxy`, the compound launcher through the
|
|
137
|
+
real `get_resolve`, and a launcher from `setUpClass`. Each reach fails exactly
|
|
138
|
+
one inner test; the `setUpClass` reach fails the class's first test and not its
|
|
139
|
+
second. An inner test that deletes the entry for its deliberate call passes. With the `TestCase.run`
|
|
140
|
+
wrapper removed, 4 of its 6 tests fail.
|
|
141
|
+
- The v4.8.4 `McpSchema` test fails under the new check when the guard's
|
|
142
|
+
`get_resolve` is swapped back to the real one. It records 10 attempts, each
|
|
143
|
+
`…McpSchema.test_every_hooked_tool_advertises_the_override_and_nothing_else_new (called from src.granular.common)`.
|
|
144
|
+
With `hasattr` restored in the scan, the new pin test fails with
|
|
145
|
+
`asked for a connection`.
|
|
146
|
+
- Full suite, `python -m unittest discover -s tests -t .`: 3,756 tests. No test
|
|
147
|
+
failed the launch check, and `LAUNCH_ATTEMPTS` was empty at exit. The 11 errors
|
|
148
|
+
are the same as on v4.8.5 in this environment (no `numpy` or `requests` in the
|
|
149
|
+
venv, plus `test_offline_fallback` and `test_lut_file_controls`).
|
|
150
|
+
`python -m unittest discover -s tests`, the runner that skips `tests/__init__.py`,
|
|
151
|
+
gives the same result.
|
|
152
|
+
Both runs used a scratch `sitecustomize` tripwire, because Resolve was open on
|
|
153
|
+
the machine. It set `sys.modules["DaVinciResolveScript"] = None`, answered any
|
|
154
|
+
later import with a recording module, pointed `DAVINCI_RESOLVE_BRIDGE_CONFIG`
|
|
155
|
+
at a file that does not exist, and blocked `Popen` of the application. It
|
|
156
|
+
recorded no `scriptapp` call and no launch in the test process or in any of its
|
|
157
|
+
59 child processes. The children were kept away by the tripwire's `None`
|
|
158
|
+
entry, not by this change. The control-panel children noted under v4.8.5 are
|
|
159
|
+
still outside the in-process guard.
|
|
160
|
+
- pytest is not installed here, so the `conftest.py` fixture was not run locally.
|
|
161
|
+
CI runs `python -m pytest tests -q`.
|
|
162
|
+
- No Resolve behavior changed, so no live Resolve run is required. None was made.
|
|
163
|
+
|
|
5
164
|
## What's New in v4.8.7 — an append Resolve refuses is reported as a failure
|
|
6
165
|
|
|
7
166
|
### Fixed
|
package/README.md
CHANGED
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
|
|
3
3
|
English | [简体中文](README.zh-CN.md)
|
|
4
4
|
|
|
5
|
-
[](https://github.com/samuelgursky/davinci-resolve-mcp/releases)
|
|
6
6
|
[](https://www.npmjs.com/package/davinci-resolve-mcp)
|
|
7
7
|
[](docs/reference/api-coverage.md)
|
|
8
8
|
[-blue.svg)](#server-modes)
|
package/README.zh-CN.md
CHANGED
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
|
|
3
3
|
[English](README.md) | 简体中文
|
|
4
4
|
|
|
5
|
-
[](https://github.com/samuelgursky/davinci-resolve-mcp/releases)
|
|
6
6
|
[](https://www.npmjs.com/package/davinci-resolve-mcp)
|
|
7
7
|
[](docs/reference/api-coverage.md)
|
|
8
8
|
[-blue.svg)](#服务器模式)
|
|
@@ -12,7 +12,7 @@
|
|
|
12
12
|
[](https://www.python.org/downloads/)
|
|
13
13
|
[](https://opensource.org/licenses/MIT)
|
|
14
14
|
|
|
15
|
-
> 本翻译对应 v4.8.
|
|
15
|
+
> 本翻译对应 v4.8.9 版 README。如与英文原版有出入，以 [英文原版](README.md) 为准。
|
|
16
16
|
|
|
17
17
|
一个 Model Context Protocol (MCP) 服务器，让 AI 助手通过官方脚本 API 控制 DaVinci Resolve Studio（达芬奇）。它提供完整的 API 覆盖，外加带护栏的工作流助手，涵盖剪辑、媒体池整理、渲染设置、审阅标记、调色、Fusion、Fairlight、项目生命周期任务、扩展开发，以及不碰源媒体的媒体分析。
|
|
18
18
|
|
package/install.py
CHANGED
|
@@ -37,7 +37,7 @@ from src.utils.update_check import (
|
|
|
37
37
|
|
|
38
38
|
# ─── Version ──────────────────────────────────────────────────────────────────
|
|
39
39
|
|
|
40
|
-
VERSION = "4.8.
|
|
40
|
+
VERSION = "4.8.9"
|
|
41
41
|
# Only hard floor: mcp[cli] requires Python 3.10+. There is no upper bound —
|
|
42
42
|
# Resolve's scripting bridge loads into newer interpreters on recent builds
|
|
43
43
|
# (Python 3.14 verified against Resolve Studio 20.3.2). Older Resolve builds
|
package/package.json
CHANGED
package/src/granular/common.py
CHANGED
|
@@ -93,7 +93,7 @@ if not logging.getLogger().handlers:
|
|
|
93
93
|
handlers=[logging.StreamHandler()],
|
|
94
94
|
)
|
|
95
95
|
|
|
96
|
-
VERSION = "4.8.
|
|
96
|
+
VERSION = "4.8.9"
|
|
97
97
|
logger = logging.getLogger("davinci-resolve-mcp")
|
|
98
98
|
logger.info(f"Starting DaVinci Resolve MCP Server v{VERSION}")
|
|
99
99
|
logger.info(f"Detected platform: {get_platform()}")
|