Fork of Amiberry-XML-Builder / up-to-date xml

[nemo93]

Hello @HoraceAndTheSpider ! Provided there was nothing happening on this repository for a while (no update on whdload_db.xml for more than 2 months) I decided to try my luck with a fork. My objective is to update the xml file once again so that it could benefit to all. Not trying to steal anyone's thunder just trying to help.

I reworked a bit the python script and uploaded a fresh whdload_db.xml in my own repo.

Questions

• Would you like me to issue a PR to merge my repo with yours? As far as my tests conclude my file is really up-to-date with all latest packages in there. I've also cleaned up a bit the various *.txt under settings/ folder and also added 2 fields for "smart" centering. Any occurence to the offset settings have been removed as well.
• I've start committing changes for the games specified in your issues section. Do you know if there's another place where changes for that xml file are being discussed?

Please let me know what you think.

[HoraceAndTheSpider]

Strange coincidence - You may notice I actually updated the XML last night - i had had a few issues having set up a new Pi 4, so it was no longer syncing with the retroplay packs - it is now after I fixed my cron scripts.

I will be glad to integrate your changes though - please feel free to submit a PR and i'll take a look. I dont think there is any reason I would reject it! I'm happy to add someone else to the credits tbh.

Thanks for this. Working with additions (even to the txt files) from PR's would be a much easier route as I was losing track with suggests changes, and changes-back that occurred previously.

Edit: actually we could discuss you being a contributor direct to this repo tbh.

I'm not aware of any other source for suggestions, other than the Amiberry github or maybe the official RetroPie forums.

[nemo93]

Indeed :-) So glad to see you're back! I need to get a Pi4 myself now Retropie 4.6 has been released.

Ok let me see what I could do re the PR. I'm having a hard time right now testing my many games with the changes I've made. That's also why I've closed all tickets from Issues section :-) I've left the ones I'm not sure about or wasn't able to reproduce/confirm.

I'm also working on a script (aka the refresher) and see if it could be plugged in somehow with Github's Actions so that whenever someone's push or submit a PR the script will automatically regenerate the db.

Thanks for the credits but I prefer not. You did all the work and I'll be happy just if my modest contribution helps some people.

As for me being a contributor to this repo...well If you think that would be easier then I'll be glad to contribute here instead of my repo. I'm ok with this proposition yet it's your call :-)

[HoraceAndTheSpider]

Just so you know the current updates are every couple of days from my host machine, where it downloads everything from the the RetroPlay packs, and rescans the every few days. Two times a week is a minor scan (new games added to XML) and once a week is a major scan (all game entries regenerated)

I forget exactly but i think if the current xml is less than a day old or something, it doesn’t bother to do an update - I had in mind that something like this would allow for someone else to “copy” my workflow a day later, so that if my machine went down again, then there would be someone doing a second update :) that might be useful for us to discuss.

Part of the reason to only do this every few days is so that I am not eating up my own bandwidth in the daytime and I can have it do all of this while I’m asleep :)

[nemo93]

Thanks a lot @HoraceAndTheSpider! Ok I'm having a hard time with the PR given the way I (poorly) committed under my repo. Therefore here's my plan.

1. first of all can you please check/test and in fact validate my version of the whdload_db.xml? I'm asking because if validated that would set our target.
2. assuming you're fine with my version, I'll request access to your repo and I'll create a new branch.
3. I'll commit first the settings/* files to see how everything goes.
4. I'll issue a PR with those files to merge them into master.
5. if still fine I'll commit in my branch few changes to your script (in a smarter way than I did in my repo this time). I'll issue PRs after to merge into master. => not a lot of changes just the ones to ensure proper sorting, to add the "smart centering" parameters and to remove any ref to "offset".

If we get there that would be a very good start :-) I'll then have a look at Amiberry "xml" code part to see if I could be of any help.

What do you think?

[HoraceAndTheSpider]

I'm happy with your XML in terms of layout. My only reservation is that it cannot be directly used because 1) i am now reguarly running automated updates 2) i have many of the older retroplay packs scanned for compatibility.

Happy with items 3-5.

[nemo93]

Just to be clear because it was poorly phrased in my previous post: the target is to keep relying on your file and only on your file/repo. I'll add some very light touches to the layout and add the "smart centering" params that's pretty much it :-)

I've accepted the invite. Thank you for that. Soon I'll start working according to the plan above. I'm also keeping alive my own repo for the time being but I consider it more as a backup from now on.

I fully agree on your update workflow. I don't see any real reasons to update it more often. Every 24h or so is more than enough. And you need your bandwidth :-)

Any suggestion(s) please shoot.

[HoraceAndTheSpider]

All good - once we have the XML updating with the new format, we can track back to the main amiberry source and start looking at how to read the data. I will need to give myself some reminders!

[nemo93]

First PR submitted! Let's close that thread then now things are set in motion :-)