(2014-11-14, 03:32)ashlar Wrote: [ -> ]I've tried all possible settings but still it doesn't appear to download as fast as it does from the browser. Nowhere near, really. Maybe the web app of the browser opens multiple connections?
Also, thinking it might have to do with Kodi or the unstable release 0.4.0, I uninstalled everything (including user folder) and reinstalled. Now the plugin refuses to work, throwing out this error in logs:
Code:
02:27:24 T:17848 ERROR: EXCEPTION Thrown (PythonToCppException) : -->Python callback/script returned the following error<--
- NOTE: IGNORING THIS CAN LEAD TO MEMORY LEAKS!
Error Type: <type 'exceptions.ImportError'>
Error Contents: No module named Crypto.Random
Traceback (most recent call last):
File "C:\Users\ashlar\AppData\Roaming\Kodi\addons\XBMC-gdrive-unstable\default.py", line 19, in <module>
from resources.lib import gdrive
File "C:\Users\ashlar\AppData\Roaming\Kodi\addons\XBMC-gdrive-unstable\resources\lib\gdrive.py", line 25, in <module>
from resources.lib import encryption
File "C:\Users\ashlar\AppData\Roaming\Kodi\addons\XBMC-gdrive-unstable\resources\lib\encryption.py", line 4, in <module>
import Crypto.Random
ImportError: No module named Crypto.Random
-->End of Python script error report<--
02:27:24 T:17848 INFO: Python script stopped
02:27:24 T:17848 DEBUG: Thread LanguageInvoker 17848 terminating
02:27:24 T:3600 DEBUG: XFILE::CPluginDirectory::WaitOnScriptResult - plugin exited prematurely - terminating
Your KODI doesn't support encryption so use < 0.4.0 version.
http://dmdsoftware.net/repository.ddurdl...-0.3.3.zip
But is it supposed to be like this? I downloaded the Kodi software from the official source, I didn't compile it myself or anything.
Also, what about speeds? Am I the only one seeing slow downloads from gDrive, when from the browser it goes ten times as fast?
I also wanted to point out this to you, in case it might help in resuming files and skippin forward and backward:
https://forums.plex.tv/index.php/topic/1...ntry765197
This guy is adapting FuseFS to Google Drive and regarding streaming mentions this (which I guess it refers to the gDrive API, but I might be wrong):
"The streaming bit is quite simple, when you download the file, just add in your header options the "Range: bytes=x-y" and it will download chunks of it."
(2014-11-14, 16:45)ashlar Wrote: [ -> ]But is it supposed to be like this? I downloaded the Kodi software from the official source, I didn't compile it myself or anything.
Also, what about speeds? Am I the only one seeing slow downloads from gDrive, when from the browser it goes ten times as fast?
I also wanted to point out this to you, in case it might help in resuming files and skippin forward and backward:
https://forums.plex.tv/index.php/topic/1...ntry765197
This guy is adapting FuseFS to Google Drive and regarding streaming mentions this (which I guess it refers to the gDrive API, but I might be wrong):
"The streaming bit is quite simple, when you download the file, just add in your header options the "Range: bytes=x-y" and it will download chunks of it."
0.4.0 is in the unstable branch because it has some experimental code that I'm working on for advanced features such as encryption. The out-of-box KODI doesn't support encryption, but it can be installed separately.
Yes, it is the Google Drive/Docs API that one uses to interact with Google Drive via a plugin.
For downloading we hand over the URL to the source file to KODI to playback, so if it has speed issues, its because of the way it buffers the file. Streaming / Transcoding mode is done the same way, but it is passed a Transcoded Google Drive stream at the designated resolution and quality. I would expect the streaming one to be more limited in speed.
There is that Disk mode that I have in options that today just uses Memory mode, which passes it to KODI to playback. The intention of the Disk mode will be download the file through the plugin and initiate the playback directly from within the plugin (bypassing KODI altogether). It sounds like this is what you really would need to test to ensure the maximum speed is reached. The current versions just default back to Memory even if you select Disk, as I am still doing testing on it. If you want to test this out to report back if the speed issue is gone, I can generate you a special custom version with the Disk mode enabled.
Let me know.
Definitely available to test whatever you want to shoot in my direction. I'm trying with 0.3.3 and the behaviour is strange, with the advancedsettings.xml I posted before, the cache increases (with O I can see it increasing) but it keeps on downloading at around 10Mbps, a tenth of the theoretical limit (one that is nearly reached when downloading from the webapp for gDrive).
But yes, do send me stuff to test. More than glad to help, if I can.
Edit: reading what you wrote I tried one more thing. Set the plugin to memory cache and changed the network settings to this:
Code:
<advancedsettings>
<network>
<cachemembuffersize>629145600</cachemembuffersize>
<buffermode>1</buffermode>
<readbufferfactor>10000</readbufferfactor>
</network>
</advancedsettings>
But still no significant improvement. I'm playing back a 5Mbps file and the cache is increasing steadily (this file plays perfectly, I want to be clear) but it seems, even looking at task manager (Windows 8.1 here) that bandwidth download still oscillates from 11 to 2Mbps, as if something is "stopping it" from reaching full speed. From what you wrote, with 600MB of cache available, I'd expect that to be filled up as fast as possible. But this still doesn't seem to be the case.
Edit 2: I reverted to Gotham 13.2 and with the above settings speed stays the same. But I've noticed another thing. There's no way of seeking, even when fully cached. I mean, I'm now watching am episode of a tv show. I have the full 600MB cached, but I can't skip ahead, not even 30 seconds. It doesn't make any sense...
(2014-11-14, 17:04)ashlar Wrote: [ -> ]Definitely available to test whatever you want to shoot in my direction. I'm trying with 0.3.3 and the behaviour is strange, with the advancedsettings.xml I posted before, the cache increases (with O I can see it increasing) but it keeps on downloading at around 10Mbps, a tenth of the theoretical limit (one that is nearly reached when downloading from the webapp for gDrive).
But yes, do send me stuff to test. More than glad to help, if I can.
You do bring a good point about buffering in KODI. I noticed in the past with KODI running on Raspberry Pi, streaming through HTTPS randomly fails, or even worse, causes the device to reboot. It was all around the way it buffers. In general, I find the buffering usually useful.
I started working on this "Disk" caching as a way to work around the streaming issue with HTTPS on the Raspberry Pi. I never even thought about it being useful for other things --- focused on getting streams to work, not bothering to check if they are being hampered by buffering/caching issues.
I'll ping you sometime today with a build for you to test. It'll be a 0.4.1 (or something like that), where I disable the encryption logic and enable the disk caching.
Great! Thanks. Looking forward to it.
(2014-11-14, 18:38)ashlar Wrote: [ -> ]Great! Thanks. Looking forward to it.
Here it is ->
http://dmdsoftware.net/repository.ddurdl...-0.4.1.zip
Encryption was disabled. Tested on a vanilla Kodi 14 without encryption, and works.
For the testing, make sure you select Disk Cache as Playback Type. Two parameters apply, location to store cache files and chunk size.
Please note that for this testing, the download code only works when playing videos directly from the plugin (streamurl API calls not supported atm).
Hi! Installed this new version, configured it with different chunk sizes but the result was always the same.
Basically, the file starts, it starts getting cached (as an .mp4 file, although it was an .mkv, but that doesn't seem to be the problem, as XBMC seems to parse it correctly) and it stops just as soon as playback starts.
I had a look at the log file and the crucial point seems to be this:
Code:
11:26:37 T:9104 DEBUG: CDVDPlayerAudio:: Discontinuity2 - was:2032486.394418, should be:2003383.045888, error:-29103.348530
11:26:38 T:9104 DEBUG: CDVDPlayerAudio - CDVDMsg::GENERAL_EOF
11:26:38 T:9104 WARNING: CDVDMessageQueue(audio)::Get - asked for new data packet, with nothing available
11:26:39 T:6940 WARNING: CDVDMessageQueue(video)::Get - asked for new data packet, with nothing available
11:26:39 T:10044 INFO: CDVDPlayer::Process - eof reading from demuxer
11:26:39 T:10044 NOTICE: CDVDPlayer::OnExit()
11:26:39 T:10044 NOTICE: DVDPlayer: eof, waiting for queues to empty
Basically, it reaches end of file as soon as playback starts (I tried playing the cache file with MPC-HC and the same seems to happen).
The good news is: download speed is what is supposed to be, as fast as it can basically. Extra bad news is: even though the file stops playing, download keeps going. You need to exit XBMC to make it stop.
Full log here:
http://pastebin.com/AfuF6aNf
Also, a strange thing: I uploaded a big file (it's a rip of my Planet Earth BluRay collection, 9GB with an average bitrate of about 23Mbps) to check download performance, anticipating your new build. Now, the plugin doesn't see the file. It sees the directory I created. I went to the web interface and, in fact, the file hadn't been processed yet. But now it's been processed and the plugin still doesn't see it.
EDIT: after 10 minutes or so that the file had been processed by Drive, it appeared in the plugin as well.
(2014-11-15, 12:44)ashlar Wrote: [ -> ]Hi! Installed this new version, configured it with different chunk sizes but the result was always the same.
Basically, the file starts, it starts getting cached (as an .mp4 file, although it was an .mkv, but that doesn't seem to be the problem, as XBMC seems to parse it correctly) and it stops just as soon as playback starts.
I had a look at the log file and the crucial point seems to be this:Code:
11:26:37 T:9104 DEBUG: CDVDPlayerAudio:: Discontinuity2 - was:2032486.394418, should be:2003383.045888, error:-29103.348530
11:26:38 T:9104 DEBUG: CDVDPlayerAudio - CDVDMsg::GENERAL_EOF
11:26:38 T:9104 WARNING: CDVDMessageQueue(audio)::Get - asked for new data packet, with nothing available
11:26:39 T:6940 WARNING: CDVDMessageQueue(video)::Get - asked for new data packet, with nothing available
11:26:39 T:10044 INFO: CDVDPlayer::Process - eof reading from demuxer
11:26:39 T:10044 NOTICE: CDVDPlayer::OnExit()
11:26:39 T:10044 NOTICE: DVDPlayer: eof, waiting for queues to empty
Basically, it reaches end of file as soon as playback starts (I tried playing the cache file with MPC-HC and the same seems to happen).
The good news is: download speed is what is supposed to be, as fast as it can basically. Extra bad news is: even though the file stops playing, download keeps going. You need to exit XBMC to make it stop.
Full log here: http://pastebin.com/AfuF6aNf
Also, a strange thing: I uploaded a big file (it's a rip of my Planet Earth BluRay collection, 9GB with an average bitrate of about 23Mbps) to check download performance, anticipating your new build. Now, the plugin doesn't see the file. It sees the directory I created. I went to the web interface and, in fact, the file hadn't been processed yet. But now it's been processed and the plugin still doesn't see it.
EDIT: after 10 minutes or so that the file had been processed by Drive, it appeared in the plugin as well.
What was the size of the file you tested (in the first case)? The progress bar in the app only reflects the progress on the first 100 chunks, before it starts playback. It should continue to download the rest of the file after playback starts (or fails). You should see the filesize continuing to increase even if there is no activity going on. Then again, it could be the case where the plugin is erroring and stopping. When I tested, even if I caused the playback or plugin to error out, the thread downloading the video would continue.
I'm looking at the log you provided and doing some other testing on other files, but my first guess is the file was probably a large file and not enough of it was downloaded before the playback started. I should base the decision on how large the file is. That or there is an issue with MKV files.
Ignoring the progress bar, etc, are you seeing download speed issues when the file is downloading via the network tools? It is bypassing XBMC's buffering and caching controls.
As you guessed, the extension on the cache file doesn't matter. Matter of fact, most of my media files don't have extensions. Playback through normal means doesn't rely on the file type extension. With that said, I tested with MP4, AVI and MPG files of various types.
In your second case, while the file is in processing, it won't show up in the plugin as it's not classified as playback capable. I will probably start listing them perhaps with a denotation that it'll only playback in original format until processed.
EDIT: The termination because running for more than 5 seconds is a little disturbing. If the file indeed stopped downloading, that might be the case. I assume your file is of large size?
The file is 7.9 GB, more or less.
I repeat the test right now, let me see... yup, it stops playback, going out to the plugin screen (with the files list), with no error message. Meanwhile, download keeps on going, at speeds averaging 95Mbps, more or less (hence, maxing out bandwidth for all practical purposes). When I exit XBMC, the download stops.
I now try with a much smaller file, let me see... nope, nothing changes, it still stops. This time after 7 seconds of playback (for a 750MB file). If I leave it alone, in background the download proceeds (at the fastest speed possible, as above) but once finished... its size is slightly different from the file I can download from the webapp. And when played back with MPC-HC (the cache.mp4 file, I mean), it exhibits the same behaviour. It stops at the same exact point where XBMC stops.
Tell me if there are more experiments or specific logs you might need.
Edit: I just double checked by downloading the same files I was trying to play from withing the plugin. Downloading them through the webapp produces exact replicas of the local files, perfectly playable, with no problem. In any case, the download speed is most definitely solved. Now, well, all the rest
Again, I'll help however I can.
(2014-11-15, 15:58)dmdsoftware Wrote: [ -> ] (2014-11-15, 12:44)ashlar Wrote: [ -> ]Hi! Installed this new version, configured it with different chunk sizes but the result was always the same.
Basically, the file starts, it starts getting cached (as an .mp4 file, although it was an .mkv, but that doesn't seem to be the problem, as XBMC seems to parse it correctly) and it stops just as soon as playback starts.
I had a look at the log file and the crucial point seems to be this:Code:
11:26:37 T:9104 DEBUG: CDVDPlayerAudio:: Discontinuity2 - was:2032486.394418, should be:2003383.045888, error:-29103.348530
11:26:38 T:9104 DEBUG: CDVDPlayerAudio - CDVDMsg::GENERAL_EOF
11:26:38 T:9104 WARNING: CDVDMessageQueue(audio)::Get - asked for new data packet, with nothing available
11:26:39 T:6940 WARNING: CDVDMessageQueue(video)::Get - asked for new data packet, with nothing available
11:26:39 T:10044 INFO: CDVDPlayer::Process - eof reading from demuxer
11:26:39 T:10044 NOTICE: CDVDPlayer::OnExit()
11:26:39 T:10044 NOTICE: DVDPlayer: eof, waiting for queues to empty
Basically, it reaches end of file as soon as playback starts (I tried playing the cache file with MPC-HC and the same seems to happen).
The good news is: download speed is what is supposed to be, as fast as it can basically. Extra bad news is: even though the file stops playing, download keeps going. You need to exit XBMC to make it stop.
Full log here: http://pastebin.com/AfuF6aNf
Also, a strange thing: I uploaded a big file (it's a rip of my Planet Earth BluRay collection, 9GB with an average bitrate of about 23Mbps) to check download performance, anticipating your new build. Now, the plugin doesn't see the file. It sees the directory I created. I went to the web interface and, in fact, the file hadn't been processed yet. But now it's been processed and the plugin still doesn't see it.
EDIT: after 10 minutes or so that the file had been processed by Drive, it appeared in the plugin as well.
What was the size of the file you tested (in the first case)? The progress bar in the app only reflects the progress on the first 100 chunks, before it starts playback. It should continue to download the rest of the file after playback starts (or fails). You should see the filesize continuing to increase even if there is no activity going on. Then again, it could be the case where the plugin is erroring and stopping. When I tested, even if I caused the playback or plugin to error out, the thread downloading the video would continue.
I'm looking at the log you provided and doing some other testing on other files, but my first guess is the file was probably a large file and not enough of it was downloaded before the playback started. I should base the decision on how large the file is. That or there is an issue with MKV files.
Ignoring the progress bar, etc, are you seeing download speed issues when the file is downloading via the network tools? It is bypassing XBMC's buffering and caching controls.
As you guessed, the extension on the cache file doesn't matter. Matter of fact, most of my media files don't have extensions. Playback through normal means doesn't rely on the file type extension. With that said, I tested with MP4, AVI and MPG files of various types.
In your second case, while the file is in processing, it won't show up in the plugin as it's not classified as playback capable. I will probably start listing them perhaps with a denotation that it'll only playback in original format until processed.
EDIT: The termination because running for more than 5 seconds is a little disturbing. If the file indeed stopped downloading, that might be the case. I assume your file is of large size?
Followup:
I tried a 1080p MKV (it was only actually a 43 second video).
With the initial setting, I could see the video flash on the screen for a split second before returning to to XBMC. Changing the counter to 400 from 100, the playback started and lasted for about 3 seconds before closing. I could see from the playback bar that about 25 seconds of video was ready to playback. Continuing to dig, but there might be an issue with MKV files. I continue to test non-MKV and haven't encountered anything else with the same issue.
One of the features I was going to add was a "download then watch". That would definitely work with the MKV files.
(2014-11-15, 16:31)ashlar Wrote: [ -> ]The file is 7.9 GB, more or less.
I repeat the test right now, let me see... yup, it stops playback, going out to the plugin screen (with the files list), with no error message. Meanwhile, download keeps on going, at speeds averaging 95Mbps, more or less (hence, maxing out bandwidth for all practical purposes). When I exit XBMC, the download stops.
I now try with a much smaller file, let me see... nope, nothing changes, it still stops. This time after 7 seconds of playback (for a 750MB file). If I leave it alone, in background the download proceeds (at the fastest speed possible, as above) but once finished... its size is slightly different from the file I can download from the webapp. And when played back with MPC-HC (the cache.mp4 file, I mean), it exhibits the same behaviour. It stops at the same exact point where XBMC stops.
Tell me if there are more experiments or specific logs you might need.
Edit: I just double checked by downloading the same files I was trying to play from withing the plugin. Downloading them through the webapp produces exact replicas of the local files, perfectly playable, with no problem. In any case, the download speed is most definitely solved. Now, well, all the rest Again, I'll help however I can.
Ah, yes, playback of the cache file demonstrates an issue I see. I think I know the issue now. One of the packets must be not getting saved properly, and MKV files can't tolerate that. Because my full downloaded MKV file fails at the same part even when played back through through Files. I guess AVI/MP4/MPEG files are more tolerable.
Should be easy to track down and fix
Ok, I believe I solved the corruption issue. After the whole file is downloaded, I can play it back.
When it playback through the plugin, it stops about 5 seconds in because my internet isn't fast enough for 1080p 5.1 chanel mkv. But if I immediately go to Files and manually run the file, while the plugin continues to download the rest of the file, I can playback, and it doesn't stop until it has run past the amount already downloaded (when buffer runs out). I believe if my internet was fast enough, the initial playback would continue.
Changes:
http://dmdsoftware.net/repository.ddurdl...-0.4.2.zip
Good! The strange thing is that, with the previous version (bandwidth problems notwithstanding), the same files played back with no problem.
Also worth mentioning, considering what you wrote, I am having a similar problem with an .mp4 file. Playback doesn't even start, download goes through but, again, unplayable through MPC-HC too. The file is an mp4 file, 350MB in size.
Log:
http://pastebin.com/04fMZVGy Mediainfo for the mp4 file:
http://pastebin.com/d9TVFE3M
Edit: see you have a new version. Downloading right now. Will report back ASAP.
I confirm that the file is downloaded correctly. But XBMC still doesn't play it back. It doesn't even start. I mean, it starts but it doesn't even arrive to the point where you see a frame of the video. It stays on the user interface. Meanwhile, in background, the file is being downloaded at great speeds and yes, I'm now playing it back through MPC-HC while it's still downloading, with no problem.
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.