I have figured out a solution. This post on StackOverflow helped out immensely: The secret is to use an SKRenderer() in addition to the SKView renderer. They are not mutually exclusive. The example referenced above uses a SceneKit view as the source, grabs a metal texture from the SceneKit scene, and then uses that metal texture as the texture of a second SceneKit scene that has a single plane object using the metal texture as its diffuse texture. The same setup works with SpriteKit: For my use case, I was able to implement using a single SKScene, rendered to both an SKView() and an SKRenderer() - just call the SKRenderer.render() method inside your SKScene.update() method. The SKRenderer is what is used to render the scene into a MTLTexture using a renderPassDescriptor. I found that I had to call SKRenderer.render() and commandBuffer.commit() prior to updating any SpriteKit nodes - but it works great. That MTLTexture can then be used however is necessary. In my test setup, I also rendered it to a separate SCNView using a single plane node.

Same issue. I went through a whole bunch of permuations - and it seems this is limited to any 16.4 tvOS simulator - tested both 3rd gen and 2nd gen with 16.4 and both show black screen for video. Note that older versions of the simulator (16.1, 16.0) work just fine. So far, video seems to be working on real device with 16.4.1

Found the answer on SO... you can set these values using the AVMetadataItem with the identifiers: AVKitMetadataIdentifierExactStartDate, AVKitMetadataIdentifierExactEndDate

Same issue. tvOS application Does not use Unity at all.

This is one of the most annoying issues I have found with tvOS. What I have found is that when a UIScrollView enters in this "fastFocus" scroll mode, the focus moves to UIView of type "UIFocusFastScrollingIndexBarView". So what I did was put a check in my didUpdateFocus() function like so: if let tempNextFocusView = context.nextFocusedView { let desc = type(of: tempNextFocusView).description() let isFastFocusMode = desc.contains("_UIFocusFastScrollingIndexBarView") } At least now I know when I am in this mode. One of the biggest issues I have is that it can be difficult to get a notification that the user has exited out of this mode. There are use-cases where none of my UIScrollView delegate functions are called - typically if the user does a bunch of fast swiping and then clicks to stop scrolling then scrolls again... No items will receive focus and none of the scrollView delegates are called. i.e., our QA can break this pretty easily.

I am also getting this crash. Same circumstances. Starting up a video stream using AVPlayerViewController. I also set up both a AVPlayerItem.status observer as well as a "timeControlStatus" observer. Then when I change to a different stream, I remove the observers, stop the current stream using player.replaceCurrentItem(with:nil) - nil out properties holding on the playerItem & player properties. Then start a new stream, creating all new playerItem (AVPlayerItem) & player (AVPlayer) objects. Is there a known workaround or a way to prevent this crash? Am I doing something wrong? This current strategy has worked for years. Getting reports from the customers about this crash.