Edited by dlanor at Sat Nov 15, 2014 08:05 |
I'm sorry to report that in my recent tests I get exactly the same kind of result with SMBWrapper as I earlier got for XBMCWrapper.
There is now a long delay with spinning circle until 'MX Player' times out its access attempt and gives the message that it can't play the video.
This is surprising, as a number of people have described it as working with Gotham, but there must be some difference between their setups and mine.
One possible difference which comes to mind is that they may have had files stored in the base path for which the password was registered by XBMC, whereas my files always are in some subfolder beneath that level. If SMBWrapper checks folder match by precise match of the full string, then that is bound to fail. It needs to check that the registered path for a password is included as a leading string in the current access path, in which case that password should be used.
----- some tests later -----
Now I'm really confused, but positively surprised as well. After several tests with negative results I decided to make a test by defining a video source link for XMBC with video files at the top level (due to my suspicions above), and playing these through SMBWrapper + MXPlayer worked fine. But when I then started testing other files, not in that top folder but further beneath it, these too worked fine. But all files under the video source link defined earlier still fail every time, so that's very confusing. There's nothing wrong with the definitions or the passwords, as those files play fine if I remove the playercore file so XBMC plays them directly, so there must be something about them that doesn't work for SMBWrapper.
Best regards: dlanor