Feedback - Bugs & Issues [CLOSED]

Fixed in: 3.5.0 WIP5 Today the scanning status window displays the last scanned file or directory.

Loading RomCenter DATs causes crash

RV 3.7.0

Loading RomCenter DATs causes RomVault to crash with an "index was outside the bounds of the array" error. These DATs supposedly worked with 3.5.1 but do not work with 3.6.4.

Corrupt CHDs crash RV scan

RV 3.6.0

RV crashes with error HDERR on corrupt CHDs. This occurred when chdman.exe was present in the RV directory. The CHD that caused the crash was v4 with compression level 2. If you run the CHD through chdman verify directly a fatal error occurs, Example: chdman verify -i C:\Emulation\ROMVault3\ToSort\lasstixx.chd chdman - MAME Compressed Hunks of Data (CHD) manager 0.233 (mame0233) Error reading CHD file (C:\Emulation\ROMVault3\ToSort\lasstixx.chd): read error Fatal error occurred: 1 (screenshot)

Empty directories and 0 byte files are deleted from locked branches and ToSorts

RV 3.5.2

Any branch or ToSort can be locked in the tree and is signified as such with a lock icon. This implies that the directory will not be modified and no files will be deleted. However, even if a directory like a ToSort is locked, 0-byte files and empty directories will be deleted during a fix. This issue is problematic for some collectors who keep 0-byte files or directories in their archives that they want to keep. For example someone may create a 0-byte file placed in a directory that has a filename that indicates where they found the content. Also, many old PC games present in TDC and eXoDOS sets contain intentional empty directories. Steps to reproduce: Create a 0-byte file and place it in a non-Primary ToSort Create an empty directory and place it in your non-Primary ToSort Lock the ToSort directory in the tree Scan the ToSort so that the file and directory are logged in RV's cache Perform a fix while the ToSort is locked Notice that the 0-byte file and empty directory are deleted Expected behavior: 0-byte files and directories should not be deleted if the directory is locked as indicated in the tree

ZipMove does not work when archive contains 0-byte files or empty directories

RV 3.7.0

In some cases, the ZipMove action does not work if the archive contains 0-byte files or empty directories. This behavior has frequently been observed with the Sega ALLS DAT when sets are renamed. This appears to be an issue with the order in which the files are processed. The archives which would need to be zipmoved are processed before the archive to be fixed due to alphabetical ordering. The archives which need to be used for the fix contain zero byte entries, which are normally deleted since they can be recreated. Thus when the deletions of zero byte files occur, the archive becomes ineligible to be zipmoved.

Corrupt CHDs marked as good after L1 then L2 scan

RV 3.6.2

Scanning

If a corrupt CHD is first scanned with a header-only scan it is recorded as good in the cache. If a regular scan is conducted afterwards, the scanning window will identify the CHD as corrupt, however the status will remain as good instead of corrupt. Steps to reproduce: Purposely create a corrupt CHD by modifying a few bytes somewhere in the middle of it with a hex editor Scan the CHD with a header-only scan and notice it is not detected as corrupt (expected) Rescan the CHD with a regular scan, and during the verification process the scanning window will show the CHD is corrupt (expected) After the scanning is complete, the corrupt CHD is not flagged with the appropriate corrupt status in the game list / rom details grids.

Missing text when using Linux

RV 3.6.0

General UX

Linux

Many parts of the RomVault UI are missing text when running with mono on Linux, particularly Ubuntu. The issue occurs on fresh installs of ubuntu 22.10, 23.04, and debian 12. Another user reported the same on debian with xfce so probably not kde that broke it. He mentions: "I'm erring towards libgdiplus and its dependencies (handles .net/mono's system.drawing mechanism which includes the fonts) being the culprit, it's the only reasonable change I can find, the distro's that work are using an 'older' version+dependencies, debian and ubuntu have significant dependency changes between version 6.0.4 and 6.1 of the libgdiplus package." Also, the font library dependency for mono changed on debian/ubuntu - likely the font and app window sizing is causing text not to be displayed now. Suggest maybe trying a smaller font that fits in the RV UI rows to see if that resolves the issue. (screenshot)

datvault doesnt work under linux/mono

RV 3.6.0

Linux

Hard crash.. application just kills itself. Issue first introduced with 3.6.0 WIP1. cmdline shows error in UpdateMasterLists

Split / Merged settings result in a crash with some No-Intro DATs

RV 3.6.0

There appears to be an issue with the handling of parent/clone relationships in RV 3.6 WIP builds. The standard No-Intro Nintendo DS DAT from DatVault may have invalid or references for P/C relationships that are not handled gracefully. Steps to reproduce: Download the standard No-Intro Nintendo DS DAT from DatVault Configure directory settings for that DAT to either Split or Merged RomVault will crash instantly without error Example Problematic DAT: https://cdn.discordapp.com/attachments/622121052364865591/1086751133919363144/Nintendo_-_Nintendo_DS_Decrypted_20230318-025455.dat

ZipMove causes crash when fixing a set with NotCollected ROMs

RV 3.7.0

When ZipMove is used to fix a set that has NotCollected ROMs (E.g. using merged/split MAME listxml), RV will crash with an "Index was out of range. Must be non-negative and less than the size of the collection." error.

RV7Z archives are recompressed when "Convert all 7z to RV7Z" is enabled

RV 3.6.4

A regressive defect was introduced in 3.6.2 where if the global setting "Convert all 7z to RV7Z" is enabled, RV will needlessly recompress RV7Z files.

Missing status icon for MIA found but not used for fix

RV 3.6.4

In the scenario where you have just found an MIA rom that belongs to a set that cannot be completed due to other MIA roms, RV will display a missing status icon in the rom details grid. Steps to reproduce: Start with a redump dat that contains bin and cue files Search for any MIA file in the DAT, and manually flag the associated cue file in the set as MIA as well. Modify the directory rule for your dat to use the option to keep only complete sets Scan and find fixes so that the cue file you manually flagged as MIA is now listed as MIA Found in bright yellow Notice the rom details grid and the status icon for that fix action is missing. ("Found an MIA, but wont be used for a fix because the set would still be incomplete")

MIA status is sometimes lost when using "Merge" setting

RV 3.6.2

The No-Intro PS Vita PSGameSD DAT contains MIA tags as expected, but the MIA status is not applied to some sets when Merge mode is used. Merged: Not Merged:

Cache can become corrupt with "Unknown Tree settings in DisplayTree" error

RV 3.6.0

The cache can become corrupt if Dats are rearranged and updated in a certain way. This issue was reproducible by one user by doing the following: Place two copies of the same DAT into your DatRoot like this: /Testing/dat1.xml /dat1.xml Ensure the directory rule applied to both DATs has "Don't auto add DAT directories" disabled Update DATs Add an additional copy of dat1 into the main directory so you now have three copies of the DAT like this: /Testing/dat1.xml /dat1.xml /dat2.xml Update DATs RomVault will trigger errors upon DAT update Note that this issue only occurs when doing a normal DAT update. If refreshing all DATs after step #4 then the normal dat merge conflict error occurs. (screenshot)

DatVault can throw invalid JSON error

RV 3.5.2

Malformed JSON can cause DATVault to throw an error

Missing status for "In DAT merged, delete" in ROM details grid

RV 3.5.2

RomVault displays a broken image in the ROM details grid when a deduped ROM needs to be deleted. Steps to reproduce: Scan an archive Load a DAT for that archive that has a matching file flagged with the "dedupe" status Find Fixes and notice the broken image in the ROM details grid Expected behavior: A descriptive icon should display in the ROM details grid instead of a broken image icon. (screenshot)

FixDATs are missing MIA flags

RV 3.5.2

When a FixDAT is created, RomVault omits the mia=yes flags for MIA files. Steps to reproduce: Add a DAT to your DatRoot that contains MIA flags, for example No-Intro Sinclair ZX Spectrum Select the DAT in the tree Click "Generate Reports" to create a FixDAT and save the file somewhere Open the newly created FixDAT and notice that the MIA roms are missing the mia=yes attribute Expected behavior: These flags should be preserved in FixDATs.

CMP DATs are interpreted with incorrect character encoding

RV 3.5.2

There is a discrepancy between how characters are interpreted in CMP formatted DATs vs XML formatted DATs. XML dats are interpreted correctly with UTF-8 characters while CMP dats are not. Steps to reproduce: Refer to screenshots for an example Expected behavior: All characters should be interpreted with UTF-8 encoding regardless of the original dat format (screenshot 1 | screenshot 2)

Crash occurs if a fix requires the 7z cache but no ToSort directory exists

RV 3.5.2

If a 7z file needs to be torrentzipped using the 7z cache, but a ToSort directory does not exist, then RomVault will crash. Steps to reproduce: Start a clean instance of RomVault with no default directories Add a dat to your DATRoot Add a solid 7z archive that contains files needed by the DAT somewhere in your RomRoot in an incorrect directory Scan your ROMRoot so the 7z archive is hashed Check with explorer and ensure no ToSort folder exists, delete it if it does exist Fix ROMs Notice that RV crashes when attempting to decompress the 7z archive to the Primary ToSort Expected behavior: If the Primary ToSort directory does not exist, it should automatically be created at the time of the fix, AND If a cache ToSort is defined but does not exist, it should automatically be created at the time of the fix. (screenshot)

Crash occurs if a RV temp archive cannot be deleted

RV 3.5.2

File Access

If a RV temp file is encountered during a scan, RV will try to delete it. A crash will occur if the temp archive is open by another process. Steps to reproduce: Perform a fix that will have RomVault create a large zip archive, for example a compressed DVD-sized ISO While RomVault is compressing the archive, force the application to close using the task manager Open the temporary archive in another application so that the file is locked Test that the file is properly locked by trying to delete the temp archive with explorer After you confirm the file is locked, start RomVault back up Scan the directory where the temp archive resides When the scan reaches the archive, RV will attempt to delete the temp file and crash Expected behavior: RomVault should present the user with a halting error notifying that the temporary file could not be deleted, OR RomVault should flag the file as locked and proceed with the rest of the scan. (screenshot)

Crash occurs when generating Fix DATs for directories using Single Archive

RV 3.5.2

If you generate fixDats on directories that are using the Single Archive setting with “Add SubDirs if multiple roms” with File as the archive type then RomVault will crash with an error. The text reports will not cause a crash, but the reports will not include any information from the directories using Single Archive. This may also occur under other directory setting scenarios but this is unconfirmed. Steps to reproduce: Put the Redump PlayStation 3 DAT in your DATRoot Change the directory settings to: Archive Type = File + Override DAT, Single Archive = Add SubDirs if multiple roms (see screenshot 1 below) Apply the directory settings so the DAT is reprocessed Generate a fixDAT for the PS3 directory from the tree Notice a crash will occur Expected behavior: FixDATs should be generated properly using the original DAT settings (not the effective settings due to directory rules) (Screenshot 1, 2)

Clicking category reorder buttons causes crash

RV 3.7.0

If you edit a DAT rule and try to reorder categories when none exist, a crash occurs. Steps to reproduce: Setup a new instance of RV Edit the DAT Rule for the RomRoot and go to Advanced tab Click on either the up or down arrow for the category list RV will crash with an "Index was out of range" error

DatVault does not load tree and triggers error

RV 3.6.2

Sometimes when loading DatVault the tree will not display and an invalid operation exception will trigger. This is not consistently reproducible and appears to be a race condition. This can easily be reproduced with a new RV setup after entering a valid DV key.

Repacking zips in ToSort modifies file timestamps

RV 3.7.0

When an archive in a ToSort is repacked the files are raw copied but the modified timestamps for those files are set to TorrentZip dates, however the file is not actually a TZip file. This frequently occurs when cues are removed from a redump cue pack but there are some remaining cues left, which RomVault repacks. Expected behavior: Files within the repacked archive should retain the original modified timestamps.

Duplicate Directory Rules can be stored in the cache

RV 3.7.0

Its possible for duplicate rules with the same DirKey to be stored in the cache. This can happen if you manually edit the config xml to create a duplicate rule with different settings from the one that is already stored in the cache. When you load RV and update DATs, the config file is updated and one of the rules is removed, however both will remain in the cache. To resolve this, you can remove one of rules and both will be deleted because they share the same DirKey. Expected behavior: RV should check for duplicate rules when processing the config XML and show the user an error.

Specified path, file name, or both are too long error

RV 3.6.2

In some situations during a fix, RV can crash with an error that states "The specified path, file name, or both are tool long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters."

DatVault delete old DATs function leaves empty directories

RV 3.6.2

When a DAT is discontinued in DatVault you can choose to remove it from the UI. This process removes the JSON file and renames the existing DAT to have a .old suffix. From here, if you click the trash can icon to delete old DATs then these old dats are deleted but the empty folders remain. These empty folders serve no purpose in the DatRoot and should be deleted as well.

Corrupt CHDs can freeze scanning

RV 3.6.2

Scanning

As of RV 3.6.1 some corrupt CHD files can freeze scanning. Previously these corrupt CHDs would be marked as corrupt accordingly when chdman was used with older RV versions. The lasstixx.chd example from an older HDD_ERR crash freezes scanning at 97%. Because CHD scanning cannot be forced stopped cleanly, this leaves RomVault in an unusable state where there is no option except to force quit the application. Related To: https://romvault.convas.io/bugs-closed/corrupt-chds-crash-rv-scan-cl7ovpueo104001224q3fexx6lgy

Crash with "Index was outside the bounds of the array" during scan

RV 3.6.2

Certain archives can crash RomVault during a scan. When this occurs there is an "Index was outside the bounds of the array" error. Problematic archive to reproduce the issue can be provided.

CHD v1 scanning is slow

RV 3.6.2

RV 3.6.0 introduced native CHD verification, however verification of v1 CHDs is exceptionally slow. I suspect there is caching or threading optimization that is not properly applied to v1 CHDs.

Header skipping logic does not account for lynx.xml or a7800.xml

RV 3.6.0

Header skipping logic does not account for lynx.xml or a7800.xml

Crash occurs with error "Missing files cannot have alt values"

RV 3.6.0

In certain circumstances CHD files can be flagged with attributes that should not be possible. This causes RomVault to crash when attempting to fix. Steps to reproduce: Load a MAME listxml DAT (not Dir2Dat) Scan a CHD that is needed for a fix in the MAME listxml DAT Force RV to fail a Move operation by locking the CHD or assigning incompatible permissions Find fixes / fix ROMs RV will fail when attempting to move the CHD The missing CHD will have an AltSHA1 assigned instead of SHA1, which should not be possible. If you attempt to find and fix again RV will crash with an error "Missing files cannot have alt values"

DatVault checkboxes do not display properly on Linux

RV 3.6.0

Linux

DATVault checkboxes always appear checked.

DatVault errors with "String was not recognized as a valid DateTime"

RV 3.6.0

The error "String was not recognized as a valid DateTime" occurs when clicking in the DatVault tree. This seems related to the system date time settings. (screenshot)

Duplicate directories can occur in the cache

RV 3.6.0

Case Sensitivity Issue

Under certain circumstances, RomVault can have duplicate directory references stored in the cache resulting in frequent "rescan needed" errors when trying to fix roms. This issue occurs in mixed OS setups when the source files are on a case sensitive filesystem and RomVault is running on Windows. A common scenario would be a Linux based NAS for hosting roms exported via a SMB share with case-sensitivity enabled. Note that even though case-sensitive SMB exports are enabled, Windows can still only access a single version of a directory of the same name. For example: "TestFolder" and "TESTFOLDER" could both be viewable in Windows Explorer, but navigating into each would actually only show you the contents of "TestFolder". This behavior appears to be contributing to this bug. Steps to reproduce: Setup an RV instance on Windows Add a ToSort that points to a case-sensitive filesystem Add a directory to that ToSort with a few files in it, for example "TestFolder" Scan the ToSort and notice the files are properly scanned Add another directory in the ToSort with the same name but different case, for example "TESTFOLDER" Scan the ToSort and notice the new directory is also scanned, but the contents are the same as the first directory in step 3, even if the files are different from the directory in step 5 Delete one of the directories on the case sensitive filesystem mimicking a user's attempt to resolve the case-sensitive conflict Rescan the ToSort and notice that both folders still remain, but are normalized to the case of the remaining name From this point, there is no way to clean the cache with RomVault, the user must completely rename the bad directory to something and rescan the contents Screenshots: Duplicate folders with different case Orphaned duplicate folders

Relative default ToSort cannot be recreated if removed

RV 3.6.0

The default ToSort cannot be recreated if you remove it. All ToSort directories are added as absolute paths, but the default ToSort is relative to the RomVault exe. Expected behavior: If a ToSort is added from the same directory as the RomVault exe it should be saved as a relative path instead of absolute.

Error reading some Dats generated by FB Alpha v0.2.97.29

RV 3.7.0

When scanning new Dat generated by FB Alpha v0.2.97.29 I get an error, stating something like "Invalid character for the specified encoding, string no.., position no..." (translated from my language). Only happens when scanning FB Alpha v0.2.97.29 (ClrMame Pro XML, Megadrive only).dat and FB Alpha v0.2.97.29 (ClrMame Pro XML, PC-Engine only).dat. Other Dats, for example FB Alpha v0.2.97.29 (ClrMame Pro XML).dat are working fine.

Cache can become unstable and trigger errors on every change

RV 3.5.2

In certain scenarios the cache can become unstable and trigger errors. These errors occur during startup when the problematic area is read and during interactions with the tree. This error renders RomVault effectively unusable. (screenshot)

Corrupt CHDs lose their corrupt status

RV 3.5.2

If a CHD is scanned and flagged as corrupt then rescanned or the DAT is updated, then the corrupt status is removed.

Some edge case statuses are missing images

RV 3.5.2

The following ROM statuses are missing images: R_InDatMerged_Corrupt R_InDatMerged_MoveToCorrupt R_InDatMerged_UnScanned R_InDatMIA_Corrupt R_InDatMIA_MoveToCorrupt R_InDatMIA_CorruptCanBeFixed R_InDatMIA_UnScanned

DATs with single archive directory settings are reprocessed on every DAT update

RV 3.5.2

DATs that have single archive settings set to true are reprocessed on every regular DAT update even if the DAT did not change. Steps to reproduce: Place a DAT in a folder in your DATRoot Change the directory settings to use Single Archive Apply settings Click the Update DATs button and notice the DAT is processed again. This occurs every time you choose to Update DATs Expected behavior: Update DATs should only process DATs if there has been a change (add/update/delete)

Registration window uses default icon in task bar

RV 3.5.2

The registration window does not have a custom icon defined, so it uses the default form icon when viewing in the task bar Steps to reproduce: Select Registration from the Settings menu Hover over the RV taskbar icon Notice the registration window uses the default windows forms icon Expected behavior: The RV icon should be used (screenshot)

Elevated RAM usage after refreshing all DATs

RV 3.5.2

RomVault appears to consume a significant amount of RAM while doing a full dat refresh. When the process is complete, RAM does not return to normal usage levels. Steps to reproduce: Start with opening a large RV instance so the issue is more pronounced Take note of your RAM usage before doing anything else Refresh all DATs Notice while dats are refreshing RAM usage is elevated Notice when the process completes RAM usage remains high Expected behavior: RAM should be freed up after the Refresh All DATs process completes and return to a normal level

Files can be stuck in a "cyan" state until rescan

RV 3.5.2

Its possible for an uncompressed file to be stuck in a cyan state if you start scanning and the file becomes unavailable before hashing can complete. This results in a situation where "Find Fixes" will not be sufficient to perform a fix. Steps to reproduce: Setup your RomRoot to target a mapped network drive Place a large uncompressed file somewhere in your RomRoot, approximately 2gb or larger to ensure you have enough time for the next steps Scan the RomRoot While the file is scanning, quickly disconnect the network drive Notice the file appears in the RomVault UI but it only has a size and no hashes Reconnect the network drive Attempt to fix as normal by doing "find fixes" then "fix roms" Notice the fix will not work Expected behavior: The error message should prompt the user to rescan since a file with no hashes at all is not a supported scenario. (screenshot)

Crash occurs when moving a file open by another process

RV 3.5.2

File Access

If a file is open by another process and RV tries to move the file as part of a fix, RV will crash. Steps to reproduce: Place a file which is needed by a DAT in your ToSort Configure the directory rule for the DAT to "Files" archive type with "Override DAT" option selected Scan the ToSort Open the file in your ToSort in another application so that is locked Confirm the file is locked by trying to delete it with explorer After confirming the file is locked, have RV perform a fix which should attempt to move the file Notice RV will crash when it attempts to move the locked file Expected behavior: RomVault should present the user with a halting error and update the cache, OR RomVault should flag the file as locked and continue with the remainder of the fix operation (screenshot)

Readable corrupt zips that require fixes cause repeated errors

RV 3.5.2

If a zip file is corrupt but readable, and the archive needs fixing (E.g. deletions of matched files), then RomVault will throw an error while fixing. This error will occur during every fix run as RomVault will keep attempting to fix the corrupt archive. Steps to reproduce: Place a corrupt archive in your ToSort that is readable where some files can be extracted but others cannot Place a DAT in your DATRoot that should match some of the files in the corrupt archive Update DATs Scan the corrupt archive Find fixes and fix ROMs An error will occur when RomVault tries to delete files from the archive Attempt to fix again, and notice the same error will occur Expected behavior: Suggestion: RomVault should not attempt to delete any files from corrupt archives since there are likely issues that would prevent recompressing the archive Contact johnsanc for example archive. (screenshot)

DatVault can load with no Groups displayed, refresh causes crash

RV 3.5.2

Sometimes DatVault loads with no Groups Filter in the left rail. This seems to occur most frequently when DatVault loads with an empty DatRoot folder. Steps to reproduce: Create a new empty test instance of RomVault Load DatVault Close DatVault Reload DatVault using the right click shortcut (for some reason this method of opening seems to reproduce the issue more frequently than the top menu) Keep trying step 4 until the missing Groups Filter issue is reproduced Once the Groups Filter is missing, press refresh button Notice RomVault crashes after pressing the refresh button Expected behavior: The Groups Filter should always consistently display, and pressing the refresh button should not cause a crash (Screenshots: 1, 2)

Missing ROMs from "Single Archives" are included as orphaned ROMs in the wrong FixDAT

RV 3.5.2

If a directory with Single Archive = No Subdirs has missing ROMs, then these ROMs are included in the fixdat from the previous collection. This results in a fixdat with content that does not belong which also cannot be parsed properly without potentially thousands of "Trying to add a ZipFile to a Dir" errors since the roms are orphaned in the fixdat. Steps to reproduce: Start with a fresh RV instance Place two DATs into your DATRoot in the same folder (Example: Redump Acorn Archimedes and Nintendo Gamecube) Configure the lowest DAT in the tree with Single Archive = No Subdirs with Archive Type = File with Override DAT set to true (Nintendo Gamecube) Generate fixDATs for all directories Notice only one fixDAT is created, and that this fixDAT contains content from both source DATs and files from the Gamecube DAT are orphaned without a set Expected behavior: RomVault should generate the fixDATs correctly with the appropriate content for each and no ROMs should be orphaned without a set. (Screenshot: 1, 2, 3, 4)

CHDs are not verified if already L2 scanned without chdman

RV 3.6.0

If you perform a regular scan of CHDs without chdman, the contents are not decompressed and hashed, which is expected. However, if chdman is later added the previously scanned CHDs are not verified. This should instead behave like a Level 1 (headers only) scan of a zip archive and then moving to a Level 2 (regular) scan. In the case of archives, RomVault properly decompresses and hashes the archive contents during the regular scan if upgrading from a headers only scan.

CHDs are incorrectly merged if the DAT contains .chd extensions

RV 3.5.1