PlayStation FFmpeg Recording causes Seg Fault in RetroPie 4.0.2 (Recording Megadrive, VCS, etc still fine)

[RetroResolution]

Hi,

@BuZz I'm wondering if you can shed some light on a segmentation fault that getting when trying to use the FFmpeg recording in RetroArch under RetroPie 4.0.2, implemented as per my own guide: https://retroresolution.com/2016/07/06/recording-live-gameplay-in-retropies-retroarch-emulators-natively-on-the-raspberry-pi/

Whilst invesitgating an issue for another user, I updated my RetroPie from 4 Release-Candidate 1 build to the latest build as of this morning (last commit 22 hours ago).

After rebuilding RetroArch as per your original instructions to me back in May, I found that RGUI is now visually updated, although the version number is still 1.3.6 (as it was previously in RetroPie 4.x).

I tested recording from the RetroArch VCS and Megadrive emulators, and all works as before. However when I tried to record from the PlayStation, all the games return to Emulation Station after the Runcommand menu is shown, triggering a seg fault:
/opt/retropie/supplementary/runcommand/runcommand.sh: line 827: 2439 Segmentation fault

The verbose log output of one of these PSX recording attempts can be see here:
http://pastebin.com/4gPXjwsM

As RetroArch (1.3.6) and lr-pcsx-rearmed (r22) appear to be at the same versions as when everything last worked (RetroPie 4 rc-1) I'm not sure where to begin investigating.

I would note that when I first updated from 4 rc-1 to 4.0.2, and rebuilt RGUI, the menu text was corrupted, with selections overlaid when switching sub-menus or scrolling. I updated RetorPie again, this time including the underlying dependencies and the kernel. This resolved the text corruption, however there are no icons (I understand that this is all cutting-edge, of course).

Thanks in advance for any information you can provide.

[BuZz]

I can't offer any advice - if it used to work - you can git bisect the core/retroarch to see when it broke. And of course report the bug upstream.

your image links don't work.

[RetroResolution]

@BuZz Thanks, I'll see if I can determine what's changed.

I'm confused as to why RGUI is showing a radically new UI, but reporting the same version number.

Do you know if lr-pcsx-rearmed has been updated between 4rc1 and 4.0.2?

Maybe I should leave investigating this until a stable version 4 release is made?

[RetroResolution]

@BuZz could you tell me if it is possible for me to pull a specific commit of retropie's forked version of RetroArch from Git when rebuilding it with the 'disable-ffmpeg' parameter removed? Ideally I'd like to obtain the version used in retroPie 4rc1.

I've done similar to force retrieval of a specific version of the FFmpeg framework, but I'm not sure how the forked versions of components used by RetroPie are stored.

[BuZz]

@RetroResolution it's not forked. Nothing changed from rc1 unless you are building from source. Then you get the latest code.

[RetroResolution]

@BuZz okay, thanks for confirming that.

The problem is apparently in the very latest RetroArch 1.3.6 (version with the new UI) - I replaced my RetroPie 4.0.2's RetroArch with the ffmpeg-enabled version 1.3.4 from my RetroPie 3.8 system and was able to record from the PlayStation.

I initially tried replacing the lr-pcsx-rearmed PlayStation core from my RetroPie 3.8 build, but as expected it made no difference (both are version r22).

Unfortunately I didn't back up my RetroPie 4 rc1's ffmpeg-enabled build of RetroArch 1.3.6 before I updated everything earlier.

I need to look into pulling and building a specific version of RetroArch.

[RetroResolution]

@BuZz I'm confused - under RetroPie's github entry RetroArch is listed as forked:

RetroArch
forked from libretro/RetroArch
Reference frontend for the libretro API.
Updated on 17 Jun 2015

[RetroResolution]

There is a change specific to ffmpeg recording in the latest retroarch commit , adding a new null reference check, which perhaps is the issue with lr-pcsx-rearmed.

I've located the source for the July 17th release of RetroArch, and shall investigate building this with ffmpeg recording enabled. I'm aiming to have a workaround - building against a known-good recent version -whilst retroarch is in flux.

https://github.com/libretro/RetroArch/archive/v1.3.6.tar.gz

I'll aim to post an issue to the retroarch git repository later as well.

For the record, I've tested recording vcs, megadrive, SNES and 32x with 4.0.2 and retroarch 1.3.6 (very latest) and all of these work perfectly as before.

[BuZz]

@RetroResolution said in PlayStation FFmpeg Recording causes Seg Fault in RetroPie 4.0.2 (Recording Megadrive, VCS, etc still fine):

@BuZz I'm confused - under RetroPie's github entry RetroArch is listed as forked:

RetroArch
forked from libretro/RetroArch
Reference frontend for the libretro API.
Updated on 17 Jun 2015

That is not used by the retropie-setup script.

[RetroResolution]

@BuZz okay, thanks

[RetroResolution]

Okay, I have determined the steps required to pull a specific version of RetroArch from the Git releases, and have the existing RetroPie setup system build this (instead of the default behaviour of pulling the very latest source code).

From test it seems that sometime in the last few days some changes have been made to RetroArch 1.3.6; as well as adding a very funky new UI, when recording is enabled using FFmpeg something fails when the PlayStation emulator lr-pcsx-rearmed is used. Recording from VCS, Megadrive, 32X, and SNES were all working as normal.

I'll write this up as an addendum to my original guide, but for now the required process is:

OBTAIN AND BUILD SPECIFIC VERSION OF RETROARCH TO ENABLE FFMPEG RECORDING

Modify the RetroPie setup script for RetroArch:

cd /home/pi/RetroPie-Setup

remove paramater which is disabling ffmpeg in retroarch:

sed -i "s/--disable-ffmpeg//" scriptmodules/emulators/retroarch.sh

Edit the script to prevent call which obtains the very latest version of RetroArch source from git repository:

sed -i 's@\(gitPullOrClone "$md_build" https://github.com/libretro/RetroArch.git\)@#\1@' retroarch.sh

Obtain RetroArch version 1.3.6 (as a tar) from the git archive:

cd /home/pi/RetroPie-Setup/tmp/build

wget https://github.com/libretro/RetroArch/archive/v1.3.6.tar.gz

Unpack tar archive file:

tar xzvf v1.3.6.tar.gz

Remove the tar file:

rm v1.3.6.tar.gz

Rename directory to that expected by setup script:

mv RetroArch-1.3.6/ retroarch

Run the setup script to build RetroArch 1.3.6 with ffmpeg enabled:

cd /home/pi/RetroPie-Setup

sudo ./retropie_packages.sh retroarch

Replace the modified script file (to prevent issues when running future updates via the retropie setup script, due to uncommitted changes in the local git repository casused by modifying this file)

git checkout scriptmodules/emulators/retroarch.sh

NOTE:
after running the script, the temporary build folder should be empty
/home/pi/RetroPie-Setup/tmp/build

...and /opt/retropie/emulators/retroarchshould contain the freshly rebuilt version 1.3.6 retroarch

[meleu]

@RetroResolution it seems that you changed the Menu Driver to xmb.

Usually changed in Settings -> Driver -> Menu Driver. It is usually rgui, but it seems that it changed to xmb.

(Edit: it is menu_driver in retroarch.cfg.)

[RetroResolution]

@meleu hi,
Didn't know about that option - thanks!

As it happens I didn't make any changes explicitly - I grabbed the very latest version of retroarch this morning as a by-product of helping someone who posted a comment on my guide this morning. This variant of retroarch 1.3.6 is newer than that from which the binary version was built (the one you normally get when updating RetroPie).

It seems that in the overnight build that option is now default - on my machine I ended up with no icons in the menu. I posted a screen grab earlier, but I can't see the picture on the thread for some reason.

The new menu looks like it'll be very slick. Also means several of my guides are out of date again...

[dankcushions]

@RetroResolution that xmb menu is quite old now but is nice looking. it shouldn't be the default as retropie has the menu_driver set to rgui in the /all/retroarch.cfg, no? i don't know as i've been intentionally using the xmb driver for ages.

and yeah i would say your guides aren't out of date as i imagine retropie will keep using the rgui (old menu) as it's lighter on resources (although on an rpi3 i don't see any difference in game).

[meleu]

@dankcushions I took a look at the configure_retroarch function and there's no default setting to video_driver. I think it would be useful to set it to rgui.

[RetroResolution]

@dankcushions thanks for the insight - that menu being different really threw me this morning, and given the problems with recording I just assumed it was new. Glad my other guides can be left as-is!

[dankcushions]

@meleu you're right! hmm, interesting. perhaps the xmb will in fact be the default from now on :) i just asked in the retroarch IRC channel and apparently it's defaulted differently on different systems, so who knows when it changed.

like i said, it's fine on the pi3 but not sure about pi2 and 1.

[meleu]

@dankcushions said in PlayStation FFmpeg Recording causes Seg Fault in RetroPie 4.0.2 (Recording Megadrive, VCS, etc still fine):

perhaps the xmb will in fact be the default from now on

It's a bad idea for Android phones. The xmb doesn't accept input from the touchscreen...

[meleu]

@RetroResolution can you please paste here the output of this command:

grep video_driver /opt/retropie/configs/all/retroarch.cfg

I'm curious if it is really the default or if somehow it is explicitly xmb.

[RetroResolution]

@meleu hi,

the video block is as follows:

#### Video

# Video driver to use. "gl", "xvideo", "sdl"
# video_driver = "gl"

All commented out...