No. Every card reads the existing attachment posts, postmeta keys, and post_parent links Videopack already writes. The encoding queue, the FFmpeg pipeline, and the player shortcodes continue to behave exactly as before. SleekView Charts is a read-only reporting surface on top of the attachment library.

Yes. Encoded WebM, MP4, and OGV children are stored as additional attachments linked via post_parent to the source video. A SleekView filter that selects child attachments turns the dashboard into a coverage report for which sources have been encoded to which target formats.

Yes. File size is read from the attachment metadata Videopack already records, and duration from the postmeta keys the plugin writes after probing each upload with FFmpeg. Number cards summarize totals and averages, and bar or area cards trend them over time.

Yes. The top-level filter bar applies across all cards. Selecting one or more post_author values scopes every chart to that editor, so a per-uploader review is one filter click away from the library-wide view without rebuilding the dashboard.

No. Charts are computed against the same attachment and postmeta queries WordPress already supports, with SleekView caching aggregation results between renders. The first paint may take a moment on very large libraries, subsequent loads are immediate.

Yes. Videopack writes the poster image reference into postmeta on each video attachment. A SleekView number card for the share of videos that have a poster reveals coverage at a glance, and a date filter scopes it to recent uploads only.

Yes. Each card supports a CSV export of its underlying aggregation. Export the MIME type mix for a quarterly review or the uploader bar to share workload context with the editorial lead running the next planning meeting.

Yes. SleekView runs per site within a multisite network, so each site has its own Charts view against its own attachment library. Charts only ever read the current site's attachments, keeping reporting scoped and private to that subsite.