CreateHttpStreamAsync throws ArgumentOutOfRange on some torrents.

Birds of Pray for instance is throwing this. Boss Level didn’t throw it.

Exception Thrown By CreateHttpStreamAsync in StartStreamingTorrent:Specified argument was out of the range of valid values. Parameter name: index [System.Collections.ListDictionaryInternal]

 try
                {
                    //-- creates a ArgumentOutOfRange with some torrents.
                    streamObject = await streamprovider.CreateHttpStreamAsync(tf);
                    SaveFastResume(streamprovider.Manager, AppGlobals.gFastResumePath + @"\fast_resume.dat");
                }
                catch(Exception ex)
                {
                    System.Diagnostics.Debug.WriteLine("Exception Thrown By CreateHttpStreamAsync in StartStreamingTorrent:{0} [{1}]", ex.Message, ex.Data);
                    bCreateStreamFailed = true;

                }
                if (bCreateStreamFailed)
                {
                    return null;
                }
                return streamObject;

But other than that, your C# library is beautiful. Was able to watch torrents using it. I’ll take a closer look into why Birds Of Pray is failing hard. It’s able to download while streamprovider started. Just won’t CreateStreamSync. At first, I thought it was the name of the file. It’s long. I’m not entirely sure if I could create a friendlier version of the mp4 file name within the torrent.

[SICGames]

I put the SaveFastResume function after CreateStgreamAsync. So, I think that was my bad on my part. So now it’s working as it should. I placed the SaveFastResume on video player close and after when the file been downloaded.

And certainly, I’ll resume using the prealpha releases. I don’t mind changing code here and there in my app. 😃

[alanmcgovern]

@SICGames It looks like i did backported the required patch [0] to the monotorrent-1.0 branch in December but never actually released them. I just issued a new release in the stable series which includes the fix for files of length 2GB+.

[0] https://github.com/alanmcgovern/monotorrent/commit/c33b63fc76eae82e1a784d016beea9f692f8fcc3#diff-2e05c0dd4662ce4f95cc996d74d62d095fe2d37cbe50f89ef503d1dec49f2cf1R109-R110

That said - I’d still highly recommend using the pre-release if you’re OK dealing with the API changes. It should be far superior in terms of streaming performance due to the changes to how piece picking is performed in this mode.

Because once they were done, and I closed out, copied them to another folder (leaving same files still in the download (streamed folder) on the local drive, Monotorrent would redownload them all

This doesn’t sound right. MonoTorrent should run a hash check on files which already exist on disk, unless FastResume data has been loaded for that torrent. In this scenario fastresume data should not be loaded, so a full hashcheck should be performed as soon as StartAsync is invoked. No actual data should be re-downloaded.

I’ll double check this with the latest alpha. Maybe something went wrong with the DiskManager.ExistsAsync code with the recent changes around how the in memory cache is handled. Perhaps ‘false’ was being returned when the in memory cache was empty, instead of querying the filesystem for the existence of the file.