Take and Scrape Your Own Screenshots

[meleu]

@herb_fargus It's important to mention that this trick only works on the Raspberry Pi version (home directory is /home/pi).

[herb_fargus]

@meleu ah thats right too, perhaps if we use the $user variable like we did with the retropie manager that should address it?

[meleu]

@herb_fargus
I've just realized that the rom name has a full path filename! We can get the home directory from it:

homedir=$(echo "$rom" | grep -o '\/home\/[^\/]*')

[EDIT: explaining the grep: the -o tells the grep to show only the matching pattern (and not the entire line); the regex means: the string "/home/" followed by anything different from "/" (which is the username).]

updating my script on the post...

[herb_fargus]

@meleu what about this?

#!/usr/bin/env bash

system="$1"
rom="$3"

rom_bn="${rom##*/}"
rom_bn="${rom_bn%.*}"

# Find most recent screenshot taken
screenshot=$(find "/home/$USER/RetroPie/roms/$system/images" -type f -print | grep 'RetroArch' | tail -n -1)

#rename most recent screenshot to rom name *note after scraping if you take a screenshot again it will overwrite the original image
mv "$screenshot" "/home/$USER/RetroPie/roms/$system/images/$rom_bn.png"

# Remove every RetroArch screenshot except the most recent
find "/home/$USER/RetroPie/roms/$system/images" -type f -name '*RetroArch*' -delete

[meleu]

@herb_fargus
I avoided the $USER because I was never really sure when RetroPie/emulationstation is executing a command with the regular user or with sudo. But now I checked here and it's the regular user (looked at the es_system.cfg to see the runcommand calling line, no sudo).

I would suggest just some superfluous/cosmetic changes:

1. use $HOME instead of /home/$USER;
2. use a variable to store the image directory path instead type it 3 times (if you change your mind about where to store the images, you have to change only one line):

imgdir="$HOME/RetroPie/roms/$system/images"

3. I put a 2> /dev/null in the screenshot's variable find to avoid error messages. I did it because all the error messages when executing runcommand-on{start,end}.sh scripts are logged in runcommand.log. I used that if to check if screenshot is not empty for the same reason.
4. the last find to delete the unwanted screenshots is fully OK for this application. But for other applications it would delete all the files that match the -name pattern in the subdirectories too. I used rm with -f because this option ignores nonexistent files, therefore no error messages if there is no screenshots to delete.

Updating my script again...

[herb_fargus]

@meleu typo:

    rm -f "$imgdir/*RetroArch*

should be

    rm -f "$imgdir"/*RetroArch*

I presume. There may be ways we can refactor it further as well

also is the print necessary?

[meleu]

@herb_fargus
Actually the double quotes comes in the end, otherwise some parsing problems can happen. Thanks for noting this.

[EDIT: this doesn't work. Look the next posts...]

rm -f "$imgdir/*RetroArch*"

[herb_fargus]

@meleu you should really test things before you say them authoritatively ;) quotes at the end doesnt work.

[meleu]

@herb_fargus
You're right... updated my script...
I deserve a downvote!

[herb_fargus]

@meleu alright I've taken some of your changes and just tweaked it a bit, and modified the original post. It seems to be working with my tests.

There may have been a slight lag either because I was taking screenshots too fast or I exited before it could be saved properly so it saved a screenshot from a couple seconds earlier rather than my latest one, so I'll have to look into that a little further. If you don't take a ton in a short period of time it seems to work as intended.

Also if anyone else cares, if you set it to 16:9 in the retroarch.cfg your screenshots will also be 16:9 rather than 4:3

[meleu]

@herb_fargus
I was thinking about this trick again and realized one thing:

When using this trick, the user can't get screenshots for any other purpose.

The runcommand-onend.sh will delete the screenshots.

While we don't make a workaround for this, I think it would be appropriate to add this warning at the first post disclaimers.

[herb_fargus]

@meleu They can as long as they change the screenshot directory to somewhere else other than the images folder within a rom folder.

[hiulit]

This tutorial could make a great entry in the RetroPie Wiki! What do you guys think?

[herb_fargus]

@hiulit perhaps once I've cleaned up the code a bit more, might even be able to make a module of sorts perhaps, idk. Id also like for 4.0 to be released before adding something like this.

[hiulit]

@herb_fargus Yeah sure, no rush! Just thinking out loud. Great work, btw!

[meleu]

@herb_fargus

@meleu said

When using this trick, the user can't get screenshots for any other purpose.

If they change the screenshot directory, they are not using this trick. :-)

[herb_fargus]

@meleu its a fair point. how I envisions it is that people will just go through their gamelist once to get titleshots and then disable it or something. Idk, thats what I did anyways ha ha

[meleu]

@herb_fargus
BTW: I'm working on RetroArch code to implement what is said here: https://retropie.org.uk/forum/topic/2483/screenshot-with-rom-name
If it works as expected and the libretro guys accept my PR (not submitted yet), we must adapt this trick. Then, let's wait before the wiki...

[herb_fargus]

@meleu that would save a step ;) I think there are others that would be happy for that implementation as well

[meleu]

@herb_fargus
When I was playing with RetroArch code I found that there is an option named auto_screenshot_filename.

As far as I understood, if this flag is set to "true" in retroarch.cfg, the screenshot filename is always Game Name.png, therefore it overwrites the old screenshot. It would be a really really nice feature for the trick we want to do here. Because we could turn on/off the trick based on auto_screenshot_filename flag.

The only problem is: I didn't get it working!

I made some tests here and it seems to be ignored by RetroArch. What a pity...

Sorry for this good followed by a bad news...