Summary
vfo profiles is checking for /mkv_original and /mp4_original as absolute paths instead of joining them under the configured mezzanine root. This causes false missing-folder warnings even when the directories exist under the configured mezzanine location.
Current behavior
With a runtime config like:
MEZZANINE_LOCATION=/Volumes/Mitchum/vfo_practice/mezzanine
KEEP_SOURCE=false
and these folders present:
/Volumes/Mitchum/vfo_practice/mezzanine/mkv_original
/Volumes/Mitchum/vfo_practice/mezzanine/mp4_original
/Volumes/Mitchum/vfo_practice/mezzanine/unable_to_process
vfo profiles still prints warnings such as:
PROFILE ALERT: mezzanine /mkv_original does not exist, if KEEP_SOURCE=FALSE, no encoding will occur from mkv_original to this profile.
PROFILE ALERT: mezzanine /mp4_original does not exist, if KEEP_SOURCE=FALSE, no encoding will occur from mp4_original to this profile.
The command then continues into profile execution and eventually hits:
DEV NOTE: MAJOR ERROR, ca_get_a_node_from_profile_name has failed
Expected behavior
vfo profiles should resolve those lane paths relative to the mezzanine root and detect the existing folders correctly:
/Volumes/Mitchum/vfo_practice/mezzanine/mkv_original
/Volumes/Mitchum/vfo_practice/mezzanine/mp4_original
Likely cause
In services/vfo/src/Profile/Data_Structures/p_profiles_struct.c, the path construction appears to overwrite the joined root path with the subfolder name instead of appending it. The same pattern also appears to affect the mp4_original helper.
Impact
- false warnings during
vfo profiles
- confusing CLI output for users running
KEEP_SOURCE=false
- potential downstream profile selection failures in the same flow
Repro
- Configure VFO with a valid mezzanine root, e.g.
/Volumes/Mitchum/vfo_practice/mezzanine
- Create:
mkv_original
mp4_original
unable_to_process
under that mezzanine root
- Run
vfo doctor successfully
- Run
vfo profiles
- Observe the false missing-folder warnings for
/mkv_original and /mp4_original
Notes
I observed this while setting up a lean Craigstreamy aggressive-VMAF pack on a local volume. The config itself validated cleanly in vfo doctor, so this looks like a runtime path-join bug rather than a config issue.
Summary
vfo profilesis checking for/mkv_originaland/mp4_originalas absolute paths instead of joining them under the configured mezzanine root. This causes false missing-folder warnings even when the directories exist under the configured mezzanine location.Current behavior
With a runtime config like:
MEZZANINE_LOCATION=/Volumes/Mitchum/vfo_practice/mezzanineKEEP_SOURCE=falseand these folders present:
/Volumes/Mitchum/vfo_practice/mezzanine/mkv_original/Volumes/Mitchum/vfo_practice/mezzanine/mp4_original/Volumes/Mitchum/vfo_practice/mezzanine/unable_to_processvfo profilesstill prints warnings such as:PROFILE ALERT: mezzanine /mkv_original does not exist, if KEEP_SOURCE=FALSE, no encoding will occur from mkv_original to this profile.PROFILE ALERT: mezzanine /mp4_original does not exist, if KEEP_SOURCE=FALSE, no encoding will occur from mp4_original to this profile.The command then continues into profile execution and eventually hits:
DEV NOTE: MAJOR ERROR, ca_get_a_node_from_profile_name has failedExpected behavior
vfo profilesshould resolve those lane paths relative to the mezzanine root and detect the existing folders correctly:/Volumes/Mitchum/vfo_practice/mezzanine/mkv_original/Volumes/Mitchum/vfo_practice/mezzanine/mp4_originalLikely cause
In
services/vfo/src/Profile/Data_Structures/p_profiles_struct.c, the path construction appears to overwrite the joined root path with the subfolder name instead of appending it. The same pattern also appears to affect themp4_originalhelper.Impact
vfo profilesKEEP_SOURCE=falseRepro
/Volumes/Mitchum/vfo_practice/mezzaninemkv_originalmp4_originalunable_to_processunder that mezzanine root
vfo doctorsuccessfullyvfo profiles/mkv_originaland/mp4_originalNotes
I observed this while setting up a lean Craigstreamy aggressive-VMAF pack on a local volume. The config itself validated cleanly in
vfo doctor, so this looks like a runtime path-join bug rather than a config issue.