[bkiziuk]

Hi,

I use some code that copies subtitles from location (in this case network share) to local storage, process it, and copies result back to network share.
The original code looks like this:

python:
if xbmcvfs.exists(srcFile):

    Log("copy_file: srcFile exists.")

if xbmcvfs.exists(dstFile):

    delete_file(dstFile)

else:

    Log("copy_file: dstFile does not exist.")

success = xbmcvfs.copy(srcFile, dstFile)

While it works 100% when copying from smb: share to special://temp, on my machines it happens that copying from special://temp back to smb: fails, and success flag is set to 0.

For debug purposes I changed the code to:

python:
filehandle = xbmcvfs.File(srcFile)

buffer = filehandle.read()

filehandle.close()

Log("File data read: " + str(buffer))

filehandle = xbmcvfs.File(dstFile, 'w')

result = filehandle.write(buffer)

filehandle.close()

Log("File data write result: " + str(result))

This code has the same problem, but as the result I can see that file is correctly read from special://temp, and on target smb: the file is created in this case, but its length is 0. More of it, the result is 1.
The problem is that this behavior is not consistent between tries. It works ~90% of the time on my smb: share - both from Libreelec HTPC and Linux.
One of users reports that on nfs: share the first piece of code does not work at all - always fails to copy file back to share.

As xbmcvfs class is some wrapper built on top of cpp low level functions - is there any way to check what is the exact reason that xbmcvfs.copy() function fails (more than just binary result)?

[ronie]

years ago i had similar problems, with either copying to or reading from (don't remember exactly) special://temp
i was adviced to avoid using special://temp, as it was kodi's "black hole".

so try to use another folder as a temporary storage. it's recommended anyway for addons to use their own subfolder under userdata/addon_data/ for saving data.

[bkiziuk]

Hi Ronie,
many thanks for your quick response. I reorganized the test code to use the addon's working dir as a storage. At the moment there is no final conclusion yet if it helped, but preliminary testing reveals that there can still be some problems and the root cause does not seem consistent. So anyway, I've been trying to find out a way of seeing why the copy operation fails in the first place. As I mentioned before, it is random, so it takes time to observe it. Do you think that there is a way to see what happens under the hood? I searched the forum and I haven't found any prior reports of issues with xbmcvfs operation, which would suggest that this can be environment specific.

[ronie]

apart from enabling debug logging in kodi and checking the logfile for clues, there isn't much you can do to get more info.

perhaps you could try if adding a bit of sleep inbetween the operations helps:

python:
filehandle = xbmcvfs.File(dstFile, 'w')

xbmc.sleep(100)

result = filehandle.write(buffer)

xbmc.sleep(100)

filehandle.close()

[bkiziuk]

Ok, many thanks. I will use your suggestions.