SMB mounts directly from XBMC for Mac OS X?

[imclumzy]

I have a standalone Xbox with XBMC that I map an SMB share on my Vantec NAS for all my videos. I figured I would be able to do the same from OSXBMC but and failing to mount it.

OSXBMC has an IP and is able to pull weather forecasts from my area so I know it's on the network. I haven't installed any scripts so I don't know if they work. But when I try to put in the details of my NAS (IP addy, share name, etc.) it can't connect to it.

Anyone else have any experience with this?

[d4rk]

The OSX port doesn't yet support samba shares (not natively at least). You can always mount the shares manually and then add it as a local share.

[Gamester17]

http://dn-0.com/xbmc-trac/wiki/FrequentlyAskedQuestions

How can I access my Windows shares through OSXBMC?

Currently, the direct access to Windows shares through OSXBMC does not work. Just mount the drive via SMB in OS X and then point OSXBMC to the local mount point.

[imclumzy]

Thanks all for the clarification. I haven't seen that FAQ site before and although I searched this forum, I will endeavor to dig a little deeper before posting.

Thanks again.

[eduo]

There are several things that should change when running XBMC as an app as opposed as it being, for all intents and purposes the GUI for the operating system that it is in an Xbox.

These are some things that should or could change when run as a standalone application:

- XBMC doesn't need to mount filesystems directly, as these can be managed by the local OS. Obviously this doesn't apply to virtual Filesystems.

- Preferences should be stored on the appropiate place, as well as metadata required by the application.

- Fullscreen should be a toggable setting, with a fullscreen resolution and a windowed resolution.

- Network, time, region, encoding, keyboard layout, etc. should be driven by the OS, not XBMC.

- Platform-specific video codecs and drivers should be supported (Quicktime in Mac, WM in Win)

- Proxy settings and html rendering engines, if necessary, should be taken from the OS.

There are probably others but these have hit me this week.

Options regarding the above should disappear or adapt when compiled to run as a standalone application, so as to not confuse users.

[Gamester17]

@eduo, XBMC is originally design to practically act the only GUI interface for an embedded operating-system (so more like a the operating-system itself then a standalone application), meaning it is expected to be the only window manager on that hardware, and thus all controls and settings needs to be available from the XBMC GUI. (OFF-TOPIC but understand that this is also why we plan to eventually release XBMC for Linux as a LiveCD/LiveUSB type of Embedded Linux distro making it boot directly to the XBMC on dedicated hardware with the XBMC GUI being the only interface to that Embedded Linux operating-system, so in practice making is work just as XBMC running as the boot dashboard on an Xbox).

However if you are a C++ programmer then know that patches are welcomed, with the correct implementation XBMC should be able to work both as a window manager (embedded application) and as a standalone application, the only difference would be be skin, (then you only need to 'hide' those settings/controls in the skin for XBMC as a standalone application and set it to use the operating-systems parameters when acting in that capacity).
http://xbmc.org/wiki/?title=Development_Notes

[eduo]

Gamester17: I know what XBMC is. I know what it expects and I know what hoops it's jumping through.

It's because I know that I find it weird that some of the things I mention already appear, greyed out, in the application-mode XBMC.

XBMC has decided to follow both paths and, considering its history, people expect top-of-the-line behaviour.

I might not have been clear, but I wasn't saying things should be taken out, only #IFDEF'd as the compiler knows when it's compiling for standalone execution.

I won't make this call as there are several ways this can be done (harcoded depending on compilation target or auto-selected by XBMC when it detects how it's running and where).

I really think this logic should be in the application, not the skin. This two-post exchange shows that this isn't a clear-cut decision either. I won't be submitting patches before OSXBMC runs smoothly (as for most it's aesthetic) and even then I'd be proposing a direction.

But, still, I thought it was worth mentioning it as it's something that jumps at you when you first run it.