incognegro Wrote:I have one question about running xbmc on USB stick; Is there a way to edit source.xml to make a share that points to the xbmc folder no matter what the drive letter is? I tried changing the letter to the Q drive, because i thought it refers to the "home" folder. It doesn't seem to work that way, because if the drive letter changes the share disappears.Q is going to be removed at some point, so maybe you could submit a separate feature request for something like home:// to always be mapped to XBMC's application folder (the the XBMC.exe executable was executed from). That way you could map that in sources.xml in the future as well.
2008-09-04, 23:34
Gamester17 Wrote:Q is going to be removed at some point, so maybe you could submit a separate feature request for something like home:// to always be mapped to XBMC's application folder (the the XBMC.exe executable was executed from). That way you could map that in sources.xml in the future as well.
ok. ill post something in the feature request forums when i get home. Thanx for the help guys.
2008-09-05, 09:16
Gamester17 Wrote:Q is going to be removed at some point, so maybe you could submit a separate feature request for something like home:// to always be mapped to XBMC's application folder ...
Don't hold your breath ...
2009-09-28, 03:51
I have XBMC installed on my portable hard drive for use at friend's houses and such; the -p switch is happily storing all my settings in the right place, but when adding things to the media library, they're stored with the drive letter included, and this changes on each PC, so the library breaks.
As such, I think a virtual drive (similar to the existing special://home/ ) which refers to "whatever drive the current XBMC install is running on" would be very useful.
(In the meantime I'm trying to write a plugin to achieve the same effect, but that's being a pain, and needs a separate plugin for each of video / music / photos, and it seems painfully slow compared to accessing the filesystem directly...)
As such, I think a virtual drive (similar to the existing special://home/ ) which refers to "whatever drive the current XBMC install is running on" would be very useful.
(In the meantime I'm trying to write a plugin to achieve the same effect, but that's being a pain, and needs a separate plugin for each of video / music / photos, and it seems painfully slow compared to accessing the filesystem directly...)
2009-09-29, 22:45
I've made a patch to do this, and it seems to work, however it seems that other unrelated bits of XBMC are broken so I can't test... (possibly not "broken" so much as "sticking a SVN xbmc.exe into a 9.04 install isn't supposed to work in the first place"...)
http://svn.shishnet.org/patches/xbmc%20-%20xdrive.diff
This basically adds a "special://xdrive/" virtual path which maps to whichever drive XBMC is installed on, thus if you have an XBMC install on a portable hard drive alongside your media, then it can keep track of your media even when the drive letter changes (eg, when you plug the portable hard drive into somebody else's PC)
http://svn.shishnet.org/patches/xbmc%20-%20xdrive.diff
This basically adds a "special://xdrive/" virtual path which maps to whichever drive XBMC is installed on, thus if you have an XBMC install on a portable hard drive alongside your media, then it can keep track of your media even when the drive letter changes (eg, when you plug the portable hard drive into somebody else's PC)
2009-09-29, 22:58
Shish Wrote:I have XBMC installed on my portable hard drive for use at friend's houses and such; the -p switch is happily storing all my settings in the right place, but when adding things to the media library, they're stored with the drive letter included, and this changes on each PC, so the library breaks.
As such, I think a virtual drive (similar to the existing special://home/ ) which refers to "whatever drive the current XBMC install is running on" would be very useful.
(In the meantime I'm trying to write a plugin to achieve the same effect, but that's being a pain, and needs a separate plugin for each of video / music / photos, and it seems painfully slow compared to accessing the filesystem directly...)
I take it you're averse to using the Subst command?
Not ideal, but works perfectly for me
Although the best solution would be to use the 'Source' name and XBMC dynamically translates... thus allowing you to remap a source to anywhere without XMBC caring, or needing to update the database
2009-09-30, 02:42
Finally managed to get a release build + installer to work -- using the SVN data files instead of 9.04 ones, everything works \o/
> I take it you're averse to using the Subst command?
I ask if this is possible three times and get nothing; I spend a couple of days running windows, setting up a dev environment, and writing a patch, and /then/ somebody tells me there's a one-line command which has the same effect
Ho hum, at least having the dev setup ready makes my other ideas one step closer to happening...
My approach still works when the preferred drive letter is already claimed, but I'm not sure how often that'll happen in practice...
> I take it you're averse to using the Subst command?
I ask if this is possible three times and get nothing; I spend a couple of days running windows, setting up a dev environment, and writing a patch, and /then/ somebody tells me there's a one-line command which has the same effect
Ho hum, at least having the dev setup ready makes my other ideas one step closer to happening...My approach still works when the preferred drive letter is already claimed, but I'm not sure how often that'll happen in practice...
2009-09-30, 10:31
Shish Wrote:Finally managed to get a release build + installer to work -- using the SVN data files instead of 9.04 ones, everything works \o/
> I take it you're averse to using the Subst command?
I ask if this is possible three times and get nothing; I spend a couple of days running windows, setting up a dev environment, and writing a patch, and /then/ somebody tells me there's a one-line command which has the same effect
My approach still works when the preferred drive letter is already claimed, but I'm not sure how often that'll happen in practice...
You could also consider 'Mount Points' or symbolic links (only for NTFS on Windows, Linux and Mac have similar options)... you would only need ONE drive letter for the entire system
2009-09-30, 19:56
Although the -p switch is fabulous....
Would it not be advantageous for XBMC to check if there is a 'userdata' folder in the XBMC directory, and if so, assume portable mode?
This would then negate the need for users to create shortcuts to facilitate the -p switch.
If it's argued that some users might want to have an esoteric setup that has a portable, and 'user' based userdata folder, then a command line switch would be more apt to select the desired mode.
This way 90% of user using EITHER user, or portable modes would be satisfied without requiring any command line switch.
Would it not be advantageous for XBMC to check if there is a 'userdata' folder in the XBMC directory, and if so, assume portable mode?
This would then negate the need for users to create shortcuts to facilitate the -p switch.
If it's argued that some users might want to have an esoteric setup that has a portable, and 'user' based userdata folder, then a command line switch would be more apt to select the desired mode.
This way 90% of user using EITHER user, or portable modes would be satisfied without requiring any command line switch.
2009-09-30, 19:57
hell no. in this case devs before users
1) userdata sits in svn and i don't want crap dumped in there that svn can complain about
2) we'd have to ask every single user that wants to do something in userdata for a log just as we don't know who built their shit and how
3) a user could easily screw himself over by e.g. stuffing one file in the app folder and boom! your stuff that sits in the os profile older is ignored.
1) userdata sits in svn and i don't want crap dumped in there that svn can complain about
2) we'd have to ask every single user that wants to do something in userdata for a log just as we don't know who built their shit and how
3) a user could easily screw himself over by e.g. stuffing one file in the app folder and boom! your stuff that sits in the os profile older is ignored.
2009-09-30, 20:16
spiff Wrote:hell no. in this case devs before users
1) userdata sits in svn and i don't want crap dumped in there that svn can complain about
2) we'd have to ask every single user that wants to do something in userdata for a log just as we don't know who built their shit and how
3) a user could easily screw himself over by e.g. stuffing one file in the app folder and boom! your stuff that sits in the os profile older is ignored.
Ah, my mistake entirely, what I should have said was...
If the userdata\database folder exists! (you're quite right, I'd forgotten the SVN had userdata)
If this folder exists, they clearly they've elected to use portable mode..or is this a false assumption?
2009-09-30, 20:36
spiff Wrote:that's betteryeah, that could be doable
And doable means....
install Visual Studio, check out a bunch of code, build it, run it, modify a line or two, compile it, add the missing semicolon, build again, run it, and check it back in? ;-)
It's not wonder you guys never get time to WATCH these movies!
2009-09-30, 20:43
actually testing eats much more time than writing the code. i speak the language fluently i'm just not sure what i want to state all the time 
i'm just not sure what i want to state all the time
