-
Notifications
You must be signed in to change notification settings - Fork 12
- Why does the games importer freeze on first run in XBMC/RCB?
- Why can't I have this as an XBMC addon, or keep all my configs?
- [Why isn't X console supported?] (#unsupported)
- When will feature X come out?
- Why don't I just load XBMC+RCB myself?
- Should I use branch X over the master branch?
Sometimes, ROM Collection Browser (possibly due to the preset config.xml) will seem to freeze if you try to import games on "first run" without any ROMs in [em]any[/em] of your folder(s). In this respect, it is best to choose the particular system you wish to load ROMs for on first boot if you only have 1 console type to import. If you have no ROMs whatsover, the importer will often stall.
First, you have to understand where I came from in makin this. I took an old pc, installed, configured, testing, dreamed, and daydreamed some more...leading to this. My intention before this was just to backup my configs to git. What it turned into, was RetroRig. I have looked into XBMC addon structures, and it seems doable, but it kinda goes against the spirit of what I set out to make: an easy "jumpstart" for RetroGamers with old or unused x66_64 PC's lying around. An addon already exists, which I make use of, called Rom Collection Browser. I am merely making that, and many other components speak to eachother, and come pre-configured.
Second, an attempt to "remake" RetroPie (which in spirit is what I wanted to, am doing) would also have been nice, but I chose XBMC+RCB for several reasons. ROM Collection Browser has so many things I can do, from extensive configuration, clean and comprehensive XML files, to modular design. I think RetroArch/libretro/emulation station is superb, and it is true that you can chuck your ROMs into [0-9]A-Z] subfolders, which I have done so for my hundreds of MAME titles. I just felt that RCB went above this, and handles configurations in-place very well (without having to go into an ASCII configuration file to tweak many settings). I very much appreciate and applaud the work RetroPie/RetroArch/libretro/emulationstation has done. RetroPie still lives on my main Pi to this day.
As far as configs/dotfile go for the components involved, that is a bit difficult with my time/resources. I can't realistically set out to produce an "easy to setup" install script that does everything for you and not overwrite configs that it references. What I can do at the least (which I hope to do soon), is give the user the option to backup their existing configs to a tarball, which work to retore that file at some point too). Things like this are in the future, but not yet implemented. I thank you for your patience.
There are a lot of version good reasons for this. Primary, some emulators, such as Dolphin, don't seem to allow you to "preset" you controller config within an ini file before starting (even with profiles). No text editor I tried seemed to make a difference, so it wasn't a "ASCII format" issues or some sort. It seems the only way to set the profiles, is via the GUI. Until problems like this get sorted out, or ever, I will not include the emulator by default, even though it's quite possible to use it (with a keyboard and mouse to set things to the gamepad).
Until things kinda stabilize and I can try out neat ideas to make this bigger than what it is now, features are added when time allows. You're always welcome to submit a feature request in the issues section at any time.
RetroRig is meat solely to provide an easy base for retro gaming to work from. Everyone has their opinion of what an ideal solution is. For some, RetroArch+Emulation Station is what they love, and for me XBMC, and the slick sorting options of Rom Collection Browser is my thing. Being able to also use XBMC for a myriad of other things is a plus for me as well. I started this for myself, so any benefit another person gets is a plus, and anyone that doesn't care for this, that is completely fine. The springboard RetroRig supplies take a lot of time and frustration out of the typical manual equation of setting this all up for yourself.
There currently are 3 branches:
* master - "stable" (as much as I can I suppose)
* beta - "test bed" for changes to merge into master
* vbox-beta - branch for beta vbox implementation
The master branch is considered "stable," where as the "beta" branch is where I stage upcoming changes I need to test out first. The "vbox-beta" branch is where early testing occurs for VirtualBox users, which is a tricky area to tackle at times (with graphics support and USB host issues). There is a non listed branch called "testing," where I just play around with random things, and really shouldn't be used by anyone.