dsym file

It appears that the LL HLS playlist provided is missing the required EXT-X-RENDITION-REPORT. That leads to the player dropping out of low latency mode. Note that the spec requires that every LL-HLS Media Playlist contain a Rendition Report for every other Media Playlist in the MVP Should you find that a missing rendition report is not the issue, please file a bug report following steps at https://developer.apple.com/services-account/download?path=/iOS/iOS_Logs/CoreMedia_Logging_Instructions.pdf

Hello! This doesn't sound right, and is probably a bug. But to be sure, we need some more information to investigate Can you please file a bug report and include a video recording of you experiencing the issue? This site will walk you through the steps, https://developer.apple.com/bug-reporting/ You can tell me what the Feedback ID is for this issue and I'll make sure it gets to the right team to investigate.

A bug report has been filed via the Feedback Assistant with the Feedback number: FB21773746.

I did file a bug, FB21763493 I did try using the security scoped bookmark for creating the PDF Services directory but didn't think I needed to then create a new security scoped bookmark for the newly created directory. Once I implemented that suggestion, creating the directory and workflow did work with one user prompt. I also tried using the Save dialog to create the directory and workflow and, you are correct, it is a bit weird :-) but it worked. Now I have two working methods to achieve this, which means I don't need to mess with entitlements. Thanks for the help. Dave

I couldn't post the snippet as it fails the sensitive language check... So I try to add it as text file [here] leaks.snippet.txt

Thanks for all that info. [quote='873820022, dylandylandylan, /thread/813642?answerId=873820022#873820022, /profile/dylandylandylan'] apologies for my extra-long answer [/quote] Au contraire, that’s exactly the sort of info I need (-: First up, let’s talk about how the API should work. The NETunnelProviderManager APIs are asynchronous for a reason: They’re not supposed to complete until they’re done. In your first example, either one of the following should be true: Either removeFromPreferences() should not return [1] until the tunnel is closed. Or the open tunnel shouldn’t get in the way of the system establishing the new settings. The fact that you have to add arbitrary delays is clearly a bug IMO, and I encourage you to file it as such. Given that you can easily reproduce this, I recommend that you enable extra NE logging via the VPN (Network Extension) for macOS instructions on our page Bug Reporting > Profiles and Logs and attach a sysdiagnose log taken shortly after seeing the issue. Please

Thanks for the crash report. I was able to uncover an internal bug that AFAICT is tracking the same issue (r. 154431813) [1]. Sadly, that remains unfixed and doesn’t offer any ideas as to how you might avoid it. My advice is that you file your own bug about this, attaching all the information you have available. Please post your bug number, just for the record. Also, you mentioned that you’re in touch with some users that can reproduce this. If so, could you ask them to file their own report about it in Feedback Assistant. That should capture a sysdiagnose log, which might help with the investigation. If that happens, ask them to send you their bug number and then post those here as well. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] Much to my own surprise. Radar is a very big haystack (-:

I can’t speak for a564033861, but from an Apple perspective it’s hard to track down whether we fixed this problem because they didn’t post their bug number )-: Given that, my advice to you is going to be the same as the original advice I gave them: Please file a bug. Ideally with a linker snapshot. Post the bug number here to make it easier on Future Quinn™. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='873889022, dileepachandrasekara, /thread/813571?answerId=873889022#873889022, /profile/dileepachandrasekara'] Bug filed FB21757864 [/quote] Thanks. I’ve added my own comments to your bug. [quote='873907022, dileepachandrasekara, /thread/813571?answerId=873907022#873907022, /profile/dileepachandrasekara'] I want to understand whether this is a bug fix … [/quote] In my opinion this is a bug, but the resolution of your bug report will act as an official answer to that question (-: [quote='873889022, dileepachandrasekara, /thread/813571?answerId=873889022#873889022, /profile/dileepachandrasekara'] We need to extract the filename without extension for display purposes. [/quote] Ah, I’ve found myself in that very conundrum. It’s annoying that we never got a Swift equivalent of Objective-C’s -stringByDeletingPathExtension method. I think it’d be reasonable for you to file an enhancement request for that. And if you do, please post that bug number as well. [quote='873889022, dileepachandrase

Thanks for those additional answers. [quote='873877022, Retouch, /thread/813562?answerId=873877022#873877022, /profile/Retouch'] I understand it refers to the scenario: “You have an existing flow object …” [/quote] OK. The error you’re getting is NEAppProxyFlowErrorDomain / 1. That’s a bit confusing because the error domain string doesn’t match the error domain identifier. In fact, the identifier is NEAppProxyErrorDomain: print(NEAppProxyErrorDomain) // -> NEAppProxyFlowErrorDomain So, code 1 corresponds to NEAppProxyFlowErrorNotConnected, which is documented to mean: The flow is not fully opened. However, you’re sure that the flow was fully open, so it’s not that simple. I did some digging and it seems that this error is caused by you attempting to write when the write side of the flow is closed. There’s a couple of ways that might happen: If you write to the flow before the open is complete. Or at least I think that’s the case. I wasn’t able to be 100% sure about that, and I declined to research further