# MediaView Scenarios

**Preview after ingestion/inspection:**
- An .mov file with video+audio – no precache
- An .mov file with video+audio – precache at ingestion - **Should not have System/Reporting Events**
- An .mov file with video+audio – custom audio output mapping
- An .mxf file with video+audio
- An .mxf file with video only
- An .mxf file with audio only
- A video file with broken segments
- A file with multiple audio tracks – no precache
- A file with multiple audio tracks – precache - **Should not have System/Reporting Events**
- A file with multiple audio tracks – precache + extracted channels enabled
- A file with 1 unsupported audio track + 1 supported audio track
- A file with 2 unsupported audio tracks
- A CPL with video only
- A CPL with 1 video + 1 audio essence
- A CPL with multiple video+ multiple audio essences
- A CPL with multiple Clips (e.g. resulted from Deep Analysis Essence Compare)
- An image sequence – no precache
- An image sequence – precache - **Should not have System/Reporting Events**

Questions:
1. Select any video file with multiple audio channels, the caching starts automatically. Open the channel mapping, select Mono and channel 1, the caching starts automatically, select channel 2, the caching starts again, select channel 3 and so on then back to 1/2/3. All these changes without actually playing the video.
What is the expected index outcome for differentiating these events?

2. From what we've tested, replacing a file in the destination folder, from outside of Connect, doesn't trigger an invalidation of the cache already created for it.
In the case of this happening (NTP transcode can do this), as the fileID remains unchanged in Connect but the other attributes will come back differently (codec, duration, so on) what is the expected outcome for the index for the newly cached segments? Does it reset as the other values will no longer match or will it keep counting up?