davinci-resolve-mcp 4.8.8 → 4.8.10
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 +150 -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,156 @@
|
|
|
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.10 — the offline suite no longer asks GitHub for the latest release
|
|
6
|
+
|
|
7
|
+
No tool, action or runtime behaviour changed. This release changes the test
|
|
8
|
+
harness only.
|
|
9
|
+
|
|
10
|
+
### Fixed
|
|
11
|
+
|
|
12
|
+
- **Every full offline run sent a live request to GitHub.** `install.py` checks
|
|
13
|
+
`https://api.github.com/repos/samuelgursky/davinci-resolve-mcp/releases/latest`
|
|
14
|
+
for a newer version, and `tests/test_scripting_lib_discovery.py` runs its
|
|
15
|
+
`main()` in-process (`install.py --clients manual --dry-run`) through
|
|
16
|
+
`_run_main`. So `python -m unittest discover -s tests -t .` made that request
|
|
17
|
+
on every run. The run's outcome depended on the machine being online, and the
|
|
18
|
+
release notes that came back were written into `logs/update-check.json`.
|
|
19
|
+
Redirecting that file moves the answer, not the request. Measured on a full
|
|
20
|
+
v4.8.4 run with a tripwire wrapped around `urllib.request.urlopen`: exactly one
|
|
21
|
+
outbound request, this one, from
|
|
22
|
+
`test_only_the_designated_live_test_touches_a_real_resolve` →
|
|
23
|
+
`test_a_failed_verification_exits_non_zero` → `_run_main` →
|
|
24
|
+
`update_check.check_for_updates` → `_fetch_latest_release`. The same run of
|
|
25
|
+
this release makes none.
|
|
26
|
+
- `tests/offline_guard.py` now also wraps `urllib.request.urlopen`. Loopback
|
|
27
|
+
URLs (`127.0.0.0/8`, `::1`, `localhost`) and `file:`/`data:` URLs pass
|
|
28
|
+
through, so the control-panel tests still serve and probe a real panel.
|
|
29
|
+
Anything else raises `NetworkRefused` before a socket is opened. That is a
|
|
30
|
+
`URLError`, so callers take their no-network path. Each refusal is recorded
|
|
31
|
+
in `NETWORK_ATTEMPTS` with the calling line and the test, and pytest lists
|
|
32
|
+
them in its summary. The wrapper is installed before `src.server` is imported
|
|
33
|
+
and does not need it, so a checkout without the runtime stack is guarded too.
|
|
34
|
+
Installing twice is a no-op, and `uninstall()` puts the original back.
|
|
35
|
+
- `_run_main` sets `DAVINCI_RESOLVE_MCP_UPDATE_CHECK=0`, so the installer tests
|
|
36
|
+
do not ask at all and a clean run records no attempt.
|
|
37
|
+
|
|
38
|
+
### Validation
|
|
39
|
+
|
|
40
|
+
- New `tests/test_offline_network_isolation.py` is the tripwire. It fails if
|
|
41
|
+
`urlopen` is not the guard, if a remote URL (as a string or a `Request`) gets
|
|
42
|
+
through or a loopback one (`127.0.0.1`, `localhost`, `[::1]`) is stopped, if
|
|
43
|
+
`check_for_updates` with its own defaults stops going through the guard, if the
|
|
44
|
+
refusal stops naming `update_check.py … _fetch_latest_release`, or if
|
|
45
|
+
`_run_main` reaches for the network again. The refusal tests put a spy
|
|
46
|
+
downstream of the guard, so a wrong verdict fails the test instead of sending a
|
|
47
|
+
request. With the `_run_main` switch removed, the installer test fails and
|
|
48
|
+
names the URL, the caller and the test. With the guard disabled, all eight tests
|
|
49
|
+
fail in `setUp` before opening any URL. `tests/test_offline_guard.py` now also
|
|
50
|
+
checks that the network guard installs without `src`.
|
|
51
|
+
- Full suite, `python -m unittest discover -s tests -t .`, run behind a
|
|
52
|
+
`sitecustomize` tripwire that records and refuses off-machine `urlopen`,
|
|
53
|
+
DNS lookups and socket connects: 3,747 tests. Off-machine requests went from 1
|
|
54
|
+
on v4.8.4 to 0. The 14 errors are the same tests as on v4.8.4, all
|
|
55
|
+
environmental: six need `numpy` or `requests`, which the venv lacks, and five
|
|
56
|
+
in `test_offline_fallback` need `jszip`, because `node_modules` is not
|
|
57
|
+
installed. The last three are refusals by the tripwire itself: two
|
|
58
|
+
`test_doctor_paths` probe children, and the granular `get_resolve()` →
|
|
59
|
+
`open DaVinci Resolve.app` in `test_granular_destructive_op`, which v4.8.5
|
|
60
|
+
removes. pytest was not run locally.
|
|
61
|
+
- No Resolve behaviour changed, so a live run is not required.
|
|
62
|
+
|
|
63
|
+
## What's New in v4.8.9 — the offline suite's child processes no longer reach Resolve
|
|
64
|
+
|
|
65
|
+
Test-only. No tool, action or runtime code changed.
|
|
66
|
+
|
|
67
|
+
### Fixed
|
|
68
|
+
|
|
69
|
+
- **The control panels the suite starts connected to the open Resolve.** The
|
|
70
|
+
offline guard swaps the servers' entry points and installs its stand-in finder
|
|
71
|
+
inside the test process. None of it reaches a child process.
|
|
72
|
+
`server._open_control_panel` starts the real `src/analysis_dashboard.py` with
|
|
73
|
+
`subprocess.Popen`. That child imported Blackmagic's module and called
|
|
74
|
+
`scriptapp("Resolve")` through `_connect_resolve_read_only`: at startup, in the
|
|
75
|
+
inventory warm-up, and for `/api/boot`. Measured on v4.8.4 with a tripwire
|
|
76
|
+
standing in for the library, a full `python -m unittest discover -s tests -t .`
|
|
77
|
+
run made 6 calls from 3 panel children. Two children came from
|
|
78
|
+
`test_control_panel_ipv6_loopback`, whose docstring says "No Resolve". The third
|
|
79
|
+
came from `test_tool_argument_validation`, which calls every action with no
|
|
80
|
+
arguments, `open_control_panel` included. v4.8.5 attributed that third child to
|
|
81
|
+
`test_open_control_panel`, but every test there stubs the port probe and none of
|
|
82
|
+
them starts a panel.
|
|
83
|
+
- The guard now puts `tests/offline_child_site` first on PYTHONPATH, so every
|
|
84
|
+
Python child that inherits the environment runs its `sitecustomize.py` at
|
|
85
|
+
startup. That file answers `DaVinciResolveScript` and `fusionscript` with an
|
|
86
|
+
empty stand-in from a `sys.meta_path` finder, as the test process does. The
|
|
87
|
+
stand-in has no `scriptapp`, and its error names the guard. A panel started by
|
|
88
|
+
a test now reports `Resolve connection failed: DaVinciResolveScript is the
|
|
89
|
+
offline test guard's stand-in …` from `/api/boot`.
|
|
90
|
+
- It also refuses to launch the application through `subprocess` in a child.
|
|
91
|
+
A child that imports `src.server` and calls a tool falls through
|
|
92
|
+
`get_resolve()` to `_launch_resolve()` whenever Resolve is closed, and the
|
|
93
|
+
in-process swap of that function does not exist in a child. The check matches
|
|
94
|
+
the commands `resolve_runtime.launch_command` builds on each platform, any
|
|
95
|
+
other program inside an installation such as `fuscript`, and `open` or
|
|
96
|
+
`osascript` naming the app. Only the program is checked, so a Python child that
|
|
97
|
+
merely mentions the bundle path still runs.
|
|
98
|
+
- It runs the `sitecustomize` it shadows first, because Python loads only one.
|
|
99
|
+
Homebrew's Python ships one that rewrites `sys.prefix` and `sys.path`. A
|
|
100
|
+
developer's tripwire is often one too, and it typically chains to "the next
|
|
101
|
+
sitecustomize that is not me", which is now the guard. Before the guard
|
|
102
|
+
tracked what had already run, the two files chained into each other until
|
|
103
|
+
`RecursionError`. The tripwire then ended up answering the import, and the
|
|
104
|
+
guard was never installed. The chain now continues past the guard to the file
|
|
105
|
+
the tripwire would have reached, and the guard's stand-in goes in front last.
|
|
106
|
+
- The bridge redirect from v4.8.5 reaches children through the environment.
|
|
107
|
+
That covers the doctor probe as well. It replaces PYTHONPATH and so never runs
|
|
108
|
+
the new file, and it calls `connect_resolve(None)`, which is the bridge's route.
|
|
109
|
+
|
|
110
|
+
### Validation
|
|
111
|
+
|
|
112
|
+
- New `tests/test_offline_guard_child_process.py`, 14 tests. The main one starts the
|
|
113
|
+
real panel the way the suite does. Fakes shaped like Blackmagic's pair sit on
|
|
114
|
+
PYTHONPATH behind the guard: a `DaVinciResolveScript.py` loader that hands over
|
|
115
|
+
`fusionscript`, and a `scriptapp` that records every call to a file. The test
|
|
116
|
+
asserts that `/api/boot` names the guard's stand-in and that neither fake was
|
|
117
|
+
loaded. A control child without the guard does reach the fake `scriptapp`. The
|
|
118
|
+
other tests cover the stand-in answering both names again after a
|
|
119
|
+
`sys.modules` pop, a shadowed `sitecustomize` still running, and a chaining one
|
|
120
|
+
reaching the file after the guard. They also cover a second checkout's copy not
|
|
121
|
+
chaining in, the launch check against `launch_command` for three platforms and
|
|
122
|
+
both modes, other launch forms, ordinary children still running, a guarded child
|
|
123
|
+
refusing a bundle-shaped program that does not exist, and the PYTHONPATH
|
|
124
|
+
install and restore.
|
|
125
|
+
- With the PYTHONPATH export removed from `install()`, the panel test fails
|
|
126
|
+
("DaVinci Resolve is not connected"), and the tripwire records 4 `scriptapp`
|
|
127
|
+
calls from the panel child. With the chain tracking removed, both chaining
|
|
128
|
+
tests fail.
|
|
129
|
+
- Full suite, `python -m unittest discover -s tests -t .`: 3,770 tests. The 11
|
|
130
|
+
errors are the same as on v4.8.8 in this environment (no `numpy` or `requests`
|
|
131
|
+
in the venv, plus `test_offline_fallback` and `test_lut_file_controls`).
|
|
132
|
+
`python -m unittest discover -s tests` gives the same result. Both runs used a
|
|
133
|
+
scratch `sitecustomize` tripwire on PYTHONPATH, which chains to Homebrew's. It
|
|
134
|
+
answered the scripting modules with a recording module, refused native loads of
|
|
135
|
+
`fusionscript` and launches of the application, and redirected the bridge
|
|
136
|
+
config. It recorded no `scriptapp` call, native load or launch in the test
|
|
137
|
+
process or in any child it could see, and that includes 4 panel children per
|
|
138
|
+
run. The same tripwire on v4.8.4 recorded 6 panel-child calls.
|
|
139
|
+
- The tripwire could not see every child, and one of the children it missed
|
|
140
|
+
reached Resolve. `install.verify_resolve_connection` replaces PYTHONPATH with the
|
|
141
|
+
Blackmagic Modules directory, so its child loads neither the tripwire nor this
|
|
142
|
+
guard. `test_scripting_lib_discovery.test_the_live_probe_agrees_with_the_summary`
|
|
143
|
+
runs that probe for real whenever Resolve is installed. With Resolve open, each
|
|
144
|
+
of the four full runs behind this release most likely made one read-only
|
|
145
|
+
connection through it (`scriptapp`, `GetProductName`, `GetVersionString`). This
|
|
146
|
+
release does not close that path.
|
|
147
|
+
- Not covered: a child started with its own PYTHONPATH, as that probe and the
|
|
148
|
+
doctor probe are, with `-E` or `-I`, or with an environment built from scratch
|
|
149
|
+
does not run the file. Launches outside `subprocess` (`os.system`, `os.exec*`)
|
|
150
|
+
are not intercepted.
|
|
151
|
+
- pytest is not installed here, so the pytest path was not run locally. CI runs
|
|
152
|
+
`python -m pytest tests -q`.
|
|
153
|
+
- No Resolve behavior changed, so no live Resolve run is required. None was made.
|
|
154
|
+
|
|
5
155
|
## What's New in v4.8.8 — a test that reaches a Resolve launcher fails
|
|
6
156
|
|
|
7
157
|
Test-only. No tool, action or runtime code changed.
|
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.10 版 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.10"
|
|
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.10"
|
|
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()}")
|