Problems opening cloud video files. (NanoHTTPD issues?)

Hello to all

I bought the plug in to support you and test the features of the clouds.

Here are my findings:
Cloud Rail authorizations work perfectly.
The problem is with the opening of streamed video files:
In the majority of the cases the opening of .avi and sometimes .mp4 do not work properly or it is random:

The problems are often related to a seek command but not always ... and the results are different depending on the cloud providers and players.

Tests made with MxPlayer, Xplayer, Samsung player, vlc ... on samsung galaxy s7 oreo with amaze v.3.2.2.

To do my tests I forced the intent with a createChooser:

 public static void launchCloud(final BaseFile baseFile, final OpenMode serviceType, final Activity activity) {
        final CloudStreamer streamer = CloudStreamer.getInstance();// only for video or audio file ??

        new Thread(new Runnable() {
            @Override
            public void run() {
                try {

                    streamer.setStreamSrc(baseFile.getInputStream(activity), baseFile.getName(), baseFile.length(activity));
                    activity.runOnUiThread(new Runnable() {
                        public void run() {
                            try {
                                File file = new File(Uri.parse(CloudUtil.stripPath(serviceType, baseFile.getPath())).getPath());
                                Uri uri = Uri.parse(CloudStreamer.URL + Uri.fromFile(file).getEncodedPath());
                                Intent i = new Intent(Intent.ACTION_VIEW);
                                i.setDataAndType(uri, MimeTypes.getMimeType(file));
                                /*PackageManager packageManager = activity.getPackageManager();
                                List<ResolveInfo> resInfos = packageManager.queryIntentActivities(i, 0);
                                if (resInfos != null && resInfos.size() > 0)
                                    activity.startActivity(i);
                                else
                                    Toast.makeText(activity,
                                            activity.getResources().getString(R.string.smb_launch_error),
                                            Toast.LENGTH_SHORT).show();*/
                                activity.startActivity(Intent.createChooser(i,"choose"));
                            } catch (ActivityNotFoundException e) {
                                e.printStackTrace();
                            }
                        }
                    });
                } catch (Exception e) {

                    e.printStackTrace();
                }
            }
        }).start();
    }

There are several problems here, in my opinion:
Why start the streamer if it is neither a video file or a streamable audio file?

Why not download the file to a temporary file and open it with an intent and then delete it on the return of the intent?

In case of failure of reading with certain readers the request remains active and the network 4g or wifi remains soliciting without the user does not perceerce. This often happens when the "seeking" fails. (you can check it with android profiler).

I do not see where the NanoHTTPD server is stopped in your code in case of failure?

There is often a warning that appears to specify that the body of the request has not been closed ... I do not know cloud rail.

W/OkHttpClient: A connection to https://api.dropboxapi.com/ was leaked. Did you forget to close a response body?

In your CloudStreamer code:

source.getMimeType ()

always returns null because the mimeType variable in CloudStrerameSource.class is never initialized.

Here are my first observations. I think this is a part that should be improved because it is the paying part, and it does not give satisfaction on opening streamable files.

Congratulations for your work anyway.

Start at the launchCloud entry point and read CloudStreamer and CloudStreamerSource, including the NanoHTTPD request lifecycle. Reproduce the reported .avi/.mp4 seek failures with the listed players and inspect the leaked response-body warning. Done means streamable files open reliably and failed requests no longer remain active or leak resources.