uwp mostrecentlyusedlist添加导致COM类型异常

uwp mostrecentlyusedlist addition causes COM type exception

StackTrace

" 在 Windows.Storage.AccessCache.StorageItemMostRecentlyUsedList.Add(IStorageItem 文件、字符串元数据、RecentStorageItemVisibility 可见性)\r\n 在 FluentVideoPlayer.Helpers.FileHelper。<>c__DisplayClass7_0。b__0()\r\n 在 Microsoft.Toolkit.Uwp.Helpers.DispatcherHelper.<>c__DisplayClass10_0`1.b__0()"

I am trying to add a StorageFile to MostRecentlyUsedList and as a result I am getting this exception.

异常

HRESULT E_FAIL has been returned from a call to a COM component

代码

internal async static Task AddToHistory(StorageFile fileToBeAdded) => await DispatcherHelper.ExecuteOnUIThreadAsync(() => StorageApplicationPermissions.MostRecentlyUsedList.Add(fileToBeAdded, "", RecentStorageItemVisibility.AppAndSystem));

I have this static method to use within a static class so I can call it from any page in the app. I can verify that StorageFile object is not null and perfect I also tried to solve it by using DispatcherHelper as you can see in the code, but with or without it, exception occurs in both cases.

更新

我也尝试添加到 FutureAccessList 而不是 MostRecentlyUsedList 并且在这两种情况下我都遇到相同的错误

更新 2

正常访问列表不会导致任何错误,就像我可以使用以下代码访问它

var mlist = StorageApplicationPermissions.MostRecentlyUsedList;
var entries = mlist.Entries;

只有当我尝试向其中添加存储文件时才会出现错误。

问题出在部分 StorageFiles 我实际上是根据以下博客 post.

从 KnownFolders.VideoLibrary 查询文件

https://blogs.msdn.microsoft.com/adamdwilson/2017/12/20/fast-file-enumeration-with-partially-initialized-storagefiles/

因此,当我们使用以下索引选项时,它实际上会为我们初始化部分存储文件,这会在我们尝试将其添加到最近使用的列表或 futureacceslist 时导致异常

IndexerOption = IndexerOption.OnlyUseIndexerAndOptimizeForIndexedProperties

So to solve this I am now using IndexerOption.UseIndexerWhenAvailable now I don't get any exception, but ofcourse I am sacrificing the speed I was getting before with partial storage files. Which is disappointing as when trying to do a job with full storagefile, it should automatically initialize the partial storagefile to full storagefile as per the blog post. but that is not the case here unfortunately.