[ashlar]

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.

[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.

[ashlar]

Got it. Almost. Currently if I press stop it keeps on downloading, not just if the player runs out of content. Is this the currently intended behavior or not?

Because you describe a different thing but maybe that's something you're planning or thinking about. I'm not sure.

[dmdsoftware]

Got it. Almost. Currently if I press stop it keeps on downloading, not just if the player runs out of content. Is this the currently intended behavior or not?

Because you describe a different thing but maybe that's something you're planning or thinking about. I'm not sure.

The default behaviour is to continue downloading. Before I change it, I'll be adding a toggle to allow someone to choose in settings the default behaviour (to stop download if playback is user-stopped).

[ashlar]

Back again after some more testing.

If selecting "Force into single file", starting playback on file A and then stopping, exiting Kodi, restarting Kodi, selecting a different video to play, say file B... it starts again the previously played file (A).

In any case, I really think that keeping on downloading a file after it's been stopped should be an option and not the default behaviour (sorry, I had the window open while testing and didn't see your latest message where you say the exact same thing ).

[ashlar]

Also... I point this out just for you to have a look. If you can't do anything about it, I'd understand... but... Using DSPlayer (Windows DirectShow based fork), if not using cache files don't start playing. If I use cache they do (I need to add the .stream extension to the configuration files but that's something undestandable considering how cache files are named).

Log here: http://xbmclogs.com/p2hsqbokr

Again, this is on DSPlayer fork. If you can have a look, if you don't want to, I'd understand. Maybe it's something trivial, I don't know.

[dmdsoftware]

Back again after some more testing.

If selecting "Force into single file", starting playback on file A and then stopping, exiting Kodi, restarting Kodi, selecting a different video to play, say file B... it starts again the previously played file (A).

In any case, I really think that keeping on downloading a file after it's been stopped should be an option and not the default behaviour (sorry, I had the window open while testing and didn't see your latest message where you say the exact same thing ).

I know what is happening there. Will be easy to fix. Will be in 0.7.32

[dmdsoftware]

Also... I point this out just for you to have a look. If you can't do anything about it, I'd understand... but... Using DSPlayer (Windows DirectShow based fork), if not using cache files don't start playing. If I use cache they do (I need to add the .stream extension to the configuration files but that's something undestandable considering how cache files are named).

Log here: http://xbmclogs.com/p2hsqbokr

Again, this is on DSPlayer fork. If you can have a look, if you don't want to, I'd understand. Maybe it's something trivial, I don't know.

Would naming it filename.stream.mp4 work? I want to have stream in there somewhere as I use it to detect offline media to present to the user in <Offline Media>.

[ashlar]

That filename would work, no problem. But the strange thing in the DSPlayer log I posted (the last one) is that, although I was testing with cache disabled, the errors seem to come from cache stuff. See lines 658, 659, 860, 864, 865 and 866.

[dmdsoftware]

That filename would work, no problem. But the strange thing in the DSPlayer log I posted (the last one) is that, although I was testing with cache disabled, the errors seem to come from cache stuff. See lines 658, 659, 860, 864, 865 and 866.

Can't see the log right now "502 Bad Gateway". Will try again later.

Were you testing with a file you had already cached previously? Because if the file is already cached, if you turn off cache, it will default to playing back the cached on. You can see what it is playing back by turning on force quality prompt, as it will show you a list of all media candidates (offline, original and transcoded). The most top one is the one played during default (with force quality prompt disabled).

[ashlar]

I can access XBMC logs now, but in any case I just copy you the lines I was referring to. Doing what you suggested didn't work, with cache disabled (and the cache directory completely cleared beforehand) it didn't even arrive at the quality prompt. Here are the lines:

PHP Code:

658. 20:12:23 T:30508 WARNING: XFILE::CFileFactory::CreateLoader - unsupported protocol(plugin) in plugin://plugin.video.gdrive-testing/?mode=video&instance=gdrive1&folder=0ALqc3r0JSiXEUk9PVA&filename=1qTrssusM7rnkpuYxdKWJM4gyVY09NWG_yNCJwo_mj4c&title=XBMC-gdrive&content_type=video
659. 20:12:23 T:30508   ERROR: XFILE::CFileCache::Open - failed to open source <plugin://plugin.video.gdrive-testing/?mode=video&instance=gdrive1&folder=0ALqc3r0JSiXEUk9PVA&filename=1qTrssusM7rnkpuYxdKWJM4gyVY09NWG_yNCJwo_mj4c&title=XBMC-gdrive&content_type=video>

860. 20:12:40 T:30700   ERROR: CCurlFile::Stat - Failed: HTTP response code said error(22) for https://www.googleapis.com/drive/v2/files/0B7qc3r0JSiXENG5EZ0VmQmZuZkU?alt=media
861. 20:12:40 T:30700   DEBUG: CCurlFile::GetMimeType - https://www.googleapis.com/drive/v2/files/0B7qc3r0JSiXENG5EZ0VmQmZuZkU?alt=media -> failed
862. 20:12:40 T:30700   DEBUG: CFileCache::Open - opening <drive/v2/files/0B7qc3r0JSiXENG5EZ0VmQmZuZkU> using cache
863. 20:12:40 T:30700   DEBUG: CurlFile::Open(0ADE1650) https://www.googleapis.com/drive/v2/files/0B7qc3r0JSiXENG5EZ0VmQmZuZkU?alt=media
864. 20:12:40 T:30700   ERROR: CCurlFile::FillBuffer - Failed: HTTP returned error 403
865. 20:12:40 T:30700   ERROR: CCurlFile::Open failed with code 403 for https://www.googleapis.com/drive/v2/files/0B7qc3r0JSiXENG5EZ0VmQmZuZkU?alt=media
866. 20:12:40 T:30700   ERROR: XFILE::CFileCache::Open - failed to open source <https://www.googleapis.com/drive/v2/files/0B7qc3r0JSiXENG5EZ0VmQmZuZkU?alt=media> 


[dmdsoftware]

I can access XBMC logs now, but in any case I just copy you the lines I was referring to. Doing what you suggested didn't work, with cache disabled (and the cache directory completely cleared beforehand) it didn't even arrive at the quality prompt. Here are the lines:

PHP Code:

658. 20:12:23 T:30508 WARNING: XFILE::CFileFactory::CreateLoader - unsupported protocol(plugin) in plugin://plugin.video.gdrive-testing/?mode=video&instance=gdrive1&folder=0ALqc3r0JSiXEUk9PVA&filename=1qTrssusM7rnkpuYxdKWJM4gyVY09NWG_yNCJwo_mj4c&title=XBMC-gdrive&content_type=video
659. 20:12:23 T:30508   ERROR: XFILE::CFileCache::Open - failed to open source <plugin://plugin.video.gdrive-testing/?mode=video&instance=gdrive1&folder=0ALqc3r0JSiXEUk9PVA&filename=1qTrssusM7rnkpuYxdKWJM4gyVY09NWG_yNCJwo_mj4c&title=XBMC-gdrive&content_type=video>

860. 20:12:40 T:30700   ERROR: CCurlFile::Stat - Failed: HTTP response code said error(22) for https://www.googleapis.com/drive/v2/files/0B7qc3r0JSiXENG5EZ0VmQmZuZkU?alt=media
861. 20:12:40 T:30700   DEBUG: CCurlFile::GetMimeType - https://www.googleapis.com/drive/v2/files/0B7qc3r0JSiXENG5EZ0VmQmZuZkU?alt=media -> failed
862. 20:12:40 T:30700   DEBUG: CFileCache::Open - opening <drive/v2/files/0B7qc3r0JSiXENG5EZ0VmQmZuZkU> using cache
863. 20:12:40 T:30700   DEBUG: CurlFile::Open(0ADE1650) https://www.googleapis.com/drive/v2/files/0B7qc3r0JSiXENG5EZ0VmQmZuZkU?alt=media
864. 20:12:40 T:30700   ERROR: CCurlFile::FillBuffer - Failed: HTTP returned error 403
865. 20:12:40 T:30700   ERROR: CCurlFile::Open failed with code 403 for https://www.googleapis.com/drive/v2/files/0B7qc3r0JSiXENG5EZ0VmQmZuZkU?alt=media
866. 20:12:40 T:30700   ERROR: XFILE::CFileCache::Open - failed to open source <https://www.googleapis.com/drive/v2/files/0B7qc3r0JSiXENG5EZ0VmQmZuZkU?alt=media> 


More fun times. Now it's the opposite situation from earlier where the URL is not being prepared properly, which that line earlier was dealing with when it shouldn't have been. I tried with never trancode off and on, and always prompt on and off, with the file cached and not cached and I haven't been able to reproduce that exact case you're running into.

I can't reproduce the situation you are facing but I also cannot get the selection menu to display regardless of the settings I choose, so it looks like 0.7.31 broke it. Back to the drawing board.

[dmdsoftware]

I traced back the new issue that was created with 0.7.31 which was the disappearing menu and have fixed that.

I also see the circumstances which you must be hitting with that latest error, even though I haven't been able to reproduce. You must be hitting that section of code with playOriginal, which means you have never transcode enabled in settings, but I wasn't hitting it when I had it enabled. Fixed it anyways for 0.7.32. Doing some more testing.

Prior to playing with your latest error, I was trying to figure out the logic around stopping download with playback is stopped. The concept mentioned earlier with tapping into the player module would work but lost at least 2 hours troubleshooting with it. Methods for onplaybackstopped was not triggering. Discovered with playing around that unless you sleep for at least a few nano seconds while downloading, none of the player interrupts are executed. It's like it is too busy cycling through downloading chunks that it misses the interrupts. As soon as I put a sleep statement for a few nano seconds after writing a chunk, the interrupts (when player clicks stop) are captured. Lucky, I don't think a few nano seconds will matter when downloading chunks. At least it is now working (download terminates if player clicks stop).

[dmdsoftware]

0.7.32 should be posted in < 12 hours, got to do some more testing

[ashlar]

More fun times. Now it's the opposite situation from earlier where the URL is not being prepared properly, which that line earlier was dealing with when it shouldn't have been. I tried with never trancode off and on, and always prompt on and off, with the file cached and not cached and I haven't been able to reproduce that exact case you're running into.

Well... I stressed it twice already but I want to be 100% sure you got that: the error when *not* caching comes using the DSPlayer fork for Windows.

DSPlayer plays basically everything, internet streams too (YouTube through Kodi plugin for instance, just to remain in "Googleland"), so it is strange. But I want to be crystal clear on this, because I'd hate to have you go crazy in trying to fix it to only later discover it was a Windows fork. I think you got that but I preferred repeating it.