[dmdsoftware]

Hello,

This add-on has come a long way, great work thus far. I just thought I would report a possible bug regarding saving STRMs. (running latest testing version) I was able to save a folder of a tv show to my local drive, However, when I try to save it to a networked PC's HDD using sbm:// I get a script error and only the root folder is copied over. If I manually drag them over to the network PC's HDD it works fine.

Not sure if the below helps or not.

Code:

10:38:41 T:6888   ERROR: EXCEPTION Thrown (PythonToCppException) : -->Python callback/script returned the following error<--
                                             - NOTE: IGNORING THIS CAN LEAD TO MEMORY LEAKS!
                                            Error Type: <type 'exceptions.AttributeError'>
                                            Error Contents: 'NoneType' object has no attribute 'title'
                                            Traceback (most recent call last):
                                              File "C:\Users\Kodi-Server\AppData\Roaming\Kodi\addons\plugin.video.gdrive-testing\default.py", line 362, in <module>
                                                service.buildSTRM(path + '/'+title,folderID)
                                              File "C:\Users\Kodi-Server\AppData\Roaming\Kodi\addons\plugin.video.gdrive-testing\resources\lib\cloudservice.py", line 122, in buildSTRM
                                                url = self.PLUGIN_URL+'?mode=video&title='+item.file.title+'&filename='+item.file.id
                                            AttributeError: 'NoneType' object has no attribute 'title'
                                            -->End of Python script error report<--
10:38:41 T:5360   DEBUG: ------ Window Init (DialogKaiToast.xml) ------
10:38:41 T:6888    INFO: Python script stopped
10:38:41 T:6888   DEBUG: Thread LanguageInvoker 6888 terminating

Thanks,

As warned earlier, SMB /NAS isn't supported right now. Prior versions of the plugin disallowed selecting a path that was a non-local or special path. Because I wanted to allow users to save their path to Settings, it is possible for a user to select a non-local or special path, but because the STRM files are created using os modules, those modules don't have access to XBMC filesystems, so it fails.

Future version will allow you to generate them directly to these paths if I can work around the bugs in xbmcvfs. If the bugs can't be worked around, I'll disallow users from selecting the paths.

Edit: My warning was actually in the Hive thread. I forgot to warn users in this thread not to try using NAS locations. My bad.
http://forum.kodi.tv/showthread.php?tid=...pid1884620

---

Actually I got it to work but not in a way that I expected. All I had to do was change the file name then the error no longer appeared. After that I could change the file name back to the original and it would still work.

Not sure why but yeah just reporting that.

I was on the latest stable 0.4.8 and it was a MKV file.

The majority of playback issues is the video is unprocessable by google (in that case, the streams will not be available but "original" playback will work -- "original" would be the only choice presented on stream selection screen). The other most common reason is something not nice in the title for the file. Because the title is passed along the way until the streams are fetched, if there is bad character or unicode issue with the title, then playback will fail. This issue is elevated in the 0.5+ release coming up as resourceID is being used instead.

The video had been long processed by Google for months actually and the stream worked fine yet the add-on would run into the error every time I tried playing it. Still changing the name to in my case "1", saving then renaming it back to the original title was enough to make it work.

I had the same error again on other video files shared to me. Doing what I did in the first problem did not work this time in that I could not rename it back to the same file name and have it work. However renaming to something without "+" kept in the title allowed it to work.

These errors are pretty strange to me but I'm looking forward to your newer versions that solve this.

+ are troublesome in a filename. They often represent spaces in URI. So if you tell the plugin to find my+movie, it passes "my+movie" to google, but google treats the + not as the literal, but as a space. I remove this ambiguity in 0.5+ by communicating resource IDs instead -- Title's become meaningless textual representations of your media file.