Partial Assets
In some scenarios it may be required to store partial copies of a bigger assets. One typical use-case are partial restores of an assets:
An asset has been ingested to VidiCore.
The asset has been archived. The VidiCore shape refers to the archived file.
The original copy has been deleted, only the archived copy still exists.
A specific segment of the assets needs to be restored to be used within on-prem/hybrid/BYOC MAM.
The goal of partial assets is to properly model such segments while keeping the relation to the original item. It is done this way:
each partial clip will be stored as a separate item – subsequently called partial items;
partial items are connected to the complete ones via directed item-to-item relations with
type=partial-clip; the complete item is the source and the partial items are the targets of the directed relation; use this API call for setting the relation:POST /API/item/<completeItemId>/relation/<partialItemId>?direction=S&type=partial-clippartial clips can be detected as such if they have a relation of
type=partial-clipwhere they are the target; this API call can be used to decide this:GET /API/item/<itemId>/relation?direction=T&type=partial-clippartial items are never reported to MediaPortal (only applies the MediaPortal before 21.1), only complete items; to achieve this partial items need to be marked as “invisible for MediaPortal” via the mechanism described in section Hide Assets From User Interfaces [INT ENT XY.Z IG];
partial items need to be handled together with their complete items in housekeeping (deletion).
Due to this concept only components that need to work on partial clips need to have special logic.
Comparing It To Worker-Based VPMS
In VPMS2 partial clips for an asset where modelled as additional ClipList entries at the same SJob; the partial clips were marked as such but looked the same as complete clips otherwise (ClipUsage etc.). This caused a lot of problems as all modules had to be aware of partial clips – which in fact wasn’t the case.