Test and Debug an Implementation of ISmoothStreamingCache
Testing and debugging an implementation of ISmoothStreamingCache requires monitoring both the data transferred from the IIS server that delivers media data and monitoring data storage on the client computer. You can use the Visual Studio debugger to get information about data transfer and storage. For more information about the debugger and related tools, see Test and Debug Applications (IIS Smooth Streaming), Process Explorer utility on the TechNet Web site, and the Fiddler Web Debugging Proxy Web site.
An implementation of ISmoothStreamingCache gets data from an IIS server and stores it on the client computer using isolated storage (an instance of System.IO.IsolatedStorage.IsolatedStorage). To find out if a cache implementation is working, you have to be able to monitor data responses from the IIS server. When the SmoothStreamingMediaElement requests a manifest or media stream, the client application first checks the cache. If the cache has the data, the SmoothStreamingMediaElement uses cached data and does not download it from the IIS server.
Monitoring Data Transfer
To monitor the data coming from the server, you can use Fiddler, which you can download from the Fiddler Web Debugging Proxy Web site. Fiddler registers requests made by the client to the server and responses from the server, which lets you see whether the application is getting data from the server or from the cache. It can be difficult to determine whether data is coming from the ISmoothStreamingCache implementation or from the browser cache. To clear the browser cache, use the browser's commands for deleting temporary files. (For example, in Internet Explorer, display the Internet Options dialog box and use the options under Browsing history to clear cached data.) Alternatively, use the equivalent options in Fiddler.
Monitoring Data Storage
If you are testing using the Visual Studio Development Server or attaching to an application process with the debugger, you can find out where System.IO.IsolatedStorage.IsolatedStorage data is persisted on the client machine by setting a breakpoint after instantiating the storage area. In the sample described in Cache Plug-in Implementation of ISmoothStreamingCache, the isoFileArea variable contains an instance of System.IO.IsolatedStorage.IsolatedStorageIsolatedStorageFile. The instance contains a non-public member named m_AppFilesPath that contains the path to isolated storage, which might look like the following:
By watching this location as the application runs, you can verify that data is being stored in the cache or removed from it.
If you are using the cache implementation of ISmoothStreamingCache described in Cache Plug-in Implementation of ISmoothStreamingCache, you can use the debugger to watch the isoFileArea variable, which has public members named Quota, UsedSpace, and AvailableFreeSpace.
If the application is running outside the debugger, the path to isolated storage files can be obtained by using the Process Explorer utility.
The BeginPersist(CacheRequest, CacheResponse, AsyncCallback, Object) method gets the URL of each data chunk from the request parameter. The actual data of the request is obtained from the response parameter. In the sample application, the response is written to a file in isolated storage when the EndPersist(IAsyncResult) method runs. If Fiddler is running, you can watch the requests that the application makes to the server and the results of the requests. After data has been persisted in the cache, subsequent requests to the server should not be made because the data is obtained by the BeginRetrieve(CacheRequest, AsyncCallback, Object) method from the cache. As noted, the browser might cache the data. Fiddler has a Clear-Cache option that can be used to clear the cache, or you can use the browser's commands to delete browsing history.
The isolated storage folder should contain one manifest file and a number of data files; the exact number depends on media bandwidth for each media selection. All the files in the sample are named using GUIDs. The files are tracked in a dictionary object and in the System.IO.IsolatedStorage.IsolatedStorageSettings.ApplicationSettings property of the Silverlight application. As shown in the sample, when there is data in the cache, the URL/file name pairs are read into the dictionary object named keyUrls as the application starts.
If the capacity of the IsolatedStorage object's allocation is too low, there might not be enough capacity to store all the files for a lengthy media selection. The sample provides a button that can be enabled in the XAML source to increase the quota by calling the System.IO.IsolatedStorage.IsolatedStorageFile.IncreaseQuotaTo method. The method increases the quota by 1 megabyte each time the button is clicked. There is no equivalent method available in the API that can be used to reduce the quota. To reduce the quota, you have to delete the storage and reinitialize it.
The quantities to watch are the values of System.IO.IsolatedStorage.IsolatedStorageFile.UsedSize and System.IO.IsolatedStorage.IsolatedStorageFile.AvailableFreeSpace. Calling System.IO.IsolatedStorage.IsolatedStorageFile.DeleteFile on each file in isolated storage will clear data that has been persisted by the ISmoothStreamingCache implementation. The clear-cache method of the sample also clears the dictionary object and the System.IO.IsolatedStorage.IsolatedStorageSettings.ApplicationSettings instance that contains URL/file name pairs used to track files in the cache. When the cache is cleared, the System.IO.IsolatedStorage.IsolatedStorageFile.UsedSize and System.IO.IsolatedStorage.IsolatedStorageFile.AvailableFreeSpace members will adjust accordingly.
You can also remove isolated-storage capacity from the Silverlight UI. The Silverlight configuration dialog box provides the option to delete the isolated storage. In the Application Storage tab of the dialog box, delete the quota for the appropriate Web site.
On playback, the SmoothStreamingMediaElement instance can ignore cache requests that take too long to process. Data will be retrieved from the server but persisted in the cache for future requests.