[dmdsoftware]

Thanks for your support!

Fixed in v0.7.31. 4 tests cases surrounding this were tested successfully. Hopefully you don't run into another issue.

http://dmdsoftware.net/repository.ddurdl...0.7.31.zip

This seems to fix caching. Great!

One thing I noticed, and I remember it being different, is that there is no indication of the percentage of caching advancing. I remember it used to give you a percentage but maybe it's somewhere in add-on settings. I'll look around and... nope, I don't see an option for this.

I also noticed that once you stop playback the plugin goes on downloading whatever you started watching. Is this behaviour configurable? Because if I stop something and decide to watch something else, I see that the two streams keep on both being downloaded (basically dividing, I guess, the available bandwidth). This could surely not being desirable for anybody save the most fortunate ones, bandwidth-wise).

Edit: I see this gets extended ad libitum, stopping the second file and starting a third one keeps three streams in download.

I used to have an option to determine if the pop-up caching/downloading was a dialog box or a background dialog box. You probably were familiar with the first. What I noticed on some builds of KODI, there is an issue where if you overlap dialogs (because the default "opening stream" dialog is automatic, and mine is overlay on top), it would freeze KODI when I close my dialog. Only happened since December when I last updated KODI, so it may be fixed, but the point is there are KODIs out there in the wild that my plugin would freeze due to the overlay of dialogs. Since this doesn't happen with the background dialog, I dropped the option to chose and use this one only.

Regarding continuing on, I was thinking about that. I leave it at this default behaviour to continue to download. If the playback stops (slow connection), then user can reclick on it and resume where they left off (the download continues and you don't restart the download). The KODI player does differentiate a player stopped (user clicked stopped) vs a player ended (player ran out of content) and have the download continue if player ended and kill the download if player stopped. Also, in cases where the user has multiple downloads going on ("make offline", etc) I was thinking about using file locks so that the user can decide he wants all his downloads to terminate and invoke a "Terminate all active downloads" in the plugin.

I'm already planning out a download-by-chunksize that will allow users to define a chunk size and the amount of data downloaded at any given time will not exceed that. For example, if you are watching a 20GB movie using cache, by the time you finish the movie, it will have stored 20GB of data locally. Using a limit chunk size of 500MB, it will only use up at most 1GB at any given time. 500MB for the current chunk being played back and 500MB cache-ahead for the next chunk. Also in this case, if you terminate the movie, it will stop downloading immediately.

On the same thought, adding a "preview" that will allow users to download only a few mins of a file so they can determine if that is indeed what they want to watch.

All these features I've been actively planning out as there are some users who want me to extend on the encfs support, which is what I've been working on from 0.7.23+. Since encfs requires caching, caching benefits from whatever enhancements I make to encfs support.