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.
(2016-03-11, 05:35)dmdsoftware Wrote: [ -> ]These fixes In v0.7.45
http://dmdsoftware.net/repository.ddurdl...0.7.45.zip

v0.7.45 (2016-03-10)
- fix search error when CLOUD_DB is enabled
- add support for subtitles .ass and .ssa
- add mkv and rmvb extension mapping in unknown file situation
v0.7.44 (2016-03-09)
- fix for playback of offline file
v0.7.43 (2016-03-08)
- CLOUD_DB: load data during listings (resume + play count)
- CLOUD_DB: fix resume points
- CLOUD_DB: STRM resume points
- CLOUD_DB: updated add to queue
- drop Brazil language file
We have a winner!!! With 0.7.45 caching works once more.

And DSPlayer works too, with caching.

Yes, if keeping the "keep downloading when user stopped" option activated, even doing strange things like stopping, resuming, seeking, appears to work in a relatively good way.

The only problem I see is that if one uses cache, seeking ahead doesn't work, sending you back to Kodi's GUI while the download keeps on. If one doesn't use cache, seeking ahead works just fine.
DSPlayer keeps on not working without caching (but from what I rememember you saying, it's due to the missing authentication headers that you are trying to work in through the cloudDB thing).

So... basically just seeking with cache activated has "problems", if you want look into those (and if they're solvable).
(2016-03-11, 09:23)dabinn Wrote: [ -> ]
(2016-03-11, 05:35)dmdsoftware Wrote: [ -> ]
(2016-03-10, 07:54)dabinn Wrote: [ -> ]Hi,
I tried to find the cause from source code.
If I added file types (e.g. 'mkv', 'rmvb') in file 'gdrive_api2.py', The video files will be shown and played in KODI correctly.
Code:
# entry is a video
elif ((fileExtension.lower() == '' or fileExtension.lower() not in ('','sub')) and (resourceType == 'application/vnd.google-apps.video' or 'video' in resourceType or fileExtension.lower() in ('ts','mkv','rmvb')) and contentType in (0,1,2,4,7)):

I guess maybe the 'resourceType' are not right, in this case file extension is need for recognizing the video files.

(2016-03-10, 13:34)dabinn Wrote: [ -> ]Does the addon supports 'ass' & 'ssa' subtitle ?
When I rename the '.ass' file extension to '.srt' in google drive, the ass file will be loaded and correctly displayed with the subtitle effects.
But I cannot get these subtitle loaded without rename them to srt.


These fixes In v0.7.45
http://dmdsoftware.net/repository.ddurdl...0.7.45.zip

v0.7.45 (2016-03-10)
- fix search error when CLOUD_DB is enabled
- add support for subtitles .ass and .ssa
- add mkv and rmvb extension mapping in unknown file situation
v0.7.44 (2016-03-09)
- fix for playback of offline file
v0.7.43 (2016-03-08)
- CLOUD_DB: load data during listings (resume + play count)
- CLOUD_DB: fix resume points
- CLOUD_DB: STRM resume points
- CLOUD_DB: updated add to queue
- drop Brazil language file

Hi,
Something is wrong with .ass subtitle in v0.7.45.
Click on a video, after the 'Choose a stream' dialog, screen stopped at 'Bufering... 100%' for several minutes. (KODI was not freeze, but it will crash if I hit stop button at this moment)
I also test video files with idx/sub subtitle, same situation. Only srt subtitle is OK.

If I know how to print/output debug message from the python code, I may able to help debugging this.


--
Update:
I still don't know why xbmc.log('debug string', xbmc.LOGERROR) did not update my kodi.log.
Finally I have setup the pydev debugger, and will try to trace the subtitle issue.

To activate the debugger, you can add the following two lines to your settings.xml

<setting id="remote_debugger" value="true" />
<setting id="remote_debugger_host" value="localhost" />
(2016-03-11, 13:30)ashlar Wrote: [ -> ]
(2016-03-11, 05:35)dmdsoftware Wrote: [ -> ]These fixes In v0.7.45
http://dmdsoftware.net/repository.ddurdl...0.7.45.zip

v0.7.45 (2016-03-10)
- fix search error when CLOUD_DB is enabled
- add support for subtitles .ass and .ssa
- add mkv and rmvb extension mapping in unknown file situation
v0.7.44 (2016-03-09)
- fix for playback of offline file
v0.7.43 (2016-03-08)
- CLOUD_DB: load data during listings (resume + play count)
- CLOUD_DB: fix resume points
- CLOUD_DB: STRM resume points
- CLOUD_DB: updated add to queue
- drop Brazil language file
We have a winner!!! With 0.7.45 caching works once more.

And DSPlayer works too, with caching.

Yes, if keeping the "keep downloading when user stopped" option activated, even doing strange things like stopping, resuming, seeking, appears to work in a relatively good way.

The only problem I see is that if one uses cache, seeking ahead doesn't work, sending you back to Kodi's GUI while the download keeps on. If one doesn't use cache, seeking ahead works just fine.
DSPlayer keeps on not working without caching (but from what I rememember you saying, it's due to the missing authentication headers that you are trying to work in through the cloudDB thing).

So... basically just seeking with cache activated has "problems", if you want look into those (and if they're solvable).

Good to hear.

The DSPlayer for non-cache, I've opened an issue so I can track when it gets implemented - https://github.com/ddurdle/GDrive-for-KODI/issues/73 It's a bit tricky as it requires a creation of a Google App script to perform the workaround which should work, in theory.
(2016-03-11, 07:29)v.koutensky Wrote: [ -> ]Any luck with that default sorting for music? I can play music through video, but anyway.
I was unable to find any change.

Caching problem seems to be fixed, everything works well even when playing bigger flac files.

Vit

It'll be in todays. I never had time to add the new options to the setting screen.
(2016-03-11, 14:33)dmdsoftware Wrote: [ -> ]The DSPlayer for non-cache, I've opened an issue so I can track when it gets implemented - https://github.com/ddurdle/GDrive-for-KODI/issues/73 It's a bit tricky as it requires a creation of a Google App script to perform the workaround which should work, in theory.
Cool. Thanks for working on this!

And bear in mind seeking not working from cache (maybe there's no solution, I haven't the slightest idea about this... I seem to remember it was possible to ask for a file with an offset, which is probably what you already do when not caching, but maybe it's not possible when downloading).
(2016-03-11, 07:29)v.koutensky Wrote: [ -> ]Any luck with that default sorting for music? I can play music through video, but anyway.
I was unable to find any change.

Caching problem seems to be fixed, everything works well even when playing bigger flac files.

Vit

I can't figure out how to fix the music sort. It doesn't seem to care what the setting it set at, it always sorts in some random order until you force it to sort.
(2016-03-11, 17:44)ashlar Wrote: [ -> ]
(2016-03-11, 14:33)dmdsoftware Wrote: [ -> ]The DSPlayer for non-cache, I've opened an issue so I can track when it gets implemented - https://github.com/ddurdle/GDrive-for-KODI/issues/73 It's a bit tricky as it requires a creation of a Google App script to perform the workaround which should work, in theory.
Cool. Thanks for working on this!

And bear in mind seeking not working from cache (maybe there's no solution, I haven't the slightest idea about this... I seem to remember it was possible to ask for a file with an offset, which is probably what you already do when not caching, but maybe it's not possible when downloading).

https://github.com/ddurdle/GDrive-for-KODI/issues/74
(2016-03-11, 14:23)dmdsoftware Wrote: [ -> ]
(2016-03-11, 09:23)dabinn Wrote: [ -> ]
(2016-03-11, 05:35)dmdsoftware Wrote: [ -> ]These fixes In v0.7.45
http://dmdsoftware.net/repository.ddurdl...0.7.45.zip

v0.7.45 (2016-03-10)
- fix search error when CLOUD_DB is enabled
- add support for subtitles .ass and .ssa
- add mkv and rmvb extension mapping in unknown file situation
v0.7.44 (2016-03-09)
- fix for playback of offline file
v0.7.43 (2016-03-08)
- CLOUD_DB: load data during listings (resume + play count)
- CLOUD_DB: fix resume points
- CLOUD_DB: STRM resume points
- CLOUD_DB: updated add to queue
- drop Brazil language file

Hi,
Something is wrong with .ass subtitle in v0.7.45.
Click on a video, after the 'Choose a stream' dialog, screen stopped at 'Bufering... 100%' for several minutes. (KODI was not freeze, but it will crash if I hit stop button at this moment)
I also test video files with idx/sub subtitle, same situation. Only srt subtitle is OK.

If I know how to print/output debug message from the python code, I may able to help debugging this.


--
Update:
I still don't know why xbmc.log('debug string', xbmc.LOGERROR) did not update my kodi.log.
Finally I have setup the pydev debugger, and will try to trace the subtitle issue.

To activate the debugger, you can add the following two lines to your settings.xml

<setting id="remote_debugger" value="true" />
<setting id="remote_debugger_host" value="localhost" />

Hi,
I am still testing and tracing the code, some foundings here:
* The sub/ass loading freeze issue
I fount this is not cause by ass file type, but the amount of subtitle files in the same directory.
In function cache.setSRT(), file title did not pass to service.getSRT(). So that the service.getSRT() always returns all the subtitle file, no mater their filename matches the video file or not. (Is this by design?)
If cachePath was not set, each subttile file url will cause a 10 second timeout(approx.) to load.
(each generate an error message like :
14:22:30 T:7224 ERROR: CCurlFile::Stat - Failed: Timeout was reached(28) for https://doc-14-c4-docs.googleusercontent...34rgexxxxx...)
For example, a directory with TV series EP01~15, there will be 15 subtitles read, and takes 150 seconds waiting timeout.

* Wrong subtitle
When I test with cachePath set, wrong subtitle is displayed when playing TV series.

* Chinese subtitle filename massed up
In default.py, after 'files = cache.getSRT(service)'
file = file.decode('unicode-escape')
file = file.encode('utf-8')
These causes Chinese subtitle filename unable to load.


-------------
Update:
I have successfully fixed the subtitle issue by passing the title string to service.getSRT() and querying "title contains 'xxxx'" in google api.
All subtitles are displayed correctly, but I need more test to ensure there is no side effect.

I don't know how to commit code, so I paste the code I modified here:
In default.py:
Code:
cache.setSRT(service, title)
In cache.py
Code:
def setSRT(self, service, title):
....
srt = service.getSRT(title, self.package.folder.id)
...
srt = service.getSRT(title, self.package.folder.id)

In gdrive_api2.py
Code:
def getSRT(self, title, folderid):
...
        q='';
        # search in directory
        if folderid != False:
            q = q + "'"+str(folderid)+"' in parents"

        # search for title
        if title != False:
            title = os.path.splitext(title)[0]
            encodedTitle = re.sub(' ', '+', title)
            if q!='':
                q = q+" and "
            q = q + "title contains '"+title+"'"

        url = url + "?" + urllib.urlencode({'q':q})
(2016-03-12, 10:10)dabinn Wrote: [ -> ]
(2016-03-11, 14:23)dmdsoftware Wrote: [ -> ]
(2016-03-11, 09:23)dabinn Wrote: [ -> ]Hi,
Something is wrong with .ass subtitle in v0.7.45.
Click on a video, after the 'Choose a stream' dialog, screen stopped at 'Bufering... 100%' for several minutes. (KODI was not freeze, but it will crash if I hit stop button at this moment)
I also test video files with idx/sub subtitle, same situation. Only srt subtitle is OK.

If I know how to print/output debug message from the python code, I may able to help debugging this.


--
Update:
I still don't know why xbmc.log('debug string', xbmc.LOGERROR) did not update my kodi.log.
Finally I have setup the pydev debugger, and will try to trace the subtitle issue.

To activate the debugger, you can add the following two lines to your settings.xml

<setting id="remote_debugger" value="true" />
<setting id="remote_debugger_host" value="localhost" />

Hi,
I am still testing and tracing the code, some foundings here:
* The sub/ass loading freeze issue
I fount this is not cause by ass file type, but the amount of subtitle files in the same directory.
In function cache.setSRT(), file title did not pass to service.getSRT(). So that the service.getSRT() always returns all the subtitle file, no mater their filename matches the video file or not. (Is this by design?)
If cachePath was not set, each subttile file url will cause a 10 second timeout(approx.) to load.
(each generate an error message like :
14:22:30 T:7224 ERROR: CCurlFile::Stat - Failed: Timeout was reached(28) for https://doc-14-c4-docs.googleusercontent...34rgexxxxx...)
For example, a directory with TV series EP01~15, there will be 15 subtitles read, and takes 150 seconds waiting timeout.

* Wrong subtitle
When I test with cachePath set, wrong subtitle is displayed when playing TV series.

* Chinese subtitle filename massed up
In default.py, after 'files = cache.getSRT(service)'
file = file.decode('unicode-escape')
file = file.encode('utf-8')
These causes Chinese subtitle filename unable to load.


-------------
Update:
I have successfully fixed the subtitle issue by passing the title string to service.getSRT() and querying "title contains 'xxxx'" in google api.
All subtitles are displayed correctly, but I need more test to ensure there is no side effect.

I don't know how to commit code, so I paste the code I modified here:
In default.py:
Code:
cache.setSRT(service, title)
In cache.py
Code:
def setSRT(self, service, title):
....
srt = service.getSRT(title, self.package.folder.id)
...
srt = service.getSRT(title, self.package.folder.id)

In gdrive_api2.py
Code:
def getSRT(self, title, folderid):
...
        q='';
        # search in directory
        if folderid != False:
            q = q + "'"+str(folderid)+"' in parents"

        # search for title
        if title != False:
            title = os.path.splitext(title)[0]
            encodedTitle = re.sub(' ', '+', title)
            #url = url + "?q=title+contains+'" + str(encodedTitle) + "'"
            q = q + " and title contains '"+title+"'"

        url = url + "?" + urllib.urlencode({'q':q})

It sounds like you have the load srt from same directory enabled in the settings. It was meant to search and load subtitles when the user doesn't have the title of the SRT the same name as the video.

So I need to rethink things a bit.

There are the following situations that need to be satisfied:

1) videofile.mp4 with videofile.*.srt (1 video per directory)
2) videofile.mp4 with language.srt (1 video per directory)
3) videofile.series.mp4 with videofile.series.*.srt (multiple videos)
4) videofile.series.mp4 with language.series.*.srt (multiple videos)
5) videofile.mp4 with videofile.*.srt in a different directory

The current solution works 1,2,3,5 but you need to toggle a setting (switch between 1/3/5 and 2) otherwise 3 and 4 will cause severe issues. Your solution will work with 1 and 3.

I think I really need a solution similar to yours that will drop the need for the user to toggle a setting to change the behaviour.

1. search all srt in the directory then sub-search for title.*.srt, if match, load
2. if no match in 1, and there is only 1 srt, load
3. if no match in 1 but there are multiple srt, user prompt to select
4. if no srt returned in 1, research all srt with title across account, if match, load

I think that will handle 1)-5) situations. Thoughts?

The reason for the decoding was unicode characters would appear as squares.

edit:
I realize now that I somehow dropped the logic that switches between the search for title vs search for all srt in folder (setting: srt_folder). I don't know how that happened.
(2016-03-12, 10:10)dabinn Wrote: [ -> ]
(2016-03-11, 14:23)dmdsoftware Wrote: [ -> ]
(2016-03-11, 09:23)dabinn Wrote: [ -> ]Hi,
Something is wrong with .ass subtitle in v0.7.45.
Click on a video, after the 'Choose a stream' dialog, screen stopped at 'Bufering... 100%' for several minutes. (KODI was not freeze, but it will crash if I hit stop button at this moment)
I also test video files with idx/sub subtitle, same situation. Only srt subtitle is OK.

If I know how to print/output debug message from the python code, I may able to help debugging this.


--
Update:
I still don't know why xbmc.log('debug string', xbmc.LOGERROR) did not update my kodi.log.
Finally I have setup the pydev debugger, and will try to trace the subtitle issue.

To activate the debugger, you can add the following two lines to your settings.xml

<setting id="remote_debugger" value="true" />
<setting id="remote_debugger_host" value="localhost" />

Hi,
I am still testing and tracing the code, some foundings here:
* The sub/ass loading freeze issue
I fount this is not cause by ass file type, but the amount of subtitle files in the same directory.
In function cache.setSRT(), file title did not pass to service.getSRT(). So that the service.getSRT() always returns all the subtitle file, no mater their filename matches the video file or not. (Is this by design?)
If cachePath was not set, each subttile file url will cause a 10 second timeout(approx.) to load.
(each generate an error message like :
14:22:30 T:7224 ERROR: CCurlFile::Stat - Failed: Timeout was reached(28) for https://doc-14-c4-docs.googleusercontent...34rgexxxxx...)
For example, a directory with TV series EP01~15, there will be 15 subtitles read, and takes 150 seconds waiting timeout.

* Wrong subtitle
When I test with cachePath set, wrong subtitle is displayed when playing TV series.

* Chinese subtitle filename massed up
In default.py, after 'files = cache.getSRT(service)'
file = file.decode('unicode-escape')
file = file.encode('utf-8')
These causes Chinese subtitle filename unable to load.


-------------
Update:
I have successfully fixed the subtitle issue by passing the title string to service.getSRT() and querying "title contains 'xxxx'" in google api.
All subtitles are displayed correctly, but I need more test to ensure there is no side effect.

I don't know how to commit code, so I paste the code I modified here:
In default.py:
Code:
cache.setSRT(service, title)
In cache.py
Code:
def setSRT(self, service, title):
....
srt = service.getSRT(title, self.package.folder.id)
...
srt = service.getSRT(title, self.package.folder.id)

In gdrive_api2.py
Code:
def getSRT(self, title, folderid):
...
        q='';
        # search in directory
        if folderid != False:
            q = q + "'"+str(folderid)+"' in parents"

        # search for title
        if title != False:
            title = os.path.splitext(title)[0]
            encodedTitle = re.sub(' ', '+', title)
            #url = url + "?q=title+contains+'" + str(encodedTitle) + "'"
            q = q + " and title contains '"+title+"'"

        url = url + "?" + urllib.urlencode({'q':q})


Does it actually work? urllib.urlencode encoding the 'folderid' results in a error 400 Bad Request for me when I tested

edit:
nm, got it working

I merged your changes and came up with this:

PHP Code:
# merge contribution by dabinn
        
''
        
# search in current directory
        
if package.folder is not None and (package.folder.id != False or package.folder.id != ''):

            
"'"+str(package.folder.id)+"' in parents"

        
# search for title
        
if package.file is not None and (package.file.title != False or package.file.title != ''):
            
title os.path.splitext(package.file.title)[0]
            if 
!= '':
                
' and '
            
"title contains '" str(title) + "'"

        
url url "?" urllib.urlencode({'q':q}) 

Still need to work on this to work in all the cases. Only works in the one case.
(2016-03-12, 15:55)dmdsoftware Wrote: [ -> ]
(2016-03-12, 10:10)dabinn Wrote: [ -> ]
(2016-03-11, 14:23)dmdsoftware Wrote: [ -> ]To activate the debugger, you can add the following two lines to your settings.xml

<setting id="remote_debugger" value="true" />
<setting id="remote_debugger_host" value="localhost" />

Hi,
I am still testing and tracing the code, some foundings here:
* The sub/ass loading freeze issue
I fount this is not cause by ass file type, but the amount of subtitle files in the same directory.
In function cache.setSRT(), file title did not pass to service.getSRT(). So that the service.getSRT() always returns all the subtitle file, no mater their filename matches the video file or not. (Is this by design?)
If cachePath was not set, each subttile file url will cause a 10 second timeout(approx.) to load.
(each generate an error message like :
14:22:30 T:7224 ERROR: CCurlFile::Stat - Failed: Timeout was reached(28) for https://doc-14-c4-docs.googleusercontent...34rgexxxxx...)
For example, a directory with TV series EP01~15, there will be 15 subtitles read, and takes 150 seconds waiting timeout.

* Wrong subtitle
When I test with cachePath set, wrong subtitle is displayed when playing TV series.

* Chinese subtitle filename massed up
In default.py, after 'files = cache.getSRT(service)'
file = file.decode('unicode-escape')
file = file.encode('utf-8')
These causes Chinese subtitle filename unable to load.


-------------
Update:
I have successfully fixed the subtitle issue by passing the title string to service.getSRT() and querying "title contains 'xxxx'" in google api.
All subtitles are displayed correctly, but I need more test to ensure there is no side effect.

I don't know how to commit code, so I paste the code I modified here:
In default.py:
Code:
cache.setSRT(service, title)
In cache.py
Code:
def setSRT(self, service, title):
....
srt = service.getSRT(title, self.package.folder.id)
...
srt = service.getSRT(title, self.package.folder.id)

In gdrive_api2.py
Code:
def getSRT(self, title, folderid):
...
        q='';
        # search in directory
        if folderid != False:
            q = q + "'"+str(folderid)+"' in parents"

        # search for title
        if title != False:
            title = os.path.splitext(title)[0]
            encodedTitle = re.sub(' ', '+', title)
            #url = url + "?q=title+contains+'" + str(encodedTitle) + "'"
            q = q + " and title contains '"+title+"'"

        url = url + "?" + urllib.urlencode({'q':q})

It sounds like you have the load srt from same directory enabled in the settings. It was meant to search and load subtitles when the user doesn't have the title of the SRT the same name as the video.

So I need to rethink things a bit.

There are the following situations that need to be satisfied:

1) videofile.mp4 with videofile.*.srt (1 video per directory)
2) videofile.mp4 with language.srt (1 video per directory)
3) videofile.series.mp4 with videofile.series.*.srt (multiple videos)
4) videofile.series.mp4 with language.series.*.srt (multiple videos)
5) videofile.mp4 with videofile.*.srt in a different directory

The current solution works 1,2,3,5 but you need to toggle a setting (switch between 1/3/5 and 2) otherwise 3 and 4 will cause severe issues. Your solution will work with 1 and 3.

I think I really need a solution similar to yours that will drop the need for the user to toggle a setting to change the behaviour.

1. search all srt in the directory then sub-search for title.*.srt, if match, load
2. if no match in 1, and there is only 1 srt, load
3. if no match in 1 but there are multiple srt, user prompt to select
4. if no srt returned in 1, research all srt with title across account, if match, load

I think that will handle 1)-5) situations. Thoughts?

The reason for the decoding was unicode characters would appear as squares.

edit:
I realize now that I somehow dropped the logic that switches between the search for title vs search for all srt in folder (setting: srt_folder). I don't know how that happened.

In my experience, most video player handle subtitle file like 1) and 3)
1) videofile.mp4 with videofile.*.srt (1 video per directory)
3) videofile.series.mp4 with videofile.series.*.srt (multiple videos)
and they may additionally provide an ability to select any subtitle from any directory.

I think your 1~4 step is very good. I may consider not to search title across account, although it is fast with google API in my test( maybe they have built index or something). But I am still afraid if user had lots lots of file in google drive, it may takes too long time to wait for response. Searching in a user specified str_folder should be safer.
(2016-03-12, 20:07)dabinn Wrote: [ -> ]
(2016-03-12, 15:55)dmdsoftware Wrote: [ -> ]
(2016-03-12, 10:10)dabinn Wrote: [ -> ]Hi,
I am still testing and tracing the code, some foundings here:
* The sub/ass loading freeze issue
I fount this is not cause by ass file type, but the amount of subtitle files in the same directory.
In function cache.setSRT(), file title did not pass to service.getSRT(). So that the service.getSRT() always returns all the subtitle file, no mater their filename matches the video file or not. (Is this by design?)
If cachePath was not set, each subttile file url will cause a 10 second timeout(approx.) to load.
(each generate an error message like :
14:22:30 T:7224 ERROR: CCurlFile::Stat - Failed: Timeout was reached(28) for https://doc-14-c4-docs.googleusercontent...34rgexxxxx...)
For example, a directory with TV series EP01~15, there will be 15 subtitles read, and takes 150 seconds waiting timeout.

* Wrong subtitle
When I test with cachePath set, wrong subtitle is displayed when playing TV series.

* Chinese subtitle filename massed up
In default.py, after 'files = cache.getSRT(service)'
file = file.decode('unicode-escape')
file = file.encode('utf-8')
These causes Chinese subtitle filename unable to load.


-------------
Update:
I have successfully fixed the subtitle issue by passing the title string to service.getSRT() and querying "title contains 'xxxx'" in google api.
All subtitles are displayed correctly, but I need more test to ensure there is no side effect.

I don't know how to commit code, so I paste the code I modified here:
In default.py:
Code:
cache.setSRT(service, title)
In cache.py
Code:
def setSRT(self, service, title):
....
srt = service.getSRT(title, self.package.folder.id)
...
srt = service.getSRT(title, self.package.folder.id)

In gdrive_api2.py
Code:
def getSRT(self, title, folderid):
...
        q='';
        # search in directory
        if folderid != False:
            q = q + "'"+str(folderid)+"' in parents"

        # search for title
        if title != False:
            title = os.path.splitext(title)[0]
            encodedTitle = re.sub(' ', '+', title)
            #url = url + "?q=title+contains+'" + str(encodedTitle) + "'"
            q = q + " and title contains '"+title+"'"

        url = url + "?" + urllib.urlencode({'q':q})

It sounds like you have the load srt from same directory enabled in the settings. It was meant to search and load subtitles when the user doesn't have the title of the SRT the same name as the video.

So I need to rethink things a bit.

There are the following situations that need to be satisfied:

1) videofile.mp4 with videofile.*.srt (1 video per directory)
2) videofile.mp4 with language.srt (1 video per directory)
3) videofile.series.mp4 with videofile.series.*.srt (multiple videos)
4) videofile.series.mp4 with language.series.*.srt (multiple videos)
5) videofile.mp4 with videofile.*.srt in a different directory

The current solution works 1,2,3,5 but you need to toggle a setting (switch between 1/3/5 and 2) otherwise 3 and 4 will cause severe issues. Your solution will work with 1 and 3.

I think I really need a solution similar to yours that will drop the need for the user to toggle a setting to change the behaviour.

1. search all srt in the directory then sub-search for title.*.srt, if match, load
2. if no match in 1, and there is only 1 srt, load
3. if no match in 1 but there are multiple srt, user prompt to select
4. if no srt returned in 1, research all srt with title across account, if match, load

I think that will handle 1)-5) situations. Thoughts?

The reason for the decoding was unicode characters would appear as squares.

edit:
I realize now that I somehow dropped the logic that switches between the search for title vs search for all srt in folder (setting: srt_folder). I don't know how that happened.

In my experience, most video player handle subtitle file like 1) and 3)
1) videofile.mp4 with videofile.*.srt (1 video per directory)
3) videofile.series.mp4 with videofile.series.*.srt (multiple videos)
and they may additionally provide an ability to select any subtitle from any directory.

I think your 1~4 step is very good. I may consider not to search title across account, although it is fast with google API in my test( maybe they have built index or something). But I am still afraid if user had lots lots of file in google drive, it may takes too long time to wait for response. Searching in a user specified str_folder should be safer.

I had requests for 2 and 4, so that's why they got implemented. #1 and #3 suffice for every movie/tv show I have.

Searching across the account for a folder or file is same effectiveness with Google API. Only issue is if you have such a fuzzy search that returns hundreds or thousands of results. I will abort after 10 results.

Anything else about the double-byte SRT? Did you want me to have a look. I need a copy of the SRT. I don't need a copy of the video, just the SRT.
(2016-03-12, 20:07)dabinn Wrote: [ -> ]
(2016-03-12, 15:55)dmdsoftware Wrote: [ -> ]
(2016-03-12, 10:10)dabinn Wrote: [ -> ]Hi,
I am still testing and tracing the code, some foundings here:
* The sub/ass loading freeze issue
I fount this is not cause by ass file type, but the amount of subtitle files in the same directory.
In function cache.setSRT(), file title did not pass to service.getSRT(). So that the service.getSRT() always returns all the subtitle file, no mater their filename matches the video file or not. (Is this by design?)
If cachePath was not set, each subttile file url will cause a 10 second timeout(approx.) to load.
(each generate an error message like :
14:22:30 T:7224 ERROR: CCurlFile::Stat - Failed: Timeout was reached(28) for https://doc-14-c4-docs.googleusercontent...34rgexxxxx...)
For example, a directory with TV series EP01~15, there will be 15 subtitles read, and takes 150 seconds waiting timeout.

* Wrong subtitle
When I test with cachePath set, wrong subtitle is displayed when playing TV series.

* Chinese subtitle filename massed up
In default.py, after 'files = cache.getSRT(service)'
file = file.decode('unicode-escape')
file = file.encode('utf-8')
These causes Chinese subtitle filename unable to load.


-------------
Update:
I have successfully fixed the subtitle issue by passing the title string to service.getSRT() and querying "title contains 'xxxx'" in google api.
All subtitles are displayed correctly, but I need more test to ensure there is no side effect.

I don't know how to commit code, so I paste the code I modified here:
In default.py:
Code:
cache.setSRT(service, title)
In cache.py
Code:
def setSRT(self, service, title):
....
srt = service.getSRT(title, self.package.folder.id)
...
srt = service.getSRT(title, self.package.folder.id)

In gdrive_api2.py
Code:
def getSRT(self, title, folderid):
...
        q='';
        # search in directory
        if folderid != False:
            q = q + "'"+str(folderid)+"' in parents"

        # search for title
        if title != False:
            title = os.path.splitext(title)[0]
            encodedTitle = re.sub(' ', '+', title)
            #url = url + "?q=title+contains+'" + str(encodedTitle) + "'"
            q = q + " and title contains '"+title+"'"

        url = url + "?" + urllib.urlencode({'q':q})

It sounds like you have the load srt from same directory enabled in the settings. It was meant to search and load subtitles when the user doesn't have the title of the SRT the same name as the video.

So I need to rethink things a bit.

There are the following situations that need to be satisfied:

1) videofile.mp4 with videofile.*.srt (1 video per directory)
2) videofile.mp4 with language.srt (1 video per directory)
3) videofile.series.mp4 with videofile.series.*.srt (multiple videos)
4) videofile.series.mp4 with language.series.*.srt (multiple videos)
5) videofile.mp4 with videofile.*.srt in a different directory

The current solution works 1,2,3,5 but you need to toggle a setting (switch between 1/3/5 and 2) otherwise 3 and 4 will cause severe issues. Your solution will work with 1 and 3.

I think I really need a solution similar to yours that will drop the need for the user to toggle a setting to change the behaviour.

1. search all srt in the directory then sub-search for title.*.srt, if match, load
2. if no match in 1, and there is only 1 srt, load
3. if no match in 1 but there are multiple srt, user prompt to select
4. if no srt returned in 1, research all srt with title across account, if match, load

I think that will handle 1)-5) situations. Thoughts?

The reason for the decoding was unicode characters would appear as squares.

edit:
I realize now that I somehow dropped the logic that switches between the search for title vs search for all srt in folder (setting: srt_folder). I don't know how that happened.

In my experience, most video player handle subtitle file like 1) and 3)
1) videofile.mp4 with videofile.*.srt (1 video per directory)
3) videofile.series.mp4 with videofile.series.*.srt (multiple videos)
and they may additionally provide an ability to select any subtitle from any directory.

I think your 1~4 step is very good. I may consider not to search title across account, although it is fast with google API in my test( maybe they have built index or something). But I am still afraid if user had lots lots of file in google drive, it may takes too long time to wait for response. Searching in a user specified str_folder should be safer.


Can you test out v0.7.46? I've implemented behaviour for 1-5 without having to toggle a setting. I tested them with a few test cases and looks good.

http://dmdsoftware.net/repository.ddurdl...0.7.46.zip
v0.7.46 (2016-03-14)
- SRT - merge contribution by dabinn (dealing with TV series in a single directory)
- add ability to toggle caching of thumbnails and SRT on/off
- fix cache of SRT
- rework SRT logic
1) list of files (multiple languages) from the same folder that exactly match the title of the video
2) list of candidate files that are from the same folder but don't match the title of the video (if exceeds 4, ask user to select -- likely TV series or folder containing multiple movies)
(2016-03-14, 17:07)dmdsoftware Wrote: [ -> ]
(2016-03-12, 20:07)dabinn Wrote: [ -> ]
(2016-03-12, 15:55)dmdsoftware Wrote: [ -> ]It sounds like you have the load srt from same directory enabled in the settings. It was meant to search and load subtitles when the user doesn't have the title of the SRT the same name as the video.

So I need to rethink things a bit.

There are the following situations that need to be satisfied:

1) videofile.mp4 with videofile.*.srt (1 video per directory)
2) videofile.mp4 with language.srt (1 video per directory)
3) videofile.series.mp4 with videofile.series.*.srt (multiple videos)
4) videofile.series.mp4 with language.series.*.srt (multiple videos)
5) videofile.mp4 with videofile.*.srt in a different directory

The current solution works 1,2,3,5 but you need to toggle a setting (switch between 1/3/5 and 2) otherwise 3 and 4 will cause severe issues. Your solution will work with 1 and 3.

I think I really need a solution similar to yours that will drop the need for the user to toggle a setting to change the behaviour.

1. search all srt in the directory then sub-search for title.*.srt, if match, load
2. if no match in 1, and there is only 1 srt, load
3. if no match in 1 but there are multiple srt, user prompt to select
4. if no srt returned in 1, research all srt with title across account, if match, load

I think that will handle 1)-5) situations. Thoughts?

The reason for the decoding was unicode characters would appear as squares.

edit:
I realize now that I somehow dropped the logic that switches between the search for title vs search for all srt in folder (setting: srt_folder). I don't know how that happened.

In my experience, most video player handle subtitle file like 1) and 3)
1) videofile.mp4 with videofile.*.srt (1 video per directory)
3) videofile.series.mp4 with videofile.series.*.srt (multiple videos)
and they may additionally provide an ability to select any subtitle from any directory.

I think your 1~4 step is very good. I may consider not to search title across account, although it is fast with google API in my test( maybe they have built index or something). But I am still afraid if user had lots lots of file in google drive, it may takes too long time to wait for response. Searching in a user specified str_folder should be safer.


Can you test out v0.7.46? I've implemented behaviour for 1-5 without having to toggle a setting. I tested them with a few test cases and looks good.

http://dmdsoftware.net/repository.ddurdl...0.7.46.zip
v0.7.46 (2016-03-14)
- SRT - merge contribution by dabinn (dealing with TV series in a single directory)
- add ability to toggle caching of thumbnails and SRT on/off
- fix cache of SRT
- rework SRT logic
1) list of files (multiple languages) from the same folder that exactly match the title of the video
2) list of candidate files that are from the same folder but don't match the title of the video (if exceeds 4, ask user to select -- likely TV series or folder containing multiple movies)

Many thanks, I will test 0.7.46 later today. Smile
I am still testing on Unicode file name issue (File name in Traditional Chinese, Simplified Chinese, Japanese). Something is strange but I am not very sure right now.
If you are interesting in this, here is an .ass subtitle file with 3 Chinese words in the file name.
https://drive.google.com/file/d/0B-IpAlZ...E2ZWc/view
(2016-03-15, 09:38)dabinn Wrote: [ -> ]
(2016-03-14, 17:07)dmdsoftware Wrote: [ -> ]
(2016-03-12, 20:07)dabinn Wrote: [ -> ]In my experience, most video player handle subtitle file like 1) and 3)
1) videofile.mp4 with videofile.*.srt (1 video per directory)
3) videofile.series.mp4 with videofile.series.*.srt (multiple videos)
and they may additionally provide an ability to select any subtitle from any directory.

I think your 1~4 step is very good. I may consider not to search title across account, although it is fast with google API in my test( maybe they have built index or something). But I am still afraid if user had lots lots of file in google drive, it may takes too long time to wait for response. Searching in a user specified str_folder should be safer.


Can you test out v0.7.46? I've implemented behaviour for 1-5 without having to toggle a setting. I tested them with a few test cases and looks good.

http://dmdsoftware.net/repository.ddurdl...0.7.46.zip
v0.7.46 (2016-03-14)
- SRT - merge contribution by dabinn (dealing with TV series in a single directory)
- add ability to toggle caching of thumbnails and SRT on/off
- fix cache of SRT
- rework SRT logic
1) list of files (multiple languages) from the same folder that exactly match the title of the video
2) list of candidate files that are from the same folder but don't match the title of the video (if exceeds 4, ask user to select -- likely TV series or folder containing multiple movies)

Many thanks, I will test 0.7.46 later today. Smile
I am still testing on Unicode file name issue (File name in Traditional Chinese, Simplified Chinese, Japanese). Something is strange but I am not very sure right now.
If you are interesting in this, here is an .ass subtitle file with 3 Chinese words in the file name.
https://drive.google.com/file/d/0B-IpAlZ...E2ZWc/view

thanks, I will test with the subtitle