Kodi Community Forum

(2014-11-15, 17:26)ashlar Wrote: [ -> ]Hmmm... strange. I think it might depend on the initial speed burst. If it's fast enough, then fine. If it's not, then the file stops playing. Could you maybe add some sort of buffer percentage to reach before starting playback?

I mean, I am currently streaming the aforementioned Planet Earth backup from bluray, with an average bitrate of 23 Mbps. It's being downloaded at much higher speeds and it's not giving any problem. Just before, I tried with a much lower bitrate file (both are mkv) and it stops like before (see previous post). I suspect it depends on the initial moment, if it doesn't start fast enough, XBMC spits it out. Hence the buffer idea.

Edit: Yup, the same file that refused to playback is now playing perfectly. I really think it's just a matter of waiting a little bit for the download to get up to speed before playing back the partially downloaded file.

Edit 2: yup, trying back and forth... it's random. Some times the file gets played back, some other time it stops (but download is always correct and fast, and playable through MPC-HC while downloading). My guess is about the initial speed, when XBMC starts playing but doesn't have enough "info" about the file.

Correct, that is what I'm suspecting as well.

I'll be adding a third option to specify buffer level before playback (in %).

More advanced, there are ways to override the XBMC player itself. I've done this in a few other plugins. I'm intending to do the same for this plugin, which would allow me to "pause" playback if it ran out of buffer, delete cache file after playback (based on user's settings), also detect if the file is already cached locally from the plugin to play back the local file instead of streaming it from the server.

The MKV file I was testing is a fairly extreme. 43 second video at 360MB. With the bit rate, resolution, etc, if it were a 45 min video, it would be 11.6GB.

I'm intending on uploading my HD-DVD and bluray collection to Google Drive. I ripped the discs last year, they range from around 10-47GB per media file. I'll need to be splitting them.

Why would you need to split them? Max file size is 5 TB.

Hi! Any news on development?

(2014-11-21, 17:59)ashlar Wrote: [ -> ]Hi! Any news on development?

I was going to update you last night. I implemented the % to download before watching, but I'm having trouble gathering the filesize. It is a standard to relay a content-length between client and server in both directions when uploading or downloading content, but the google server download doesn't relay a content-length. So from a client end, the client doesn't know how large the file until it has received the connection close from google (indicating the transfer is done), or by examining the media header on the media file (min count etc).

I figured out a "slight" workaround which is to make a call to google to gather information about the quota-size-on-server for the media file. So I started incorporating this to figure out the %. It will work with "downloading" the "original" file. But I was going to extend this to the transcoded streams so that users are able to "download" google's transcoded versions of the media, but of course there is no way to gather the size of these. A dirty workaround I guess is to come up with a formula to figure out approx what the size would be based on the original file size and the resolution, etc.

Regardless of all this mumble-jumble, I'm expecting to publish what I have brewed together for the "original" (non-transcoded) files today.

Wow! That's great! Wasn't expecting all this. I'll keep an eye here and start testing as soon as possible. Thanks!

By the way... when I look at Drive, using the new interface, I see the file size. Hasn't Google added something to access that data? Quite strange.

(2014-11-21, 18:41)ashlar Wrote: [ -> ]Wow! That's great! Wasn't expecting all this. I'll keep an eye here and start testing as soon as possible. Thanks!

By the way... when I look at Drive, using the new interface, I see the file size. Hasn't Google added something to access that data? Quite strange.

That's the quota size on server #. Apparently it's pulled separate and not stored with the data itself. That also explains that on the web site, if you select a folder that has a lot of files in it, it can't tell you the size of the folder. It needs to look up each file, and if that will generate a lot of requests (if the folder is large), it doesn't bother attempting it.

I did some testing and 0.4.3 is ready using the workaround.

http://dmdsoftware.net/repository.ddurdl...-0.4.3.zip

There is a new parameter in settings for %. It's been working on the files I've tested. That heavy 43 second MKV file I discussed prior, I have to set it at 70% before it downloads enough to playback the entire file without running out. This is where the transcoded will help (for high bitrate content like this).

I've added a "Play cache file" in the right click menu. So if your playback stops or you want to playback from the cache file directly, you can rightclick on the media file and playback using the downloaded cache file, instead of manually invoking the file in Video->Files

I fixed one defect I noticed around switching account when using save authorization tokens which is fixed in this 0.4.3.

I haven't worked on the download transcoded versions yet.

Downloading now. Will test and report back. Thanks!

Quick question: am I correct in assuming that (I tried reading a little bit of the code) if download initial cache is set to 0% the plugin downloads 1MB before starting playback?
Here:
By changing the second line I can manually select how much I want to download before playback starts? I suggest to have full granularity for the percentage, in any case. 5% steps are probably too coarse to cover all needs (this being said while supposing that it's a simple change).

(2014-11-21, 22:58)ashlar Wrote: [ -> ]Downloading now. Will test and report back. Thanks!

Quick question: am I correct in assuming that (I tried reading a little bit of the code) if download initiali cache is set to 0% the plugin downloads 1MB before starting playback?
Here:

Code:

if sizeDownload < 1000000:
            sizeDownload = 1000000

By changing the second line I can manually select how much I want to download before playback starts? I suggest to have full granularity for the percentage, in any case. 5% steps are probably too coarse to cover all needs (this being said while supposing that it's a simple change).

Actually, I had it set at steps =1, but it made scrolling the slider slow, so I changed it to 5, but I was able to move inbetween numbers, such as set it to 4 and 7 etc. I'll change it back to step 1 for the next build. The step counter is the middle number in range for cache_percent in settings.xml


Correct, changing the sizeDownload value indicated would dictate the minimum size to download when % = 0.

Hi there! Thanks for this very useful add-on!

I'm running XBMC 13.2 on Fire TV. It's normally very stable but XBMC crashes very often while streaming videos with gdrive. I've tried 0.3.3 and today 0.4.3. Same result - after 2-3 og 4 videos it crashes and I'll have to start XBMC again.

Any ideas why this is happening?

(2014-11-22, 00:35)marslet Wrote: [ -> ]Hi there! Thanks for this very useful add-on!

I'm running XBMC 13.2 on Fire TV. It's normally very stable but XBMC crashes very often while streaming videos with gdrive. I've tried 0.3.3 and today 0.4.3. Same result - after 2-3 og 4 videos it crashes and I'll have to start XBMC again.

Any ideas why this is happening?

Is it running Android? Do you see the problem with youtube as well?

Which playback type are you using in settings?

With Raspberry Pi, I had web streaming issues such as crashes randomly when streaming at random times during playback or crashing immediately after starting a video. It never crashed when playing back local or over samba. Working with developers for troubleshooting and it was deemed to be specific to HTTPS and was fixed. But it was particular to Raspberry Pi and any HTTPS stream (including youtube etc,) I haven't seen the problem in Raspberry Pi new 13.2 builds. What I learned was that it was a very complex issue and was the reason why I started caching files and playing back the cache files because, in that case, if you didn't stream within the XBMC lib itself, then the problem didn't occur. The Disk playback setting in 0.4.3 bypasses this. So if you try using this setting, it would indicate if your issue is related to streaming over HTTPS.

Google streams only over HTTPS.

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.

(2014-11-22, 03:27)ashlar Wrote: [ -> ]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.

When the file has finished downloading, seeking, jumping and subtitles subsequent syncing work perfectly.

One thing to do: if you download a subtitle using a plugin, you finish watching a video and start another one, the previous subtitle is not deleted. And since the files are all called cache.mp4, you get the wrong subtitle. And sometimes you wouldn't need a subtitle at all.

(2014-11-22, 01:07)dmdsoftware Wrote: [ -> ]

(2014-11-22, 00:35)marslet Wrote: [ -> ]Hi there! Thanks for this very useful add-on!

I'm running XBMC 13.2 on Fire TV. It's normally very stable but XBMC crashes very often while streaming videos with gdrive. I've tried 0.3.3 and today 0.4.3. Same result - after 2-3 og 4 videos it crashes and I'll have to start XBMC again.

Any ideas why this is happening?

Is it running Android?

Yes

Quote: Do you see the problem with youtube as well?

Yes - just tested it

Quote:Which playback type are you using in settings?

Streaming

Quote:With Raspberry Pi, I had web streaming issues such as crashes randomly when streaming at random times during playback or crashing immediately after starting a video. It never crashed when playing back local or over samba. Working with developers for troubleshooting and it was deemed to be specific to HTTPS and was fixed. But it was particular to Raspberry Pi and any HTTPS stream (including youtube etc,) I haven't seen the problem in Raspberry Pi new 13.2 builds. What I learned was that it was a very complex issue and was the reason why I started caching files and playing back the cache files because, in that case, if you didn't stream within the XBMC lib itself, then the problem didn't occur. The Disk playback setting in 0.4.3 bypasses this. So if you try using this setting, it would indicate if your issue is related to streaming over HTTPS.

I've tested disk cache and memory cache with 0.4.3. With memory cache it still crashes. With disk cache on (local "sdcard" on the Fire TV) I haven't seen crashes but I've only tested a few times. Video starts ok but then the screen starts chopping. Perhaps after cache is empty.

Quote:Google streams only over HTTPS.

Any idea?

(2014-11-22, 10:38)marslet Wrote: [ -> ]

(2014-11-22, 01:07)dmdsoftware Wrote: [ -> ]

(2014-11-22, 00:35)marslet Wrote: [ -> ]Hi there! Thanks for this very useful add-on!

I'm running XBMC 13.2 on Fire TV. It's normally very stable but XBMC crashes very often while streaming videos with gdrive. I've tried 0.3.3 and today 0.4.3. Same result - after 2-3 og 4 videos it crashes and I'll have to start XBMC again.

Any ideas why this is happening?

Is it running Android?

Yes

Quote: Do you see the problem with youtube as well?

Yes - just tested it

Quote:Which playback type are you using in settings?

Streaming

Quote:With Raspberry Pi, I had web streaming issues such as crashes randomly when streaming at random times during playback or crashing immediately after starting a video. It never crashed when playing back local or over samba. Working with developers for troubleshooting and it was deemed to be specific to HTTPS and was fixed. But it was particular to Raspberry Pi and any HTTPS stream (including youtube etc,) I haven't seen the problem in Raspberry Pi new 13.2 builds. What I learned was that it was a very complex issue and was the reason why I started caching files and playing back the cache files because, in that case, if you didn't stream within the XBMC lib itself, then the problem didn't occur. The Disk playback setting in 0.4.3 bypasses this. So if you try using this setting, it would indicate if your issue is related to streaming over HTTPS.

I've tested disk cache and memory cache with 0.4.3. With memory cache it still crashes. With disk cache on (local "sdcard" on the Fire TV) I haven't seen crashes but I've only tested a few times. Video starts ok but then the screen starts chopping. Perhaps after cache is empty.

Quote:Google streams only over HTTPS.

Any idea?

All your answers definitely hit upon the HTTPS problems.

Here is a specific thread about lib ssl issues on android -> https://github.com/xbmc/xbmc/pull/3112

Its marked as fixed, so it is just a matter of figuring out what you need updated.

Where are you getting your XBMC from? It really sounds like you are not getting a patched version.