search

robweber / xbmcbackup

Backup Addon for Kodi
MIT License
107 stars 48 forks source link

Cannot restore from SMB filesystem #227

Closed hyc closed 5 months ago

hyc commented 7 months ago

Describe the problem A clear and concise description of what the bug is.

Setting the remote dir to a a path on an SMB filesystem works, and Backup to that SMB path works. But restore always fails. The Log shows something about CreateLoader unable to recognize "-smb" protocol.

Platform and Kodi version What OS and Kodi version are you using? (Rpi, Android, etc) Android 12, Kodi 20.2

Link to Debug Log Please don't just post the whole thing here, use https://paste.kodi.tv https://paste.kodi.tv/ereraxalos

Markcoruk commented 5 months ago

Have the same problem backup to NAS works fine restore fails.

robweber commented 5 months ago

How are you setting the path - manual or browsing? I've tried replicating this on a network share using SMB locally and can't get the same result. It would help to have a full log. The very first lines of the Backup process should show the desired paths and these were missing from the one posted.

hyc commented 5 months ago

I'm not sure this bug report is valid any more. While the log shows all of those error messages, eventually the restore succeeds. It just seems to take a very long time with nothing happening, before it starts making progress. Perhaps it's initially bogged down by logging all of those failures. The log I uploaded was a complete log for the restore process. Do you need a log from making the backup?

The path in my case is smb://192.168.1.147/sambashare/KodiBak/

I browse to that, the smb://192.168.1.147/sambashare path is already known because I have other video and music folders there.

robweber commented 5 months ago

Thanks for the feedback. Wonder if this is a platform specific error? I wasn't able to recreate it but think I may have fixed it anyway. For historical reasons directories were prefixed with a dash during file scanning and then it was stripped during copy. I modified this so that now the meta data for the files contains a is_dir flag instead. I'm hoping wherever this was being fed into the file system during the copy operation will now be fixed.

I have a bit more testing to do but it's live as of this commit if you want to install a beta and test. I'll get it merged in to the addon repo once I'm confident it's all working.

Markcoruk commented 5 months ago

I tried again today and it worked. So it could of been just me it takes a bit of time to check the data but as the other user said works eventually.

robweber commented 5 months ago

I'm going to hazard a guess that the underlying file system was smart enough to just strip off the dash and proceed with the file operation as intended. The more I look at the code around the file copy methods I'm convinced this stemmed from adding the dash when walking the directory. It was just never stripped off again after that.

I think the modifications I made yesterday to flag directories in a more direct way will eliminate this. I'm going to flag this as fixed.