Closed workingmanrob closed 1 year ago
./setup.sh: line 129: /tmp/app-switcher.fifo: Permission denied
echo "dump" > $FIFO &
sleep 0.1
session_count=$(cat $FIFO)
Right now there are definitely no sessions because I have nothing installed yet so after a ctrl-c I remove that blurb and set
session_count=0
and the setup was able to proceed.
~/retrOSMCmk2$ ls -la /tmp/app-switcher.fifo
prw-r--r-- 1 osmc osmc 0 Oct 10 14:24 /tmp/app-switcher.fifo
sdl2 install failed with the hard coded version so I hard coded a new version.
vi submodule/RetroPie-Setup/scriptmodules/supplementary/sdl2.sh
change 2.0.10 -> 2.0.20
function get_ver_sdl2() {
echo "2.0.20"
}
And the sdl2 build also fails due to missing package that will be installed later but too late for sdl2.
dpkg-buildpackage: info: source version 2.0.20+5rpi
dpkg-buildpackage: info: source distribution UNRELEASED
dpkg-buildpackage: info: source changed by Jools Wills <buzz@exotica.org.uk>
dpkg-source --before-build .
dpkg-buildpackage: info: host architecture armhf
dpkg-checkbuilddeps: error: Unmet build dependencies: libsamplerate0-dev
Build of mupen64plus pulled it in so I am trying again.
$ sudo apt install libsamplerate0-dev
libsamplerate0-dev is already the newest version (0.2.1+ds0-1).
This is where the mupen64 build bombs out on me.
../../src/Combiner.cpp: In member function ‘UpdateCombiner’:
../../src/DecodedMux.h:53:19: note: at offset 0 to object ‘aRGB0’ with size 1 declared here
53 | uint8 aRGB0;
| ^
g++: fatal error: Killed signal terminated program lto1
compilation terminated.
lto-wrapper: fatal error: g++ returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
make: *** [Makefile:469: mupen64plus-video-rice.so] Error 1
make: Leaving directory '/home/osmc/retrOSMCmk2/submodule/RetroPie-Setup/tmp/build/mupen64plus/mupen64plus-video-gles2rice/projects/unix'
current revision "2973f53"
last build revision
/home/osmc/retrOSMCmk2/submodule/RetroPie-Setup/tmp/build/mupen64plus/GLideN64/projects/cmake /home/osmc/retrOSMCmk2/submodule/RetroPie-Setup/tmp/build/mupen64plus /home/osmc/retrOSMCmk2
and still it builds... slowly
And the ncurses screen wouldn't let me copy this text.. which is annoying.
Could not successfully build mupen64plus - N64 emulate MUPEN64Plus
(mupen64plus-video-gles2rice/projects/unix/mupen64plus-video-rice.so not found).
Finally testing the addon to launch retropie and things are working.
Configured the basic settings for the addon and tried to launch. No sign of life except a message in the kodi.log
2022-10-10 23:37:46.876 T:870 INFO <general>: initializing python engine.
2022-10-10 23:37:48.656 T:870 INFO <general>: retrOSMCmk2 Launcher: "/home/osmc/.kodi/userdata/addon_data/script.launch.retropie/data.xml" missing or corrupt on this run
Tried a blank file and then it just complained it couldn't parse it.
2022-10-10 23:41:13.198 T:918 ERROR <general>: EXCEPTION Thrown (PythonToCppException) : -->Python callback/script returned the following error<--
- NOTE: IGNORING THIS CAN LEAD TO MEMORY LEAKS!
Error Type: <class 'xml.etree.ElementTree.ParseError'>
Error Contents: no element found: line 1, column 0
Traceback (most recent call last):
File "/home/osmc/.kodi/addons/script.launch.retropie/addon.py", line 286, in <module>
data_file = ET.parse(DATA)
File "/usr/lib/python3.9/xml/etree/ElementTree.py", line 1229, in parse
tree.parse(source, parser)
File "/usr/lib/python3.9/xml/etree/ElementTree.py", line 580, in parse
self._root = parser._parse_whole(source)
xml.etree.ElementTree.ParseError: no element found: line 1, column 0
-->End of Python script error report<--
2022-10-10 23:41:13.267 T:918 INFO <general>: Python interpreter stopped
data.xml apparently got created when I enabled a gamepad hotkey exit but now the addon only throws this in the log:
INFO <general>: initializing python engine.
but still no launch button.
I noticed the data.xml file also had a changelog date value <changelog-date>2022-10-10</changelog-date>
Tried to use the check for updates option in the addon settings page and that crashed kodi.
2022-10-11 00:44:25.705 T:932 ERROR <general>: EXCEPTION Thrown (PythonToCppException) : -->Python callback/script returned the following error<--
- NOTE: IGNORING THIS CAN LEAD TO MEMORY LEAKS!
Error Type: <class 'ValueError'>
Error Contents: invalid literal for int() with base 10: 'hangelog read'
Traceback (most recent call last):
File "/home/osmc/.kodi/addons/script.launch.retropie/addon.py", line 427, in <module>
slots_master = int(labels_master.pop(0))
ValueError: invalid literal for int() with base 10: 'hangelog read'
-->End of Python script error report<--
2022-10-11 00:44:25.772 T:932 INFO <general>: Python interpreter stopped
actually it was the second run that crashed kodi and the error changes slightly
2022-10-11 00:44:49.879 T:958 WARNING <general>: CPythonInvoker(4): Script invoked without an addon. Adding all addon modules installed to python path as fallback. This behaviour will be removed in future version.
2022-10-11 00:44:52.288 T:940 ERROR <general>: EXCEPTION Thrown (PythonToCppException) : -->Python callback/script returned the following error<--
- NOTE: IGNORING THIS CAN LEAD TO MEMORY LEAKS!
Error Type: <class 'TypeError'>
Error Contents: function takes at most 5 arguments (6 given)
Traceback (most recent call last):
File "/home/osmc/.kodi/addons/script.launch.retropie/addon.py", line 758, in <module>
view = dialog.yesno("retrOSMCmk2", "An new update to the addon is available.\n", "\n", "View changelog or Ignore it for now?", "Ignore", "View")
TypeError: function takes at most 5 arguments (6 given)
-->End of Python script error report<--
I can see some pretty obvious errors but I'm not great at python so I will not likely be able to fix it.
int() with base 10: 'hangelog read' < oops
I made an attempt using 2to3 today since the addon works on my buster install but fails on bullseye (which does not have python2)
Still no joy. Seems like all the problems stem from the fast-switching stuff that I can't use anyway since I'm on a Pi3.
I did have to fix some sudo errors but emulation station launches from the command line just fine after I did that.
'Invalid literal for base 10' is usually around where the script is trying to read data from the app-switcher fifo.
See the app-switcher journal:
$ journalctl -u app-switcher
...
Oct 25 20:49:40 lounge app-switcher.sh[29664]: /home/osmc/RetroPie/scripts/app-switcher.sh: line 177: /tmp/app-switcher.fifo: Permission denied
Recent kernels (4.19+) don't allow a user (even root) to write to files owned by another user in /tmp.
$ ls -l /tmp/app-switcher.fifo
prw-r--r-- 1 osmc osmc 0 Oct 25 20:48 /tmp/app-switcher.fifo
Because app-switcher.service runs as root you can workaround this by giving root ownership of the fifo and allowing the osmc group to write to it:
sudo chown root:osmc /tmp/app-switcher.fifo
sudo chmod 660 /tmp/app-switcher.fifo
(Your security concerns are your own!)
I'll give that a try as soon as I get a chance and let you know how it goes.
Did a fresh osmc install so it will be a while before I know.
And I did figure out any build issues were just retropie problems and have nothing to do with the appswitch issue here in osmc.
That worked a treat - and since I have no security concerns whatsoever - I just need to figure out how to make that change survive a reboot. Pretty sure this mod to RetroPie/scripts/app-switcher.sh will do just that.
#sudo -u osmc mkfifo $FIFO
mkfifo $FIFO
chgrp osmc $FIFO
chmod 660 $FIFO
and it did too. Thanks @markferry !!
Perhaps a more canonical way to manage service FIFOs is with a SystemD socket unit. SystemD takes care of creation and cleanup.
Here's an example: https://serverfault.com/a/823973
I'll try that after I get mupen64 to build... just figured out how to get mupen64plus-video-rice.so which is where it was bombing out on me.
mupen64 dies for me too. I didn't bother much since I don't happen to have any N64 ROMs
a SystemD socket unit
I meant that for @hissingshark, but I'm sure they'd appreciate a pull request all the same ;)
And the ncurses screen wouldn't let me copy this text.. which is annoying.
Could not successfully build mupen64plus - N64 emulate MUPEN64Plus (mupen64plus-video-gles2rice/projects/unix/mupen64plus-video-rice.so not found).
This is the link failure that results from the earlier compilation failure:
../../src/Combiner.cpp: In member function ‘UpdateCombiner’: ../../src/DecodedMux.h:53:19: note: at offset 0 to object ‘aRGB0’ with size 1 declared here 53 | uint8 aRGB0; | ^ g++: fatal error: Killed signal terminated program lto1
Unfortunately I think you're missing a few lines before that. Looks like a low-priority GCC warning (a note) which is being treated as an error.
(Slightly) relevant: RetroPie/RetroPie-Setup#767
Given the age of some of the upstream issues either RetroPie-Setup's mupen64plus is very old, or recent gcc is now stricter. (I think it's the latter...)
hmmm well I was able to build rice video with a minor flag change but I'm not sure where to drop that to make the whole mupen build complete correctly.
All I had to do was cd to RetroPie-Setup/tmp/build/mupen64plus/mupen64plus-video-gles2rice/projects/unix
LDFLAGS=-fno-lto make all
dropped the flag into the Makefile in that folder too but the mupen build still bombed. ¯_(ツ)_/¯
So my latest successful build had some extra steps including an extra package needed to build sdl2
sudo apt install git libsamplerate0-dev git clone https://github.com/hissingshark/retrOSMCmk2.git
mkfifo $FIFO
chgrp osmc $FIFO
chmod 660 $FIFO
Still using a modified app-switcher.sh - I looked at that systemd stuff, shuddered and ran.
Have yet to test the mupen64 build but at least this did let it build correctly.
And with November comes the October release of OSMC... just tried a brand fresh install to see if anything had changed.
So far I have seen the system fail to create a swap file (NFS root - it won't be able to) and then run itself out of memory while trying to compile mupen64plus/GLideNHQ.
When this attempt finishes I will add a bit of hard drive space temporarily at /home/osmc/retrOSMCmk2/submodule/RetroPie-Setup/tmp/ so it won't fail to create the swap space at least.. :crossed_fingers:
Given that it seems N64 emulation on RPi3 (my hardware) is widely considered not to work very well I'm probably not going to pursue it.
See if you can pull out upstream-able issues though - they're likely to get far more attention in RetroPie or OSMC.
Ah well it was a nice place to keep track of progress and may be handy in the future for others.
It did build properly with the added swap space and the replacement rice video is actually fantastic.
Drop in the hires textures for mario64 and the game looks amazing. Gameplay is smooth enough for me so far.
Cheers - case closed - :beers:
I'm glad you've been making progress amongst yourselves here. I don't have time to be very active on this project presently. But am trying to look in. This is particularly true of RPi installs, as the product was intended for Vero4k, and I have infrequent access to an RPi3. The RPi4 I don't have access to at all.
No idea why it builds everything from source but I wish it wouldn't... takes ages.
What/how does it determine whether or not to pull binary or build from source? I always picked basic install or whatever the first menu item is called and it just does it's thing.
I do run NFS root and have noticed some differences even just with the OSMC setup wizard (which I have seen quite a bit recently).
If you can point me to the bit of code/logic that makes the binary / source decision I'd be happy to test. Lots of Pi3s here and I even have me a Pi4 if we want to dive down that rabbit hole too.
I do use an NFS root for my OSMC installs so I am going to try a regular install to SD card today to see if I have better luck but I had errors about mupen64plus not installing and the kodi addon fails to launch. It does seem like emulation station installed ok as I was able to exit kodi and launch that directly via the shell script.
Will update with error messages as fast as I can generate them.