Hey there, new-ish kodi gdrive user here, I am guessing if dmdsoftware.net is down and giving me a "bandwidth limit exceeded error" the oauth2 authentication that I used will not work with the gdrive app as well. Is this correct? I'm sure its a common sense question, so thank you in advance for anyone that replies or answers
(2016-03-01, 04:32)cbr34567 Wrote: [ -> ]Hey there, new-ish kodi gdrive user here, I am guessing if dmdsoftware.net is down and giving me a "bandwidth limit exceeded error" the oauth2 authentication that I used will not work with the gdrive app as well. Is this correct? I'm sure its a common sense question, so thank you in advance for anyone that replies or answers
If you are still using dmdsoftware.net authentication type, you should switch to Google Apps authentication type. That has been the default for sometime now. Only in the early days of OAUTH2 authentication was dmdsoftware.net being used. You should be able to go to enroll account and follow the prompts. The URL directly to the google OAUTH2 is in the README file as well.
(2016-02-28, 01:13)ashlar Wrote: [ -> ]If you can access a Windows machine, this is the build http://forum.kodi.tv/showthread.php?pid=...pid2261017
Then you can decide whether to use DVDPlayer or DSPlayer with "Play using..." from the contextual menu.
Hi @
dmdsoftware
I've tried again playing without cache and it still failed (through DSPlayer). I give you the most detailed log I could think of (I added details for https/curl stuff, maybe it helps):
http://xbmclogs.com/pynewb6bb
If it's authentication headers I could look for a splitter/source filter that supports them under Windows. Unfortunately I'm completely ignorant on this point, I hope that "authentication headers" is sufficient to point me in the right direction.
(2016-03-01, 16:07)ashlar Wrote: [ -> ] (2016-02-28, 01:13)ashlar Wrote: [ -> ]If you can access a Windows machine, this is the build http://forum.kodi.tv/showthread.php?pid=...pid2261017
Then you can decide whether to use DVDPlayer or DSPlayer with "Play using..." from the contextual menu.
Hi @dmdsoftware
I've tried again playing without cache and it still failed (through DSPlayer). I give you the most detailed log I could think of (I added details for https/curl stuff, maybe it helps): http://xbmclogs.com/pynewb6bb
If it's authentication headers I could look for a splitter/source filter that supports them under Windows. Unfortunately I'm completely ignorant on this point, I hope that "authentication headers" is sufficient to point me in the right direction.
Does it fail with playback with cache (as with cache, authentication headers are not passed on as python does the downloading of the content)?
(2016-03-01, 16:09)dmdsoftware Wrote: [ -> ]Does it fail with playback with cache (as with cache, authentication headers are not passed on as python does the downloading of the content)?
Playing with cache works, but it then doesn't download fast enough from gDrive. To clarify: it works, it starts caching, it starts playback. Once playback starts, it appears not to be downloading as fast as it should (and could) and after a little while it drops back to the Kodi interfaces with the file downloading.
During the caching period I see bandwidth use in excess of 50Mbps. Once playback starts, it drops significantly... with just occasional peaks but insufficient to keep on playback. Which at a certain point, stops and goes back to Kodi with "downloading" in the top right corner. Also, when this happens, download speed does not pick up again but keeps this "pattern" of slow speeds (and in Kbps) and occasional spikes to 30Mbps.
And... well, I tried caching with regular DVDPlayer... it starts right but then it slows down and playback doesn't even start. With both players it cached about 350MB of a very big file. In both cases it slowed down after, DVDPlayer simply didn't start. DSPlayer started (playing what was in cache) and then exited once the cache was depleted.
Here it is, happening on DVDPlayer:
http://xbmclogs.com/pn0sgezqv
The only thing that works flawlessly is DVDPlayer with no cache use (using just the internal Kodi cache,
appropriately incremented).
And, by the way, I asked nevcariel (developer of LAV Filters, used by DSPlayer), this is what he had to say about authentication headers:
http://forum.doom9.org/showthread.php?p=...ost1759110
(2016-03-01, 17:19)ashlar Wrote: [ -> ] (2016-03-01, 16:09)dmdsoftware Wrote: [ -> ]Does it fail with playback with cache (as with cache, authentication headers are not passed on as python does the downloading of the content)?
Playing with cache works, but it then doesn't download fast enough from gDrive. To clarify: it works, it starts caching, it starts playback. Once playback starts, it appears not to be downloading as fast as it should (and could) and after a little while it drops back to the Kodi interfaces with the file downloading.
During the caching period I see bandwidth use in excess of 50Mbps. Once playback starts, it drops significantly... with just occasional peaks but insufficient to keep on playback. Which at a certain point, stops and goes back to Kodi with "downloading" in the top right corner. Also, when this happens, download speed does not pick up again but keeps this "pattern" of slow speeds (and in Kbps) and occasional spikes to 30Mbps.
And... well, I tried caching with regular DVDPlayer... it starts right but then it slows down and playback doesn't even start. With both players it cached about 350MB of a very big file. In both cases it slowed down after, DVDPlayer simply didn't start. DSPlayer started (playing what was in cache) and then exited once the cache was depleted.
Here it is, happening on DVDPlayer: http://xbmclogs.com/pn0sgezqv
The only thing that works flawlessly is DVDPlayer with no cache use (using just the internal Kodi cache, appropriately incremented).
And, by the way, I asked nevcariel (developer of LAV Filters, used by DSPlayer), this is what he had to say about authentication headers: http://forum.doom9.org/showthread.php?p=...ost1759110
I'll review your attached log to validate there are is no issue become encountered that shouldn't be.
In general, original streaming I moved to alt=media which proved to resolve "slowness" issues for a lot of users, as it tells Google you are a media player so stream it accordingly. Prior, I used it without, which tells Google to treat the download request as a regular download. Some users had issues maximizing their bandwidth with this method. I'm going to add an option to toggle it to see if that improves it for you. From my perspective I saw no speed changes between the two methods, but there were a number of users who reported issues with the original method that rejoiced with the change.
I don't have an account on doom9 and I'm having an issue trying to post to that thread. Can you post a clarification request?
"KODI allows passing along additional header information in a HTTP/HTTPS request by passing it along in the URL with a |. Such as a URL "https://www.google.ca|Authentication: Bearer 1234" which would attach Authentication: Bearer 1234 to the header of the request. Is there an equivalent way to pass long authentication information that can be appended to the header of the http request? See
http://forum.kodi.tv/showthread.php?tid=77500 -- note this has been implemented in KODI since v12"
Thank you. I'll try whatever further developments you'll post. In the meantime I have posted the clarification requested for nevcariel's attention.
I could work on a method that uses Google Apps to relay your credentials. Essentially, I could draft a Google Apps script that takes your authentication information over the URL and translate and submit the request in the proper form, to get around this issue with DSPlayer. Interested?
(2016-03-02, 15:27)dmdsoftware Wrote: [ -> ]I could work on a method that uses Google Apps to relay your credentials. Essentially, I could draft a Google Apps script that takes your authentication information over the URL and translate and submit the request in the proper form, to get around this issue with DSPlayer. Interested?
I am not sure I understand what you are suggesting but, as I said before, I'm available to test whatever you'll come up with. DSPlayer might not concern the majority of users, but it has its following of aficionados and, who knows, maybe in the future there will be other needs for this workaround.
Thanks!
(2016-03-02, 18:24)ashlar Wrote: [ -> ] (2016-03-02, 15:27)dmdsoftware Wrote: [ -> ]I could work on a method that uses Google Apps to relay your credentials. Essentially, I could draft a Google Apps script that takes your authentication information over the URL and translate and submit the request in the proper form, to get around this issue with DSPlayer. Interested?
I am not sure I understand what you are suggesting but, as I said before, I'm available to test whatever you'll come up with. DSPlayer might not concern the majority of users, but it has its following of aficionados and, who knows, maybe in the future there will be other needs for this workaround.
Thanks!
Speed on cache should be resolved in 0.7.39
http://dmdsoftware.net/repository.ddurdl...0.7.39.zip
v0.7.39 (2016-03-02)
- resolved speed issue with cache video files
- add logic to accomodate flexible CLOUD_DB columns
- CLOUD_DB addition: commands
@
dmdsoftware,
How are you feeling this days?
By the way I notice the addon isn't available in Kodi's repo, why?
(2016-03-03, 02:22)dmdsoftware Wrote: [ -> ]Speed on cache should be resolved in 0.7.39
http://dmdsoftware.net/repository.ddurdl...0.7.39.zip
v0.7.39 (2016-03-02)
- resolved speed issue with cache video files
- add logic to accomodate flexible CLOUD_DB columns
- CLOUD_DB addition: commands
I leave the DSPlayer issues aside for the moment, waiting for what you have in mind.
Tried this version with DVDPlayer and it works BUT... it seems not to be able to resume correctly (using cache, that is). If I play a video, it caches ahead. If I stop and then play it back, it recognizes it has stuff in cache and proceeds to use it. BUT it doesn't cache ahead anymore, with the result that it then exits from playback with no error or anything. It just exits. Even seeking ahead seems to cause similar problems. Let me know if you need logs or if it's something you can replicate on your side.
Bear in mind that, personally, I don't have need for caching. I have a 100Mbps connection and with no caching from the plugin everything works in DVDPlayer (not so in DSPlayer but I set that aside here). I just point out what comes from testing for others that might have slower connections.
(2016-03-03, 14:55)ashlar Wrote: [ -> ] (2016-03-03, 02:22)dmdsoftware Wrote: [ -> ]Speed on cache should be resolved in 0.7.39
http://dmdsoftware.net/repository.ddurdl...0.7.39.zip
v0.7.39 (2016-03-02)
- resolved speed issue with cache video files
- add logic to accomodate flexible CLOUD_DB columns
- CLOUD_DB addition: commands
I leave the DSPlayer issues aside for the moment, waiting for what you have in mind.
Tried this version with DVDPlayer and it works BUT... it seems not to be able to resume correctly (using cache, that is). If I play a video, it caches ahead. If I stop and then play it back, it recognizes it has stuff in cache and proceeds to use it. BUT it doesn't cache ahead anymore, with the result that it then exits from playback with no error or anything. It just exits. Even seeking ahead seems to cause similar problems. Let me know if you need logs or if it's something you can replicate on your side.
Bear in mind that, personally, I don't have need for caching. I have a 100Mbps connection and with no caching from the plugin everything works in DVDPlayer (not so in DSPlayer but I set that aside here). I just point out what comes from testing for others that might have slower connections.
Are you using the "continue downloading after player is user-stopped" in cache settings when it stops?