Possibly Improved Method for Kodi / ES Switching?
I've recently begun using RetroPie on a TV to run both Kodi and EmulationStation, after many years using it in an arcade cabinet.
I'm not a programmer, and see I'm immediately breaking style guidelines, but I just wanted to toss this out to see if anyone might want to implement it in a more permanent way. The current recommended method for booting to Kodi and Switching to EmulationStation seems to work well, though only once, and in only one direction. If you quit ES, you exit to a shell and if you navigate to Ports -> Kodi, now you're running both ES and Kodi, and quitting Kodi takes you back to the Ports menu.
I considered populating /opt/retropie/configs/all/autostart.sh with:
Rather than do that though, I wrote a small script and am calling that from autostart.sh. :
#! /bin/bash while getopts f: name do case $name in f) fval="$OPTARG";; ?) printf "Usage %s: [-f application to start] args\n" $0 exit 2;; esac done while : do if [ $fval = kodi ] then kodi-standalone fval="emulationstation" elif [ $fval = emulationstation ] then emulationstation fval="kodi" fi done
I'll likely add some process control to make sure I don't wind up running multiple instances, and an option to switch to a full desktop, but this seems to work well for quitting Kodi to get to ES and then quitting ES to get back to Kodi. Restarting ES to pick up new ROMs works as expected (Doesn't re-launch into Kodi).
There's the drawback of making it somewhat difficult to get a shell on the console, but in years of using a Raspberry Pi on my TV, I can't think of the last time I needed to.
Wouldn't have been easier to put the same infinite loop in
while : do kodi-standalone emulationstation done
@mitu Actually yeah, probably, thanks! And if I'd thought of it I think I'd have been happy enough :-) Now your comment will show up in search results and may save the next person some time.
The main reason I didn't even consider editing autostart.sh directly was because it could potentially be overwritten by RetroPie-setup and I'd have to go back and restore my changes. I tend to go off on a tangent, build a thing, and plug it in in the least-invasive way possible.
But I've actually just taken a few minutes added the ability to hijack that loop so I can insert one-off commands through Kodi main-menu items, like quit kodi gracefully and run startx, then return to Kodi smoothly when I quit the desktop session. So for my part, I'm in good shape for Maximum Convenience.
Rascas last edited by Rascas
I am sorry but I don't see this as a kind of improvment, by the contrary. The way ES was written, when you launch some program from it, it enters a kind of hibernation mode, it stays in RAM but it consumes virtually 0% CPU resources. This applies to Kodi or any game you launch from it. So tying to do something like this you will get pretty much 0 performance improvement. Not to mention that doing a loop like that, if one program crashes, it may render the system trying to load two instances of one program which may cause a lot of problems if not getting a completelly useless system that you will have to restart via ssh or unplugging the power cord.
Has you may know, you can always check the current CPU, Memory and stuff by running top (and other programs) remotely via ssh. The memory usage of ES depends greatly on the number of systems, games, covers, etc you have on it.
But one RPi 2 and above, with 1GB of RAM, is almost sure enough for you to don't get out of RAM.
Rascas last edited by
Not to mention that, if you have a lot of systems, games, covers, etc, ES can take some time to start, and doing that will take longer to switch from programs.
huey last edited by huey
This doesn't not satisfy your requirement exactly, but I found it to be pretty useful for a more general solution. Note that this works in more cases than just upon startup as CTRL + D will always launch this script in shell. In my case, CTRL + D then K will bring up Kodi, and the rest is up to the user to define.
# /opt/retropie/configs/all/autostart.sh # press ctrl + d will automatically launch this script in terminal # making it a useful hub for executing more "wordy" commands # note that actually, any key other than the pre-defined ones will abort echo "===================================================================" echo "=== EmulationStation starting in 3 seconds. Press "z" to abort. ===" echo "===================================================================" # read 1 character from input with a 3-second timeout # and save in variable $input read -n 1 -t 3 input echo "" # default case # if the input is empty or time runs out, start emulation station # works without keyboard, e.g., when only controller is connected # in case keyboard is indeed connected, hit enter or space to skip the wait if [ -z "$input" ] then emumlationstation # if "x", then start desktop elif [ "$input" == "x" ] then startx # the rest is for illustrative purposes # if "s", then shutdown elif [ "$input" == "s" ] then sudo shutdown now # if "r", then reboot elif [ "$input" == "r" ] then sudo reboot # if "k", then start kodi elif [ "$input" == "k" ] then kodi # if anything else, print help info else # print help info fi
Yeah this is really in the case where ES is a secondary use of the machine and it's primarily a Kodi box. The default for "start Kodi first" is as listed above, an autostart.sh which runs Kodi, then when Kodi is quit, runs ES.
If just having that loop in Mitu's answer had been the default behavior for the "Start Kodi First" option in retropie-setup, that would have worked fine for me and I'd have had no complaints. That's exactly how I expected it to work. However, since I'd already written my script, I did add in the option of injecting commands into the loop. So I have a home-screen icon in Kodi to exit to a Desktop. It adds that command to the loop then does a graceful exit of Kodi.
I agree that in the case where ES is the primary use of the Pi, as on my arcade cabinet, it's best to just launch Kodi from within ES for the rare times I want to use it.
I do think that Mitu's answer might be a sensible default in this use case: