@mitu Actually, it's a lot quicker with omxplayer disabled. Are there any actual benefits to having it enabled? UPDATE: Seems that a lot of clips only play audio

Thanks @mitu I thought it looked and sounded familiar! :)

Problem Solved: It turns out it was a wiring problem: the A and B Buttons were crossed on the 2nd controller. It seems the system has no way of differentiating between the two otherwise identical controllers. So the config for controller 2 probably overwrote the config for controller 1 and vice versa each time a new controller config was put in.

For all those thinking that every option will have help it is not so. The help message will only be shown in Option List / Multiselect Lists atleast at present. Also Help text is optional ie. it is shown only if defined for an option. This allows help to be shown only for complex/ambiguous options like Audio Device selection (both, the one with PCM and the one with Alsa). Many users dont know what these options do and adding a small help text solves this problem. @pjft Is Random Screensaver in help necessary? @TMNTturtlguy Your suggestion is also acceptable. What I was mostly going for was when a user doesnt know what an option does, they might be inclined to checkout all options in < > Type of setting (OptionList). Clicking A on that opens a list of text components. Here we can have some help shown. So help is not obstructing during the normal usage but only shown in deeper menus

@TMNTturtlguy it will act as a black screensaver by default, even with the star set. The condition for the screensaver is just "if setting is different to fade, then do black" which is give as there are only two options there :)

@Zigurana Perfect. And you're saying you fixed it now by "exposing the loopType and setting the loopType for that particular list to NEVER_LOOP."? That's a misleading name if I've ever read one - I wouldn't have found that one out :) I'm not especially keen on removing buttons myself based on the rational that it's needed to get cyclic menus working. I believe if we want to remove the buttons for UX clarity, that's fine, and if we want to make menus cyclic that's also fine, but making one contingent on the other may make the behavior unclear and unexpected when there need to be buttons and such. That being said, I can understand it's tricky in the current architecture. In my view of the world, in the right-side picture, pressing UP from the "System Volume" selection should take you to the "Back" button, and pressing DOWN on the back button should take you to the "System Volume" selection. That way it'll be fully cyclic regardless of the menu layout - there are quite a few menus with buttons where cyclic behavior would be a positive - I'm thinking of the scraping and metadata editor menus, but I'm sure there are others. Furthermore, if we're being nitpicky, most (if not all) dialogs where there are options to be changed could/should have a "Cancel" and "Apply" button rather than a "Back" button, which would in turn disregard any changes, or apply the changes. But that would require a larger overhaul of the menus as they currently are, and I'm sure that's not a priority for anyone, and that's outside of the scope of the discussion. :) Summarizing: a) I don't oppose removing the button, in principle. Your point is valid: single button dialogs probably don't need it anyway. b) I don't really support removing it because having it causes a new behavior not to work as intended. Would rather try to make the behavior work well with the buttons, instead, so that it works across the board. c) I won't oppose if a) and b) are done together, though. :)

@mike27277 said in Scraper Issues: trying to mark as solved cant find the button The options are located at the bottom right of your first post in a pull-down menu labeled 'Topic Tools'.

Great thanks, Will definitely try the Steven Selph's Scraper and hopefully it will fill in the missing meta data from the ES scraper.

@Fourthlaw said in Quick question about installed emulators (I hope): I'm installing all optional cores from source. If that doesn't work, I might just start over from a fresh image. I shouldn't think you want to do that. Please provide more information - see https://retropie.org.uk/forum/topic/3/read-this-first (I don't know what version of RetroPie you are running, or even which hardware you are running it on etc).

To debug please choose one system (Even if the problem is on many, it's better to debug one) - and please provide all the information you can regarding version etc as mentioned in the sticky topic, so I have an idea of what version of everything you are running. The output of dmesg and cat /var/log/syslog would also be useful - can use a site like https://paste.ubuntu.com/ for the logs

@meleu said in Disable 'Configure Input' menu: Hey guys, a confirmation after selecting "CONFIGURE INPUT" was implemented today (2016-12-03). It's cool isn't it?! :-) You have to update emulationstation from source to get it. I didn't try out so far. Nice to see such developments are done. Those tweaks are not essential but I'm sure the response is the same like the wifikey import for ex. - positive! Things are getting better 😀 ... Thanks to the dev team

I did the same thing too except I created a sub-folder within the roms directory and called it mame-samples and edited both the 1.4x and the 0.9x versions of the mame-advmame.rc file and referenced my folder there as I found some of my games were using the 0.94 version while others were using the 1.4 version of the rc file. On the sample path line, I appended the updated folder path to the existing entry. dir_sample /home/pi/RetroPie/roms/mame-advmame/samples:/home/pi/RetroPie/roms/arcade/sample:/home/pi/RetroPie/roms/mame-samples Any new audio samples I'll download will go to this folder instead of within the samples folder of ADV-MAME. The samples work when they're zipped, not extracted.