[dmdsoftware]

Ok, back from some testing.

What works:
Downloading files is as fast as it gets. With a fast connection even 1% of cache is plenty enough. I suspect that, maybe, you would save yourself some complexities by giving a range in bytes to cache. 1-5-10-50-100-250-500-1000 MB should probably cover most needs and save you from trying to calculate percentages (which, from your explanation, seemed rather complex).
Subtitles download correctly, the plugin passes the correct filename to the subtitles plugin (although it always shows cache.mp4 as filename (which is what resides in the temp directory), the subs fetched follow the true filename.

What doesn't work:

Even when stopping a file being played back, the downloading continues. I haven't waited long, but it seemed to me that the only way to stop the download was exiting XBMC. This stopped the download but left the file there, in the temp directory.

Resuming seems out of the question, even when trying to resume to a point which has already been downloaded.

Moving inside the file, even when trying to move to a point which has already been downloaded.
Say you've already downloaded... 20 mins of a movie. If you jump ahead 30 seconds from the beginning (for the sake of the example, suppose you paused the movie as soon as it started, to allow for download to reach 20 mins ahead), two things happen:

1) The jump happens with significant delay.
2) Subs don't take this jump in consideration and behave as if it didn't happen, ie. they "stay behind.

If you haven't already downloaded the part where you're trying to jump to, the player simply exits.

Now... I'm unfortunately no programmer but trying to understand how things work "behind the curtains" I went here https://developers.google.com/drive/v2/r...get#try-it and authorized the code to get info from my Drive account.

Not knowing which info might be usefule I selected all fields and found out that you can discover, among others:

MIME type, which for instance is correctly identified as matroska for .mkv files (don't know if this makes or doesn't make a difference when skipping ahead in portions already downloaded)
Exact size, with bytes precision (hence you shouldn't be having problems in getting the right file size to calculate the percentage).

Also concerning the seeking problem, I keep going back to the option to request a range of bytes to download, through the range header option.
I don't know if this is doable for all file types but Matroska (mkv) should have meta seek list and cues at the beginning of the file, which should give the exact position in bytes of each point where you are supposed to be able to seek. Am I wrong in this? If I'm not, maybe one could ask the server for the file with range X - EndOfFile, so as to resume streaming from the point needed till the end of the file. I'm clearly over my head with this and, in all honesty, I don't know how flexible is the interaction between XBMC internal player and plugins.

What I see, empirically, is that if I try to add a partially downloaded file as a source under Files, the seeking problems remain (subtitles going out of sync included). But I know for certain that when seeking and jumping in a file coming through a Samba share... everything happens, with some delay maybe, but it works. And in that case, XBMC has very little of the file at the local system disposal. How does XBMC know where to seek to, what's the difference in that case? There must be a way for XBMC to know where to start reading the file (in bytes) to reach a certain time point in the file. There must be some parsing going on somewhere, am I right?

I know this is complex, extremely so probably. I'm just trying to be thorough and I appreciate enormously the amount of work you've already done. This is showing clear progress and, for many practical uses, it's already clearly very usable.

Thanks for testing out and providing feedback.

Does the seeking and subtitle issue exist if you playback a completed cache file?

If you stop the player, the plugin thread continues to download until complete. If you play a different video from within the plugin, it'll terminate the previous to start the new one. To automatically delete the file or stop downloading the file on stopping the player, it would involve overriding the player which is doable and I've done before, but can get complicated.

To seek a particular point in the file, using byte ranges, is possible. But I wouldn't know how to universally translate that to mins. The XBMC player only allows the user to seek based on duration, so seeking to mid-point in a movie doesn't necessarily mean that midpoint is exactly halfway through the file.

The transcoding by Google Drive does let you seek to a duration in a stream. It wouldn't work as-is today. I would need to override the player, intercept seeks, and instruct the XBMC player how to communicate these seeks to the Google Drive server. I will be able to implement this much easier than the earlier scenario. Essentially, the implementation would be similar to how one seeks in the youtube web player. If you seek past a point that hasn't been downloaded, the player pauses momentarily, stops "buffering" where it was at, and starts buffering to the point you've seeked to, and resumes playback at that point.