YARMan Web (BETA)

daeks

@J.Beau said in RetroPie WebGUI + Metadata Editor (BETA):

@daeks Tried it, but didn't work (in Safari). Am I missing something?

I checked the bash script and it looks like that there was a small mistake inside the sed commands. Think you need to fix it manually with sudo nano /etc/apache2/envvars and change

export APACHE_RUN_USER=$user
export APACHE_RUN_USER_GROUP=$user

to your userid used (default: pi). After that restart apache with sudo service apache2 restart. I already fixed that on the github version of the script.

Arcuza

I would love these features in a web based management:

File system manager
Configuration editor

Do you have these in plan?

daeks

@Arcuza yes, I want to copy all the functions which are currently available on the retropie/recalbox manager.
Currently my planned feature list includes

System Monitoring Dashboard (mostly done already)
Browse and start/stop games from web frontend (design like the attract mode)
Rom Management (Uploading, etc.)
Rom Relations (find duplicates, find related games)
Bios Management (Uploading etc.)
Savegame Management
Scraping (currently thinking on gamesdb, screenscraper.fr and google)
Metadata Editor (done except automatic cleanup of gamelist/media objects)
(Support of no-intro DAT files)
Configuration Editor
Log Viewer (maybe also some kind of "fetch all support infos for retropie forum" automatically)
Raspberry / ES Management (Restart ES and reboot PI)
(ES Theme Support)
(Loading Image / Splashscreen Management)
Administration Panel for WebGUI (for example for adding new gamelist metadata fields manually or changing paths, etc.)
(Technical point: move from xml to SQLite for the webfrontend cause of performance)

Points in brackets are more or less some "internal" points which I have in mind but not sure if I can implement how I want to have them. Anyhow, as I am currently developing alone it might take some time for all points to implement :)

I organised all the open points on github: https://github.com/daeks/RetroPie-WebGui/projects/
Contributions are welcome :)

Jeck11

Omg - it would be awesone to have a "create support logs" option which also includes tge required details from the sticky.

Great work!

J.Beau

@daeks said in RetroPie WebGUI + Metadata Editor (BETA):

@J.Beau said in RetroPie WebGUI + Metadata Editor (BETA):

@daeks Tried it, but didn't work (in Safari). Am I missing something?

I checked the bash script and it looks like that there was a small mistake inside the sed commands. Think you need to fix it manually with sudo nano /etc/apache2/envvars and change
export APACHE_RUN_USER=$user
export APACHE_RUN_USER_GROUP=$user
to your userid used (default: pi). After that restart apache with sudo service apache2 restart. I already fixed that on the github version of the script.

That worked, kinda. It shows me the Apache2 Debian Default Page. We're getting closer :)

pjft

Wow, this looks awesome! I do have the question, though, which is whether having Apache running in the background takes a meaningful toll on the Pi's performance and memory or not.

But I'm keeping an eye on this. Using Sublime so far:p

daeks

@J.Beau great :) how does the content of /var/www/html/ look like? maybe you should rerun the script after update. The content from the repro should be locatated at /var/www/html/(assuming you are using a PI3)

daeks

@pjft said in RetroPie WebGUI + Metadata Editor (BETA):

Wow, this looks awesome! I do have the question, though, which is whether having Apache running in the background takes a meaningful toll on the Pi's performance and memory or not.

@BuZz already suggested to switch to the php integrated webserver, but I am no bash guru :). Starting the process in the background, pushing output somewhere, etc...

as far as I figured out it could be started with

php -S "$(hostname -I):8001" -t "/var/www/html" > /dev/null 2>&1 &

J.Beau

@daeks said in RetroPie WebGUI + Metadata Editor (BETA):

@J.Beau great :) how does the content of /var/www/html/ look like? maybe you should rerun the script after update. The content from the repro should be locatated at /var/www/html/(assuming you are using a PI3)

After some tinkering, I removed everything and followed the instructions again. It's working great in Safari now :) Thanks!

daeks

@BuZz said in RetroPie WebGUI + Metadata Editor (BETA):

How about just using something like the built in php webserver? - primarily for development and shouldn't be used for any public site - but it should be enough for this, and you can avoid messing around with installing a full webserver etc. eg

What do you think on that approach? https://github.com/daeks/RetroPie-WebGui/blob/master/scriptmodules/supplementary/webgui_default.sh

BuZz

@daeks the install function seems to be copying from md_inst to md_build (the wrong direction ?).

I would checkout directly to "$md_inst" - in fact you can just have a single install_bin_webgui function which does the git clone - keeps it simple.

it will need a remove function that removes it from /etc/rc.local - there are some bash things that I would change too, but looks much better and simpler without the apache stuff.

Cheers.

daeks

@BuZz Have changed it again. Hopefully everything is now fine :)

BuZz

@daeks almost :) - the configure and remove need a few changes - if you submit it as a PR once you are ready I will advise - easier then as I can reference code lines.

daeks

Just as a note here: I have rebranded the whole app with a more individual untaken name to avoid naming conflicts with other "web guis".

The name will be "YARMan Web (Yet Another RetroPie Manager)"

pjft

@daeks I love it. :)

herb_fargus

Looks brilliant. I'll have to find time test the latest changes though I'll defer to Jools for the setup script integration.

daeks

@herb_fargus said in Rebranded: YARMan Web (former RetroPie WebGUI) + Metadata Editor (BETA):

Looks brilliant. I'll have to find time test the latest changes though I'll defer to Jools for the setup script integration.

Great :) - As a side note: Currently on each save in the metadata module, a backup copy will be done for the gamelist.

General Questions:

What would be the location for videos / marquees? For the time being I am uploading everything to the emulationstation/downloaded_images location.
Whats the purpose of the thumbnail tag in the gamelist?

herb_fargus

@daeks

Seems like some people put them in diff folders /videos and /marquees but I think people use screenscraper to generate the gamelists on a PC, I'm not sure if we have defined a standard for retropie

If you note the scraper module they can be put in the default location or in the ROM folder (which I'm more partial to as it means I only have to scrape once and they are in my backups with the ROMs) so it may be worth considering a setting for which folders/paths it saves?

I don't know I thought it was to scrape a lower res image faster for the pi as it doesn't have the specs of a PC and full res images can slow it down?

pjft

I'll second that.

I certainly have the videos and marquees in a completely separate folder, for organization's sake. Also, as I load things from a USB, I don't want to store them in the SD card - which is the where the default scraper folder stores things.

I know it's yet another small thing, but I would not object to having the user set the folders in a preferences tab. My structure currently is:

/home/pi/RetroPie/roms/%SYSTEM_NAME%
/home/pi/RetroPie/videos/%SYSTEM_NAME%
/home/pi/RetroPie/marquees/%SYSTEM_NAME%
/home/pi/RetroPie/roms/%SYSTEM_NAME%/images (as this was how it was by default, and I'm too lazy to redo all the gamelists by hand).

I suppose I left the images folder insider the systems, but this way it's easier to manage. If I want, at any point in time, to have a lighter setup I can just ignore the videos folder, for instance.

daeks

@pjft As I am not fixed on that as well, I will revert the path to be a common config parameter. I will move that to the fields definition itself on the next change with default pointing to emulationstation/downloaded_images.

Then its up to the installation later on which path will be used for uploading new media objects (common name I used for that).
Currently it is "static" in the defaults/config.json for all media objects (later on for each field with type "upload" in defaults/fields.json).