[FEEDBACK]: Bugs, Improvements and Ideas for the program

[FoxyLoon]

Note: I know you have some templates and forms pre-prepared for some of the things I've written below, but before I knew it, I'd already written this whole text. I had a lot to say, and a lot of points I wanted to make, which is why I started writing everything in one topic. However, if you want, I can fill in one or other template later if it suits you better, such as the “Console Request”. Just let me know.

---

First of all, I'd like to congratulate you for this wonderful program. It really is a spectacular tool for organizing ROM libraries, choosing the best versions, avoiding repetition and simplifying/facilitating the manual and tiring process of this kind of thing.

It really saves hours of work and headaches. THANK YOU VERY MUCH

That said, while trying out the application I encountered some difficulties and thought of improvements that could help you improve the program. Below is my feedback, with suggestions and also a few questions. I hope it helps!

---

---

1. ❌ Softlocks when something fails

🛑️ Problem

• The program "softlocks" easily, especially when some module is misconfigured or not active (for example, if ROMMover isn't active, ROMDownloader doesn't work, which I don't think it's supposed to).

• The program doesn't crash, but it doesn't respond from that point on either.

• The errors appear only in the console and usually point to several Python files, which doesn't help much for those trying to use the app. I'm sure you already know this, but I wanted to reinforce it and make a suggestion below.

💡 Suggestions

1. Show "error messages" directly to the user in a clear way, saying what failed and where. It could be a popup or a debug/log area in the interface itself;

2. An automatic validator that checks if the modules are configured correctly before running;

3. Ensure that the program doesn't “just stop working”. It's annoying to constantly have to force close the program and restart it when something isn't right. If something goes wrong, cancel the process you were doing and return to the “initial state” by displaying a message or something.

---

---

2. ⚙️ ROMDownloader (and rclone) configuration

🛑️ Problem

• The initial configuration is confusing, especially with rclone.

• It's not very clear where to put the files, how to configure the remotes, or what to write in the interface. It took me a good 4 hours to figure out how to use the tool/module.

💡 Suggestions

1. Add a simple and direct explanation in the program about where to put the rclone executable (ideally in the same directory as "romsearch.exe"). In my initial attempts, as I didn't know it had to be in the same directory, I put it in a sub-folder (because that's how it was extracted) and didn't understand why it didn't work in the program or what I should do to make it work;

2. Add a “Test connection” or “Detect rclone automatically” button, to check if it's possible to extract content from the remote - something simple like getting a list from the remote;

3. Add a direct link to the rclone download (even if it's already in the documentation - it helps to have everything at hand);

4. Give a practical example of how to configure rclone in ROMDownloader. Note: Give examples without specific sites.

---

---

3. 💾 Saving and loading config settings

🛑️ Problem

• The current system for saving/loading configs is prone to errors. Whenever I used the program the first few times, I would forget to save the changes, and then the program would load old configs, especially when it crashed or stop answering.

💡 Suggestion

1. Automatically save changes as soon as they are made (or when closing the application) in an ‘active’ file/configuration (for example: “current_config.json”), without having to manually click on the “Save” button. You could also leave the functionality of importing/exporting configurations, but without having to worry about purposely saving every time there are changes.

---

---

4. 🌙 Lack of night mode

🛑️ Problem

• The interface is too bright, at least in the windows version. It looks like a “flashbang” every time I open the program 😂

💡 Suggestion

1. Add “dark mode”, since you showed in the docs that there is a dark version.

---

---

5. 🤔 DATMapper unclear

🛑️ Problem

• The DATMapper functionality was one of the most confusing modules to deal with.

• At first, I didn't know that this module was supposed to be used to analyze .dat files that had already been used (something that wasn't quite clear). Then when I realized this, I didn't know that I had to move the files from the “dats” folder to the “mapped_dats” folder manually with the exact names - because if the files didn't have the exact names, the program wouldn't recognize the files. Also, the “dats” folder only accepts files in .zip format, while in the “mapped_dats” folder, the files have to be extracted. It was quite a confusing experience to understand how it worked.

💡 Suggestions

1. Improve the explanation in the program itself (perhaps with a tooltip or a quick help section);

2. Change the name of the module to something more obvious, like "DATAnalyzer" or "DATComparator" or "DATUpdater" or something like that;

3. Rename the default folder to something like “dats_old”, to make its purpose clear.

4. When using a .dat file for the first time, the program could automatically copy that file to the correct folder and rename it to the expected format (for example: “name_known.dat_old” or “name_known_old.dat” or something like that). The goal would be for the user to only have to maintain the main directory with the new .dat files, and the program would automatically create/handle the old DAT files by itself.

---

---

6. ❓ Questions - RA hash updates 🏆

👉 How often are the RA hashes updated?

---

---

7. ❓ Question - CHDMAN

👉 How is CHDMAN being used for compression?

• This question isn't about what chdman is, but rather what commands are being used by the program when compressing roms.

• I ask this because, as the program supports consoles such as the PS1 and PS2, it's important to make sure that chdman is being used in the right way in each case - as there are two different types of compression, and each works better depending on the type of disc. For example:

🎮 PS1 - Roms usually come in .bin/.cue, which are CD's. In these cases, it's best to use the command:

chdman createcd -i "rom.cue" -o "rom.chd"

💿 PS2 - Most roms are on .iso, which are DVDs. Here, the ideal would be to use:

chdman createdvd -i "rom.iso" -o "rom.chd"

📌 So...

1. 👉 Does your program automatically distinguish between CD and DVD, adapting the final command according to the type of rom/console?

2. 👉 Or does it always use the same type of compression command, regardless of the original file type?

💡 Suggestions:

1. Perhaps it would be useful to add an option in the program for the user to manually choose the type of compression (cd or dvd) - (Just an idea, but it might not be the best solution, I don't know);

2. Showing in the log the command used for each compression could also help with debugging;

3. A short explanation in the documentation about how the program decides the type of compression would also resolve this doubt right from the start.

---

---

8. ❓ Question - RAW/ROM's directories and ROMMover

👉 What is the difference between the RAW and ROMS directories?

👉 And... what exactly is the purpose of ROMMover?

• While testing the program, I noticed that when I activate ROMMover, I have to specify a folder - which seemed to me to be just a way of moving roms from one folder to another. So far, so good.

• But after continuing to experiment, some doubts and confusions arose.

🔍 Observed behavior

1. If I leave ROMMover disabled, the program can't download the roms - it gives errors on the console;

2. I was hoping that, if I didn't need to move the ROMs to another folder, I could leave ROMMover disabled - but it seems that this also breaks the ROMDownloader module;

3. Since I have to leave this option active, the program forces me to have two copies of the same roms in different folders: one in the “raw” folder and the other in the “roms” folder (or whatever other names I have configured for the directories);

4. When I explored the two directories (“raw” and “roms”), I couldn't find any visible differences between them. They seem to have exactly the same files;

5. This led me to wonder if I'm misunderstanding the purpose of this separation, or if this is a bug.

📌 So...

1. 👉 What is the actual function of the RAW directory and the ROMS directory? What is the difference between the two?

2. 👉 Is ROMMover really mandatory? Or should it be optional if I want to keep everything in one folder?

3. 👉 The fact that the download fails when ROMMover is disabled - is this expected behavior or could it be a bug?

💡 Suggestions

1. If ROMMover is really optional, maybe the program should work without it, just using the RAW directory as the final destination;

2. If there is a technical reason for keeping the two directories separate (e.g. organization, filters, compatibility with other tools), perhaps it would be useful to explain this better in the documentation or show an informative warning/tooltip in the program.

---

---

9. 🕹 Suggestion - Options related to roms with RA 🏆

• The idea of prioritizing roms with RA support is a good one, as it ensures that everything downloaded is compatible with the website (or at least the vast majority). In fact, that's my preference too and I thank you for creating this as it's one of the main reasons I use this program.

• Here are some suggestions to improve the module:

💡 Suggestions

1. An option to only download roms that have RA support (and ignore those that don't);

2. [Complement to Suggestion 1.]: Export a .txt list with the roms ignored for not having achievements. This way the user knows exactly what has been left out.

3. [Complement to Suggestion 2.]: The program can save this list to check later if the roms on the list have achievements. If there are new roms with achievements on the list, the program will automatically download them and delete the entry from the list, leaving only roms that don't yet have achievements on the list.

4. [Complement to Suggestion 2.]: The program can also save this list and use it to download roms without achievements to a separate directory. In other words, the program would continue to download all the roms (with the best conditions), with the only difference being that all the roms that weren't in RA (or didn't have achievements) would go into a separate folder within the same directory as the respective console.

---

---

10. 🕹️ Suggestion - Adding "OPEN" Buttons

• It would only be just a quality of life tweak, but I'm suggesting adding a small "OPEN" button to the left of the "BROWSE" button on the "MAIN" program's home page to directly open the specified folder. It's just a small tweak but I think it would come in handy for navigating directly to some directories.

---

---

11. 🕹️ Suggestion - LINUX Support?

• It's probably not in your plans right now and I understand, but I was just wondering if you'd be interested in making a flatpak version for Linux in the future, or if you've even considered it. It would be nice to have both options. Just let me know if you've thought about it.

---

---

12. 🕹️ Suggestion - Support for more consoles

• I noticed, from the roadmap in the documentation, that you intend to include support for more consoles in your program in the future, which is great! But I would suggest that you first consider adding all the consoles supported by RA, from all categories. Of course, any console is welcome, even if it's not present in RA, but personally I'd prefer consoles that are supported by RA to be considered first, if possible. Of course, the final decision is yours and you do as you see fit, this is just a small request on my part.

---

---

I hope I wasn't mistaken in any way and that I was clear in what I said. I'll edit it later if there's a problem.

Lastly, thank you once again for this program. I hope some of my suggestions can help improve your project. Keep up the good work!

[bbtufty]

Thanks for this extremely detailed report, and glad you like the tool. These are great suggestions! Obviously some are more work than others, but I'll break these out into separate features and issues, does this make sense to you (let me know if I've missed anything):

• [ISSUE] Softlocking in the GUI
• [FEATURE] Improve documentation for rclone (include a minimal working example here, along with instructions on how to install)
• [FEATURE] Automatically save config whenever any changes are made
• [FEATURE] Include dark/light mode toggle
• [FEATURE] Various DATMapper improvements -- this module may actually get deprecated, since I agree it's confusing
• [FEATURE] Rename DATMapper
• [FEATURE] Improve documentation for the RAHasher
• [FEATURE] Improve documentation for how chdman is being used
• [FEATURE] Improve documentation for ROMMover
• [FEATURE] Include an option to only choose ROMs that have RetroAchievements
• [FEATURE] Include an "open" button for each directory in the GUI

For the only RA ROMs, the log already outputs information about why ROMs aren't chosen, so I'd prefer to leave out giving a list of these files (as you suggested)

Linux support I think is off the table because of the third party tools we use here (chdman, xdelta, rompatcher). If there are working Linux versions of these, I would be happy to push on this some time in the future

And I'm prioritizing consoles with achievements now! I've been extremely busy with other things so haven't had much time to work on this, but hoping to get some more time to add more substantial features soon(TM)

[FoxyLoon]

Yes, you've managed to organize and summarize the problems and suggestions I've made very well. But I'm going to take the opportunity to clarify some points, add some notes where I think information may have been missing, and complete some ideas so that everything is clear and complete. I may be repeating myself in some paragraphs, but I'm also extending my thoughts to try to facilitate precisely what I have in mind.

---

---

"[FEATURE] Automatically save config whenever any changes are made"

💾 About CONFIG - Main Config File & Import (Clarifications for a better understanding)

⚙️ About the main config file:

• The idea was that when you run the program for the first time a main configuration file would automatically be created in the same directory;

• After that, whenever you made any changes to the options or closed the program, the new settings would be saved in that main config file automatically;

• When you opened the program again, it would always use that main config file to load the settings;

📥 About importing presets/configs:

• When importing a configuration file, the contents of that file would overwrite the current settings, but by only modifying the existing main config file, rather than creating a new one or something alike;

💡 Extra Suggestions

• Add a button to go back to factory settings (if you had a base recommendation or something);

---

---

"[FEATURE] Various DATMapper improvements -- this module may actually get deprecated, since I agree it's confusing"

🧩 About DATMapper - Keep, Improve or Remove? (My opinion on what could be done with the module)

• If DATMapper still has some value in the program flow, perhaps the ideal thing would be for the program itself to automatically handle the old copies of the .dat files. This would make everything simpler for the user and you wouldn't have to worry about whether or not they understand how the module works;

• That said, as the .dat files are free and easily updatable, the module ends up losing its purpose a bit - which yes, as you said, it would be better to discontinue/deprecate the module itself. The user can simply download the latest version of the file;

• In the best case scenario, you could leave direct links in the program itself for users to fetch the .dat files from the official site;

💡 Extra Suggestions

If you decide to keep DATMapper, it might be interesting:

• Show a simple history of which .dat file have been used recently (may not be necessary);

• Allow you to quickly compare the current .dat file with the last one used;

• Show in the module interface the list of .dat files that exist in the directory, also indicating how long it has been since they were updated. The time since the last update would be reset every time the file is deleted and/or replaced by another. If there is no .dat file for a specific console, an indication saying "does not exist" would simply appear for that "game console";

• Add a quick explanation within the program of what the module does (for example: via tooltip or help icon on the side or something like that);

---

---

"[FEATURE] Improve documentation for the RAHasher"

🧠 About RAHasher - Documentation, Limits and Behavior (Possible Solutions to Possible Problems)

📅 Frequency of hash updates

• What I was asking in this section was how often RA hashes are updated - for example, if it's daily, weekly, etc... It was really just to understand whether it makes sense to do this check all the time, or whether it's worth spacing it out more;

• And yes, I think it's a good idea for this to be documented, so everyone would know what to expect and how the system works behind it;

🔒 Request limits

• I support the idea of setting a minimum number of requests. For example, as you left the minimum value at 30, this would act as a protection for the user, preventing them from unintentionally abusing the API. Therefore, preventing any number below 30 from being written would be a good thing to do in my opinion;

• If this limit is thought of on the basis of security or stability, then slightly increasing this number could even help to ensure that there are no failures or penalties or bans when accessing the API, even if it means that it takes a little longer to get the hashes;

♻️ Avoiding unnecessary updates

• Assuming that nobody needs to update the hashes every day, the program itself could automatically limit the number of times this operation is done, for example:

  • 3 or 4 times a week;
  • AND ONLY IF NO hash file or a complete hash file exists;

    (see "🛡️ Suggestion: Treat incomplete files securely" below)

• In addition to the above, when the user asks to update the hashes but already has files, a warning could appear saying, for example: "You've already had the hashes updated for X days. Do you really want to make the request again? Warning: updating several times can lead to unexpected consequences such as being blocked from the site" or something like that - just to avoid repeated calls to the API unnecessarily. This would also involve making buttons to update 1 hash of a console or all the hashes;

---

🛡️ Suggestion: Treat incomplete files securely

By the way, I'd like to make a suggestion related to cases in which the verification of hashes is interrupted (for example, if the program crashes, the program is closed halfway through, the internet goes down, or if the website is unavailable):

• There could be a system where, WHILE the hashes are being processed, the file in question is marked as "incomplete";

• If the program is reopened or tries to use that file, it would detect that the file is incomplete and try to pick up where it left off. If it is unable to resume, it informs the user that it will download the hashes again from the "game console" indicated because the file in question has become corrupted/incomplete and it was unable to continue;

  (see "💬 Communication with the user" below)

• The file would only be marked as "complete" when all the verification and hashing has been successfully completed;

💬 Communication with the user

• In the event of a failure, the program could also display a warning saying something like:

  • "Verification of X-console hashes has not been completed. Continuing now."

    (Note: "Continuing" or "Restarting" depending on the case)

• This helps the user realize that the file is in trouble but hasn't been ignored - the program is dealing with the situation.

📝 Additional Information

• It would be good to explain this behavior in the documentation, or even within the program (for example: tooltip or a note next to the selected console), so that users know that they don't have to delete or repeat everything from scratch if something fails.

---

💡 Extra Suggestions

• A caching system with timestamps could be created, so that the program knows whether or not to update the hashes of a console. (However, looking at old logs, I believe this already exists.);

• Allowing the user to see when the last update was made in the GUI could also be useful for keeping track of the current status without having to open files manually, or search through the extensive log, or check the giant amount of text that appears on the console;

---

---

"[FEATURE] Improve documentation for how chdman is being used"

📦 About CHDMAN - Important attention to EXCEPTIONS (Things I forgot to mention before)

• When I talked about compression with chdman, I was referring more to the distinction between PS1 (CD) and PS2 (DVD) as you saw. But it's important to note that this doesn't apply to 100% of cases or even to all ROMs;

• For example, there are PS2 roms that are CDs, such as "Crash Bandicoot: The Wrath of Cortex". In these cases, the most appropriate command would be createcd instead of creatdvd;

• In addition, there are other file types and compression methods that apply to different consoles - I found a thread on Reddit that might be useful for reference: Compression of PS2, GC, Wii, X360, DS, 3DS and PSP roms;

In a nutshell:

• It's worth doing some extra research and adapting the type of compression depending on the console and the type of rom, especially if you want to make the most of the space + ensure compatibility with emulators.

💡 Extra Suggestions

• It could be interesting for the program to try to automatically detect the type of image (CD or DVD) and apply the right command (createcd or creatdvd). A simple .bat file solves this problem for several files as follows:

Compress CUE to CHD - CD

 for /r %%i in (*.cue) do chdman createcd -i "%%i" -o "%%~ni.chd" 

Compress ISO to CHD - DVD

for /r %%i in (*.iso) do chdman createdvd -i "%%i" -o "%%~ni.chd" 

Extract CHD to CUE - CD

for /r %%i in (*.chd) do chdman extractcd -i "%%i" -o "%%~ni.cue"

Extract CHD to ISO - DVD

for /r %%i in (*.chd) do chdman extractdvd -i "%%i" -o "%%~ni.iso"

Important Note: I only tested this for PS1 and PS2 games.

• You can also allow the user to manually choose the type of compression if the automatic detection is not reliable;

• A small warning in the UI or in the Console when compression is done based on an assumption (for example: "Detected DVD ISO for PS2 - using creatdvd") could help keep the user/dev informed with more details during this process. (DEBUG type INFO);

---

---

"[FEATURE] Improve documentation for ROMMover"

📁 ROMMover - Still having some questions...

• I'm sorry, but I'm still having questions about ROMMover: I don't know if there's a bug in it, if there's a flaw in the logic of what it does or if it's really mandatory to have it active at all times for the program to work;

• From what I've experienced using the module and as I wrote above, it seems to me that the module needs some improvements - at least in terms of clearer functionality and not just "improvements to the documentation". In other words, I just want to reinforce that I believe the module has bugs;

---

---

"[FEATURE] Include an option to only choose ROMs that have RetroAchievements"

For the only RA ROMs, the log already outputs information about why ROMs aren't chosen, so I'd prefer to leave out giving a list of these files (as you suggested)

🏷️ ROMs With and Without RA - separation by directories/folders

• In addition to the option of only downloading games with RA support, I had also suggested an alternative:
  👉 Download all the games anyway, but separate them into two directories - one for those with RA support, and one for those without.

• This could come in handy for those who want to have all the games, and easily know what's compatible and what's not.

Imagine having something like:
/console_name_X/roms_ra → games with RA support
/console_name_X/roms_no_ra → games without RA support

💡 Additional suggestions:

• You could make this a checkbox saying "Separate ROMs with and without RA support in different folders". That way, those who want everything together keep it as it is, and those who prefer to separate, activate the option.

---

---

"Linux support I think is off the table because of the third party tools we use here (chdman, xdelta, rompatcher). If there are working Linux versions of these, I would be happy to push on this some time in the future"

🐧 Linux - Even without the extras, it would be useful!

• There are some tools that try to run Windows applications on Linux, such as:

• 🥂 Wine (compatibility layer capable of running Windows applications);
• 🍾 Bottles (more user-friendly interface for Wine);
• 🎮 Proton (from the Steam ecosystem);

Note: I don't know if they would work well in this specific case, but it might be worth trying.

⚠️ Important Point

• Nevertheless, and this is where I really wanted to make the point: Even if you can't include support for ROMPatcher/xdelta or CHDMAN, I think it would be very worthwhile to provide a Flatpak version of the app with the main features;

🔹 For me, it would be useful enough to have everything else working - even if those tools were disabled or flagged as “unavailable on Linux”.

---

---

"And I'm prioritizing consoles with achievements now! I've been extremely busy with other things so haven't had much time to work on this, but hoping to get some more time to add more substantial features soon(TM)"

• Thank you very much!!!

---

---

For the most part, everything was fine and you basically understood what I wanted to say, but when I read the summary list of features and issues that you wrote, I felt the need to add and clarify some, because it felt like things were missing. Once again, I apologize for the long text.

Thanks for letting me know where the program stands and what you're mainly focusing on.