Kodi Community Forum

Full Version: gdrive - Google Drive Video/Music Add-on
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
(2014-11-22, 16:36)dmdsoftware Wrote: [ -> ]
(2014-11-22, 10:38)marslet Wrote: [ -> ]
(2014-11-22, 01:07)dmdsoftware Wrote: [ -> ]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.

I'm running 13.2 Gotham for Android.

As proposed her:
http://forum.kodi.tv/showthread.php?tid=...id=1800114

I have just:
1. Turn off both of the filters (mediacodec and libstagefright) under hardware acceleration.
2. Change hardware acceleration to software.
3. Enable 'allow multi thread software decoding

And until now it have been stable.
Now running 0.4.3 on Android (Amazon Fire TV). Everything works perfect except picture support. Is it supposed to work? I can browse dirs with pictures but are not able to view the pictures.
(2014-11-23, 13:52)marslet Wrote: [ -> ]Now running 0.4.3 on Android (Amazon Fire TV). Everything works perfect except picture support. Is it supposed to work? I can browse dirs with pictures but are not able to view the pictures.

The code for handling photos is in 0.4.0 and greater but it is disabled as I'm still testing it.

There is no way to view images over HTTP without downloading them first, in XBMC. The code "caches" the images in a local directory and invokes a slideshow.
Some significant fixes in 0.4.4 to deal with corrupt media files in Google Drive. 0.2.7 was the last version that properly dealt with these files, allowing them to be listed and played. In 0.3.x and 0.4.x, these files would be missing from the index. They are back now in 0.4.4 and with fixes around them to ensure successful playback.

Version 0.4.4 -> http://dmdsoftware.net/repository.ddurdl...-0.4.4.zip
- make quality selection a list instead of a directory list
- regression fix -- plugin error trying to present stream list if the media file isn't processed or processable by google
- regression fix -- list media files that are not processed or unprocessable by google (last working in 0.2.7)

With these fixes, I'll be retiring bug fixes for 0.2.7.

(2014-11-11, 00:14)leonardo_pr Wrote: [ -> ]
(2014-11-10, 23:21)dmdsoftware Wrote: [ -> ]
(2014-11-10, 21:58)leonardo_pr Wrote: [ -> ]the link is ok.
was shared to anyone with the link
see print:
https://drive.google.com/file/d/0B3DLGY_...sp=sharing

I deleted the folder
C:\Users\Leonardo\AppData\Roaming\XBMC\addons\plugin.video.gdrive\resources\language\portuguese (Brazil)

and now I can log into my account and navigate the folders, but when I try to access any video file keeps giving error
https://drive.google.com/file/d/0B3DLGY_...sp=sharing

follows the folder with all the videos.
Is shared with anyone with the link
https://drive.google.com/folderview?id=0...sp=sharing

None of the files work in a web browser. If fhey don't work in a browser, they won't work in the plugin.

you are correct
when I'm logged into my account the links work.
coo you insisted that did not work, I decided to log out of gmail account and got the same error you reported.

But when I am logged in to gmail all videos function normally ... I did see the prints of the video running

https://drive.google.com/file/d/0B3DLGY_...sp=sharing
https://drive.google.com/file/d/0B3DLGY_...sp=sharing
https://drive.google.com/file/d/0B3DLGY_...sp=sharing
https://drive.google.com/file/d/0B3DLGY_...sp=sharing
https://drive.google.com/file/d/0B3DLGY_...sp=sharing
https://drive.google.com/file/d/0B3DLGY_...sp=sharing
https://drive.google.com/file/d/0B3DLGY_...sp=sharing
https://drive.google.com/file/d/0B3DLGY_...sp=sharing
https://drive.google.com/file/d/0B3DLGY_...sp=sharing
https://drive.google.com/file/d/0B3DLGY_...sp=sharing

as you can see the video works when I am logged in google, but does not work when I'm logged in Detro plugin.

21:10:18 T:3680 ERROR: XFILE::CDirectory::GetDirectory - Error getting plugin://plugin.video.gdrive/?mode=streamVideo&title=Meu%20Of%c3%adcio%20%c3%a9%20Matar.(2014).Dublado.1080p.By.Luan.Harper.mp4
21:10:18 T:3680 ERROR: CGUIMediaWindow::GetDirectory(plugin://plugin.video.gdrive/?mode=streamVideo&title=Meu%20Of%c3%adcio%20%c3%a9%20Matar.(2014).Dublado.1080p.By.Luan.Harper.mp4) failed
21:10:18 T:2552 NOTICE: Thread BackgroundLoader start, auto delete: false
21:11:03 T:1500 NOTICE: Thread JobWorker start, auto delete: true
21:11:03 T:2000 NOTICE: Thread LanguageInvoker start, auto delete: false
21:11:03 T:2000 NOTICE: -->Python Interpreter Initialized<--
21:11:03 T:1028 NOTICE: Thread JobWorker start, auto delete: true
21:11:05 T:2000 ERROR: EXCEPTION Thrown (PythonToCppException) : -->Python callback/script returned the following error<--
- NOTE: IGNORING THIS CAN LEAD TO MEMORY LEAKS!
Error Type: <type 'exceptions.KeyError'>
Error Contents: ('',)
Traceback (most recent call last):
File "C:\Users\Leonardo\AppData\Roaming\XBMC\addons\plugin.video.gdrive\default.py", line 268, in <module>
item = xbmcgui.ListItem(path=videos[singlePlayback]+ '|' + gdrive.getHeadersEncoded(gdrive.useWRITELY))
KeyError: ('',)
-->End of Python script error report<--
21:11:05 T:3680 ERROR: XFILE::CDirectory::GetDirectory - Error getting plugin://plugin.video.gdrive/?mode=streamVideo&title=Transformers.A.Era.da.Extin%c3%a7%c3%a3o.2014.720p.Dual-WOLVERDONFILMES.COM%20(1).mkv
21:11:05 T:3680 ERROR: CGUIMediaWindow::GetDirectory(plugin://plugin.video.gdrive/?mode=streamVideo&title=Transformers.A.Era.da.Extin%c3%a7%c3%a3o.2014.720p.Dual-WOLVERDONFILMES.COM%20(1).mkv) failed
21:11:05 T:1760 NOTICE: Thread BackgroundLoader start, auto delete: false


Before it worked perfectly.

I moved the folder to the public and yet the videos do not work in the browser ... only when I'm logged in.
will be some blocking google drive?
https://drive.google.com/folderview?id=0...sp=sharing


I tracked down the issues. Seems they are related to a few handlers around bad videos. v0.4.4 has these fixes and playback should be working.
First off: great addon, thank you so much for your effort, this is greatly appreciated!

You have mentioned adding encryption somewhere in this thread. Could you describe what exactly you want to encrypt, and how this would be implemented?

I am very interested in this, as I don't want to store my media file unencrypted on Google Drive, but still would like to be able to stream them.
(2014-11-21, 23:38)dmdsoftware Wrote: [ -> ]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

Code:
<setting id="cache_percent" type="slider" subsetting="true" label="30036" default="10" option="percent" visible="eq(-3,1)" range="0,5,100" />

Correct, changing the sizeDownload value indicated would dictate the minimum size to download when % = 0.
Hi, just wanted to remind you about this, since I still see it in 5% steps in 0.4.4. Depending on file size, 5% can definitely be too much. Smile
(2014-11-24, 13:14)hans01 Wrote: [ -> ]First off: great addon, thank you so much for your effort, this is greatly appreciated!

You have mentioned adding encryption somewhere in this thread. Could you describe what exactly you want to encrypt, and how this would be implemented?

I am very interested in this, as I don't want to store my media file unencrypted on Google Drive, but still would like to be able to stream them.

I've added some encryption routines to the 0.4.0 code base, but have disabled it while I test it.

It uses Python Crypto libraries with a user supplied salt and password to decrypt files stored in application-octet-stream filetype. For photos, it is no different then the current code where it caches the files to a local directory and it decrypts it as it writes the file to disk. For video and music, it is similar to the disk cache mode, the plugin downloads the file and decrypts as it writes it to disk, and it playsback the file as it downloads. I'm doing some serious digging around in the XBMC player classes to see if this can be improved on, to actually decrypt the content using XBMC's player. The disk cache method causes issues with subtitles.

The user can use any encryption script that uses the same encryption parameters. I have a simple python script that will create take a user's desired password, create a salt and use the combination to encrypt a local folder's content. User can use another script (I have both a perl and python script) to upload the files to their Google Drive. They can also use Google Drive client software or web app to uploaded the encrypted files. It just matters that the file type is application-octet-stream.

I typically use encfs to store my files I want secured in Google Drive. The idea is very similar here. As a matter of fact, with a few adjustments, the current disk cache method in the plugin could accommodate encrypted encfs files. After I've had more time to test both methods, I was going to post some videos demonstrating it. I don't see there really being much of a need or a practical implementation that would make this a default for a typical user.

(2014-11-24, 13:57)ashlar Wrote: [ -> ]
(2014-11-21, 23:38)dmdsoftware Wrote: [ -> ]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

Code:
<setting id="cache_percent" type="slider" subsetting="true" label="30036" default="10" option="percent" visible="eq(-3,1)" range="0,5,100" />

Correct, changing the sizeDownload value indicated would dictate the minimum size to download when % = 0.
Hi, just wanted to remind you about this, since I still see it in 5% steps in 0.4.4. Depending on file size, 5% can definitely be too much. Smile

Didn't even dawn on me to include the change in the release. The release was a spur-of-the-moment after I encountered a "problematic" video on my Google Drive which drove me to debugging it and finding the playback issue around unplayable videos.
(2014-11-24, 14:25)dmdsoftware Wrote: [ -> ]Didn't even dawn on me to include the change in the release. The release was a spur-of-the-moment after I encountered a "problematic" video on my Google Drive which drove me to debugging it and finding the playback issue around unplayable videos.
Sure! Big Grin

Just wanted to post a reminder, that's all. Thanks for all the great work.
(2014-11-24, 15:09)ashlar Wrote: [ -> ]
(2014-11-24, 14:25)dmdsoftware Wrote: [ -> ]Didn't even dawn on me to include the change in the release. The release was a spur-of-the-moment after I encountered a "problematic" video on my Google Drive which drove me to debugging it and finding the playback issue around unplayable videos.
Sure! Big Grin

Just wanted to post a reminder, that's all. Thanks for all the great work.

I'll make sure it is in the next release. There is a nice surprise coming into the next release that will make everyone want to update. Early this week, if all goes well.
(2014-11-24, 14:25)dmdsoftware Wrote: [ -> ]I've added some encryption routines to the 0.4.0 code base, but have disabled it while I test it.

It uses Python Crypto libraries with a user supplied salt and password to decrypt files stored in application-octet-stream filetype. For photos, it is no different then the current code where it caches the files to a local directory and it decrypts it as it writes the file to disk. For video and music, it is similar to the disk cache mode, the plugin downloads the file and decrypts as it writes it to disk, and it playsback the file as it downloads. I'm doing some serious digging around in the XBMC player classes to see if this can be improved on, to actually decrypt the content using XBMC's player. The disk cache method causes issues with subtitles.

The user can use any encryption script that uses the same encryption parameters. I have a simple python script that will create take a user's desired password, create a salt and use the combination to encrypt a local folder's content. User can use another script (I have both a perl and python script) to upload the files to their Google Drive. They can also use Google Drive client software or web app to uploaded the encrypted files. It just matters that the file type is application-octet-stream.

I typically use encfs to store my files I want secured in Google Drive. The idea is very similar here. As a matter of fact, with a few adjustments, the current disk cache method in the plugin could accommodate encrypted encfs files. After I've had more time to test both methods, I was going to post some videos demonstrating it. I don't see there really being much of a need or a practical implementation that would make this a default for a typical user.
This sounds very promising. I agree that this is something that most users probably wouldn't need or know what to do with. I might fork your code and add the encryption routines myself. If you could point me in the right direction, or keep me updated on your progress I would very much appreciate this.

By the way, I wouldn't depend too much on encfs as this has a few significant security problems, as a recent audit has shown. Better simply implement a reliable encryption algorithm like AES-128-CBC or -XTS in my opinion.
(2014-11-24, 15:59)hans01 Wrote: [ -> ]
(2014-11-24, 14:25)dmdsoftware Wrote: [ -> ]I've added some encryption routines to the 0.4.0 code base, but have disabled it while I test it.

It uses Python Crypto libraries with a user supplied salt and password to decrypt files stored in application-octet-stream filetype. For photos, it is no different then the current code where it caches the files to a local directory and it decrypts it as it writes the file to disk. For video and music, it is similar to the disk cache mode, the plugin downloads the file and decrypts as it writes it to disk, and it playsback the file as it downloads. I'm doing some serious digging around in the XBMC player classes to see if this can be improved on, to actually decrypt the content using XBMC's player. The disk cache method causes issues with subtitles.

The user can use any encryption script that uses the same encryption parameters. I have a simple python script that will create take a user's desired password, create a salt and use the combination to encrypt a local folder's content. User can use another script (I have both a perl and python script) to upload the files to their Google Drive. They can also use Google Drive client software or web app to uploaded the encrypted files. It just matters that the file type is application-octet-stream.

I typically use encfs to store my files I want secured in Google Drive. The idea is very similar here. As a matter of fact, with a few adjustments, the current disk cache method in the plugin could accommodate encrypted encfs files. After I've had more time to test both methods, I was going to post some videos demonstrating it. I don't see there really being much of a need or a practical implementation that would make this a default for a typical user.
This sounds very promising. I agree that this is something that most users probably wouldn't need or know what to do with. I might fork your code and add the encryption routines myself. If you could point me in the right direction, or keep me updated on your progress I would very much appreciate this.

By the way, I wouldn't depend too much on encfs as this has a few significant security problems, as a recent audit has shown. Better simply implement a reliable encryption algorithm like AES-128-CBC or -XTS in my opinion.

I tend to maintain 3 branches of this code for some reason. Rock solid 0.2.x that you know does the trick and won't fail you, 0.3.x that has nice features but some things fall in the waste-basket, and 0.4.x which is what I'm running on my gear. The first few 0.4.x releases I forgot to comment out the import statements so it wouldn't even run on folks who don't have the crypto modules installed.

Now that I'm feel the stuff that fell in the waste basket are back in 0.4.4, I can retire 0.2.x and 0.3.x. So I'm expecting to keep 0.4.x going as it-is today, and add some new features, but will fork it off to a 0.5.x and re-enable encryption so that I can continue on that. I'm keeping mindful that there is at least 1 other person who'd like the encryption, so I'll be sure to make sure you know when I've pushed out the branch. So far I've been running the encryption version off a raspberry pi machine to test out the theory of it actually working

I haven't checked out the new audit results. I like encfs but I realized years ago that it has some issues -- issues I witnessed myself, that I was also able to later find documented concerns brought up. Issues I witnessed pertains to the fact that identical content will have the same encrypted result, which could assist someone intent on decrypting your stuff a way to at least figure out what your data resembles. I'm not relying on encfs for anything secret or ultra-private, nor would I, especially when storing in the cloud.
I am new to Kodi and just got the Nexus player. I was able to install Kodi through the ES File Transfer but now I need to install the gdrive addon so that I can access my movies stored online. Can someone please help me with what I have to do with the .zip file after I download it? I saved it to google drive but when I got into Kodi, I clicked on install from .zip and but could not locate the file. Thank you for any suggestions.
Does anyone have problem playing from STRM files after the 0.4.4 updates?

Playing files by navigating to addons > gdrive > "filename" works perfectly but playing from STRM files doesn't seem to work.

Here's my log file:
20:36:53 T:5268 NOTICE: ES: Client from 192.168.10.147 timed out
20:36:55 T:3964 ERROR: CCurlFile::Stat - Failed: Timeout was reached(28) for https://doc-0k-ak-docs.googleusercontent...dows+NT%29
20:36:55 T:3964 NOTICE: DVDPlayer: Opening: https://doc-0k-ak-docs.googleusercontent...dows+NT%29
20:36:55 T:3964 WARNING: CDVDMessageQueue(player):Tongueut MSGQ_NOT_INITIALIZED
20:36:55 T:4984 NOTICE: Thread DVDPlayer start, auto delete: false
20:36:55 T:4984 NOTICE: Creating InputStream
20:36:56 T:4984 ERROR: CCurlFile::FillBuffer - Failed: HTTP response code said error(22)
20:36:56 T:4984 NOTICE: CCurlFile::FillBuffer - Reconnect, (re)try 1
20:36:56 T:4984 ERROR: CCurlFile::FillBuffer - Failed: HTTP response code said error(22)
20:36:56 T:4984 ERROR: CCurlFile::CReadState::Connect, didn't get any data from stream.
20:36:56 T:4984 ERROR: XFILE::CFileCache::Open - failed to open source <https://doc-0k-ak-docs.googleusercontent.com/docs/securesc/jdg6hqscnfsi6djh5dciaujhhdmbs1aa/togkf7d7uvjngqjjcbnrn17jvt8qu833/1416888000000/17626528541190258464/17626528541190258464/0B_SAaYR5oz1MdkoxYTJhTHozX00?h=01763372981872383526&amp;e=download&amp;gd=true|GData-Version=3.0&Authorization=GoogleLogin+auth%3DDQAAABgBAACrEnaOtZb8BTiOoQodIxMD3hRqyMLmvLBE_VNHO121Q1JXHgq5uAk2UGqY_lW6pCv7mJ_4JZT6fOWl0SqrBjtnJToeGzlqjt5vgbMbHPxrdQEW1KCzf_MbkznYR0z9o0wacVTCXl-36yP0ChNDh6uwPYxVGF-_Q5XmzYjURA5OgWs8aqzlaK4PFkJG5qyYr3XqVhOB1pDiglsMdQ2-MxYImTCIwKQ8xa7mUpSZPwvN0nKIgp-qZ3075zbj5TfBNcP9H76URFhH751EVWXsTp_HqJyryy-7ZTpMlrGi1vhnqoy73048b2LjoG0HjC0z-EQjBPWOqNEXs11d5-AtiFUIoDvi3hueWuY9cY36fY6JBM_yANJlvyRsjiDqopVE_5Y&User-Agent=Mozilla%2F4.0+%28compatible%3B+MSIE+5.5%3B+Windows+NT%29>
20:36:56 T:4984 ERROR: CDVDPlayer::OpenInputStream - error opening [https://doc-0k-ak-docs.googleusercontent...dows+NT%29]
20:36:56 T:4984 NOTICE: CDVDPlayer::OnExit()
20:36:56 T:4984 NOTICE: CDVDPlayer::OnExit() deleting input stream
20:36:56 T:3964 ERROR: Playlist Player: skipping unplayable item: 0, path [plugin://plugin.video.gdrive/?mode=playvideo&title=Mulan.1998.1080p.BluRay.x264.anoXmous.mp4]
20:36:56 T:3964 NOTICE: CDVDPlayer::CloseFile()
20:36:56 T:3964 NOTICE: DVDPlayer: waiting for threads to exit
20:36:56 T:3964 NOTICE: DVDPlayer: finished waiting
20:36:56 T:3964 NOTICE: CDVDPlayer::CloseFile()
20:36:56 T:3964 NOTICE: DVDPlayer: waiting for threads to exit
20:36:56 T:3964 NOTICE: DVDPlayer: finished waiting
20:37:03 T:4652 NOTICE: Thread VideoInfoScanner start, auto delete: false
Nevermind, if I change the mode from "playvide" to "streamVideo," then the video file will play just fine.
(2014-11-25, 08:39)madcow84 Wrote: [ -> ]Nevermind, if I change the mode from "playvide" to "streamVideo," then the video file will play just fine.

I'll investigate. The playvideo is supposed to still work, for backward compatibility reasons. The recent changes to incorporate the disk cache is what is likely causing the break. Disk cache doesn't factor in for streamvideo.