Minor bugfix releases addressing issues reported by users. CHANGES IN SNAPRAID DAEMON 1.6 ============================== * In scheduled maintenance, spin down only if the daemon is configured to manage spindown, specifically if spindown_idle_minutes is different from 0. * In manual maintenance from the UI, added a checkbox for ignoring configured thresholds. * Don't protect the home directory in systemd to allow using it as a data disk. * Automatically reload the content file at startup if it was...
Clicking Refresh is exactly what you have to do in this case :) It allows the daemon to rad the new state of the array after your manual sync. On Tue, Apr 7, 2026 at 9:39 AM abubin abubin@users.sourceforge.net wrote: The error is gone after I click on "refresh" on the webui. Will update here is anything showing again. Replacing 4tb data with 3tb data drive Sent from sourceforge.net because you indicated interest in < https://sourceforge.net/p/snapraid/discussion/1677233/> To unsubscribe from further...
Yes. The web interface is inside the commander.zip. If it cannot be found, this is the issue. What system are you using, so that I can try to replicate it? Anyway, as a workaround, try to just copy the commander.zip to the expected place.
These are bugfix releases addressing issues reported by users. It is strongly recommended to update to SnapRAID 14.1, as it fixes a critical regression in the filtering logic for the include/exclude directives that could cause files to be incorrectly excluded from the parity calculation. CHANGES IN SNAPRAID DAEMON 1.4 ============================== * Propagates errors logged to syslog (or EventLog on Windows) to the task log displayed in the UI. This makes troubleshooting script execution problems...
The SnapRAID project is taking a major step forward. We are proud to announce the official release of the SnapRAID Daemon (snapraidd), a specialized background service that transforms the manual SnapRAID CLI into an automated, "always-on" ecosystem. For years, SnapRAID has been a homelab staple for data redundancy through its command-line interface. The Daemon builds upon this foundation, providing a modern orchestration layer that handles array maintenance, monitoring, and reporting so you don't...
Welcome back Leifi! Yes, fix is supposed to be slower than sync and scrub. The main reason is that sync and scrub use a multithreaded implementation with one thread for each disk to try to squeeze the maximum performance out of the system. Something similar is technically possible for fix and check as well, but in the end, during such operations you are more interested in reliability than in performance. And pushing the system to its limit is likely not a good idea.
This is likely the LAST BETA release before the official launch. This is your final opportunity to provide feedback and help us shape the stable version of the SnapRAID Daemon. WHAT'S NEW? =========== * Extra Disk Monitoring: You can now monitor disks that are not part of the main parity array. These are defined in snapraid.conf using the 'extra' keyword and receive full health and status tracking, though they are excluded from automated power management ('up', 'down', 'down_idle'). * Relocated State:...
Thanks for the report. Right now, Metro is generally better than Spooky2, but the improvement isn't large enough to justify replacing the old, battle-tested Spooky2. Version 14.0 will introduce MuseAir, a new contender expected to deliver even stronger performance. We'll see how MuseAir compares.
Merged, thanks!
The SnapRAID project is evolving. We are excited to invite the community to test BETA 2 of the SnapRAID Daemon, a specialized service that transforms the manual SnapRAID CLI into an automated ecosystem. Based on feedback from BETA 1, we have refined the architecture to be more robust, secure, and for the first time, accessible to Windows users. WHAT'S NEW? =========== Windows Support: We are excited to introduce a dedicated Windows installer (.exe). The daemon should be installed in the same directory...
Yes, a Windows version is planned, but the first official release will be Linux-only.
Announcing the SnapRAID Daemon Open Beta ======================================== The SnapRAID project is evolving. We are excited to invite the community to test the SnapRAID Daemon (snapraidd), a specialized background service that transforms the manual SnapRAID CLI into an automated, "always-on" ecosystem. This release introduces a modern orchestration layer designed to handle array maintenance so you don't have to. WHAT'S NEW? =========== * Always-On Automation: Scheduled sync and scrub cycles...
Thanks, I've merged them!
Thanks for the report! This should now be fixed in version 13.1-rc-77-g24aab43, available at: http://beta.snapraid.it/ Aside from the GitHub build servers, I don't have access to a physical macOS machine, so it would really help if you could confirm that it's working as expected. Ciao, Andrea
It’s a good idea! I’m adding it to the TODO. However, the name .snapignore can't be used, as it would conflict with the Ubuntu "snap" application ecosystem (they have also discussed using .snapignore). Maybe we can use .snapraidignore instead. It’s a bit longer, but it avoids the risk of conflicts and keeps things clear.
If you pass the --gui option you should get them. See the snapraid log documentation at https://www.snapraid.it/log Anyway, I'm developing a daemon with the intention to replace such cron jobs with also more features https://github.com/amadvance/snapraid-daemon It's still in early stage of development, so it would take some time.
TommyDS v3.0 has been released at : http://www.tommyds.it/ TommyDS is a C library of array, hashtables and tries data structures, designed for high performance and providing an easy to use interface. This is the list of changes: * Added support for 64-bit platforms and 64-bit integers. When building on a 64-bit platform you can store more than $2^{32}$ objects in the containers. This doesn't apply to tries that are able to store only 32-bit integers, but you can change this with the TOMMY_TRIE_BIT...
SnapRAID v13.0 has been released at : https://www.snapraid.it/ SnapRAID is a backup program for a disk array. SnapRAID stores parity information in the disk array, and it allows recovering from up to six disk failures. This is the list of changes: * Added new thermal protection configuration options: - temp_limit TEMPERATURE_CELSIUS Sets the maximum allowed disk temperature. When any disk exceeds this limit, SnapRAID stops all operations and spins down the disks to prevent overheating. - temp_sleep...
Thanks! I've updated the web page.
Merged, Thanks!
Thanks, Komazow. I’ll pass for now. I’d rather not mess with the DOS version since I don’t have the test and build setup anymore. I just cross-build it from Linux.
I've also tried using the most recent get_fade() from MAME, but there's still no difference. We're probably missing something else. Anyway, I went ahead and merged it.
Yes, ddrescue will attempt to read even unrecoverable files by making multiple attempts. The --import option will be required because SnapRAID has never seen the new files copied to the array, so it won't be aware of them.
Unaligned access in advcomp's GetMatch causes crash with UBSAN or upcoming GCC 16
Latest commit should fix it.
There’s ddrescue, but it works at the device level, meaning it copies the entire partition, not individual files. I'm not aware of a tool that handles this reliably at the file level by default. You can try using cp along with a file list, keeping track of any failures and retrying as needed. ChatGPT can help you write a script for that if needed. If you can replace d4, that's definitely the better option, it will simplify the recovery process with SnapRAID and help restore d3 more efficiently. Otherwise,...
First, try to copy as much data as possible from d4 before it fails completely. Then, make sure the new d4 has the same directory structure as the original. Finally, use SnapRAID to recover the already failed d3.
OK, I've updated it to use the latest MAME 0.277 source. This should make it easier to find the ROMs, as they now match those used in MAME exactly.
Hi komazow, I merged your changes with some additions to fix some minor issues. Which MAME version (or clone) did you used as reference ? Maybe we can import some more clone using a more recent one. Ciao, Andrea
Hi komazow , Just committed your changes. Thanks, Andrea
Uploaded also the .deb to http://ftp.advancemame.it/
Working on it....
Maybe I found the issue. Check with the source code in git, or with the precompiled binaries at http://ftp.advancemame.it/
AdvanceMAME v5.0 has been released at : http://www.advancemame.it AdvanceMAME/MESS are unofficial MAME/MESS versions with an advanced video support for helping the use with TVs, Arcade monitors, PC monitors and LCD screens. AdvanceMENU is a frontend for the AdvanceMAME, AdvanceMESS, MAME, MESS and any other emulator. They run in Linux, Mac OS X, DOS, Windows and in all the other platforms supported by the SDL library. New games supported or improved: [arcadez2003] [grant2258] 19yy - 19YY aladmdb...
Just realized that you want to use with the fixed resolution of your LCD screen, and not with an arcade monitor. Try disable the SDL support. Like with ./configure --disable-sdl --disable-sdl2 and to comment the "dtoverlay=vc4-fkms-v3d " in /boot/config.txt. This is what I do to use my LCD TV, and it works with buster and bookworm. No need to use advcfg as it tries to use customized video mode. It's intended for CRT monitors. Anyway, in the next weeks I plan to release a ready to use distribution...
Check the install.txt documentation. It contains some useful info for Raspberry. Anyway, ensure to use the older Raspbian "stretch", and not the more recent ones.
Check beta 225. Now you should be able to configure and save also such IPT_OTHER inputs.
Try with the beta 224, it should be fine now, and also configurable. The issue is that it was a not standard key name. Now I switched it to IPT_START and changed "Select" to IP_SELECT.
OK, got it. Try with the beta 222 at http://beta.advancemame.it/
I'm not sure I understand the problem. I tried running some Atari 2600 games, but pressing the "C" key doesn't seem to have any effect. For example, when I run: advmess a2600 -dev_cart amidar=amidar.bin I assume you're using the DOS version? I haven't checked that one in a while, but I don't recall something like that...
The version 188 at https://ftp.advancemame.it/ should have now dkongx working.
Are you referring to the release 4.0? The work in progress build should have Hammer Away working and Mspactwin renamed to Mspactwn. Anyway, you can get the prerelease here: https://ftp.advancemame.it/ You can check the pull request list to have an idea of the changes: https://github.com/amadvance/advancemame/pulls?q=is%3Apr
You are right, it's not working...
Are you by change at the FOSDEM 2025? No, I rarely attend conventions.
SnapRAID v12.4 has been released at : http://www.snapraid.it/ SnapRAID is a backup program for a disk array. SnapRAID stores parity information in the disk array, and it allows recovering from up to six disk failures. This is the list of changes: * Avoid a warning about function pointer conversion. No functional changes. For end users, there's no need to upgrade since this release introduces no functional changes. It's primarily intended to assist distributions transitioning to GCC 15, which uses...
Version 12.4 has been released to address this issue. I tested it with the latest snapshot of GCC 15, and it builds without any warnings. For end users, there's no need to upgrade since this release introduces no functional changes. It's primarily intended to assist distributions transitioning to GCC 15, which uses C23 as the default.
Investigating that now...
I just added a new 'misc_cocktail' option in the github repository. Ciao, Andrea
Please retry now
AdvanceMAME v4.0 has been released at : http://www.advancemame.it AdvanceMAME/MESS are unofficial MAME/MESS versions with an advanced video support for helping the use with TVs, Arcade monitors, PC monitors and LCD screens. AdvanceMENU is a frontend for the AdvanceMAME, AdvanceMESS, MAME, MESS and any other emulator. They run in Linux, Mac OS X, DOS, Windows and in all the other platforms supported by the SDL library. This is the list of changes: Attempt to get Mirax up and Running (#170) [arcadez2003]...
AdvanceCOMP web page issues
Thanks!
Likely it's this issue of gcc 14.0 and 14.1. To be fixed in 14.2. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114927 Maybe try with the option -std=c99 or -std=c11
Likely PIGZ uses the zip 64 format that is no supported by advzip.
AdvanceMAME v3.10 has been released at : http://www.advancemame.it AdvanceMAME/MESS are unofficial MAME/MESS versions with an advanced video support for helping the use with TVs, Arcade monitors, PC monitors and LCD screens. AdvanceMENU is a frontend for the AdvanceMAME, AdvanceMESS, MAME, MESS and any other emulator. They run in Linux, Mac OS X, DOS, Windows and in all the other platforms supported by the SDL library. This is the list of changes: * Alcon / Slap Fight MCU hookup (#116) [arcadez2003]...
Advmame crashes with Nvidia drivers (linux)
Finally I tried with a NVidea board and I can replicate the issue. You can workaround it with the -nosmp option when starting advmame.
SnapRAID v12.3 has been released at : http://www.snapraid.it/ SnapRAID is a backup program for a disk array. SnapRAID stores parity information in the disk array, and it allows recovering from up to six disk failures. This is the list of changes: * Fix potential integer overflow when computing the completion percentage. No effect on the functionality. * Documentation improvements.
It's fixed now in github code. I confirm it had no effect other than printing a wrong value. Thanks UhClem!
Hi Jon, I checked the code and it's right. It looks like as a false positive warning from the compiler. What compiler and version is it ? Ciao, Andrea
Hi ariel, I added the change in git. Thanks, Andrea
Hi Marc, Yes, I suppose it would make sense to support them now. The underlying problem is that subvolumes are seen as different filesystems with independent inode spaces. This means that SnapRAID has to keep track of the subvolume ID along with the inode when searching for files by inodes. I'll see what I can do in the next few weeks. But don't hold your breath :) Ciao, Andrea
Hi Andy, With the --disable-vc I'm able to replicate the issue. I'm able to work around it using the option -nodisplay_restore that tells AdvanceMAME to not restore the video mode at the exit. But take care that AdvanceMAME still uses the framebuffer, unless you build with --disable-fb. It just uses it without the VideoCore interface. So, I'm not sure that you are really using the SDL. If even with -nodisplay_restore you have problem, try also with -logsync that writes the advmame.log file. Attach...
Hi Andy, Have you tried the git version of AdvanceMAME ? It has changes specific for the Raspberry 4. You have to build if from source. Also, try to run AdvanceMAME directly from the command line and not from EmulationStation, and check if the problem is still here. When building AdvanceMAME, you can also use the ./configure --enable-debug, that will report more information after a crash. That info will help to get an understanding of the problem. Ciao, Andrea
Hi Andy I tried on my Raspberry 4, and it looks like working well. Can you replicate the issue with the git version of AdvanceMAME on a standard Raspbian ? If yes, in what condition exactly ? I tried from both cmdline, window environment fullscreen, and also in a window (-output window), but everything looks like working. Ciao, Andrea
Hi Andy I tried on my Raspberry 4, and it looks like working well. Can you replicate the issue with the git version of AdvanceMAME on a standard Raspbian ? If yes, in what condition exactly ? I tried from both cmdline, window environment fullscreen, and also in a windows, but everything looks like working. Ciao, Andrea
Hi guys, I don't have time to add new features or handle minor issues in the project, and opening the Gihub issue will give a wrong message. Ciao, Andrea
AdvanceCOMP v2.4 has been released at : http://advancemame.sourceforge.net AdvanceCOMP is a collection of recompression utilities for your .ZIP archives, .PNG snapshots, .MNG video clips and .GZ files. It runs in Linux, Mac OS X, DOS, Windows and in all the other Unix like platforms. This is the list of changes: Fix CVE-2022-35014, CVE-2022-35015, CVE-2022-35016, CVE-2022-35017, CVE-2022-35018, CVE-2022-35019, CVE-2022-35020 Update libdeflate to 1.14
CVE-2022-35020 advancecomp: heap buffer overflow via the component inflate()
Fixed in github with the commit "Check size of the delta buffer" Here the check of all bugs: am@redstar:/mnt/bag/home/am/data/src/advancecomp/FIXED (master)$ ../advmng -z id0_command_advmng_-z_SEGV_sample_No.1 Corrupt compressed data on id0_command_advmng_-z_SEGV_sample_No.1 [at void throw_png_error():pngex.h:37] am@redstar:/mnt/bag/home/am/data/src/advancecomp/FIXED (master)$ ../advmng -z id2_command_advmng_-z_heap-buffer-overflow_sample_No.1 Corrupt compressed data in IDAT chunk on id2_command_advmng_-z_heap-buffer-overflow_sample_No.1...
CVE-2022-35018 advancecomp: SEGV via invalid read memory access
Fixed in github with the commit "Check move chunk"
CVE-2022-35019 advancecomp: SEGV via invalid write memory access
Fixed in github with the commit "Check move chunk"
CVE-2022-35017 advancecomp: heap-buffer-overflow in mng_delta_addition() in mng.c
Fixed in github with commit "Check move chunk"
Fixed in github with commit "Check for truncated end of central directory"
CVE-2022-35016 advancecomp: heap buffer overflow in data_dup() in data.cc
CVE-2022-35015 advancecomp: heap-buffer-overflow in le_uint32_read() in lib/endianrw.h
Fixed in github with commit "Check for truncated end of central directory"
CVE-2022-35014 advancecomp: SEGV via invalid read address
Fixed in github with commit "Fix not initialized pointer"
Yeah, I thought that this should work. Obviously. Do you mean that you intentionally created a new filesystem in the new disk with the same UUID of the old one? SnapRAID uses the filesystem UUID to identify if a disk is replaced. This could have invalidated some assumptions made by SnapRAID. At least, it's not a condition I ever tested. Ciao, Andrea
Hi Nick, It's a bit strange, because Snapraid recognizes that your new d5 was the old d2, and it tries to rename it. This means that the filesystem UUIDs of the two disk are the same. How did you initialize and migrate data to the new d5 ? A possible workaround could be to force a UUID change, like with: tune2fs -U random /dev/sdX1 Otherwise, you can also temporarily remove d5 from the snapraid array configuration, run a sync, add it back, and sync again. Anyway, I'll investigate this condition,...
SnapRAID v12.2 has been released at : http://www.snapraid.it/ SnapRAID is a backup program for a disk array. SnapRAID stores parity information in the disk array, and it allows recovering from up to six disk failures. This is the list of changes: * Fix build issue with GLIBC 2.36
Hi tao, Could you please try the 12.2 RC available at: http://beta.snapraid.it/ It's an equivalent fix, but that keeps compatibility with darwin. If you confirm that it's OK, I'm going to release it. Thanks, Andrea
Hi tao, Could you please try the 12.2 RC avatilable at: http://beta.snapraid.it/ It's an equivalent fix, but that keeps compatibility with darwin. If you confirm that it's OK, I'm going to release it. Thanks, Andrea
Try removing the #include <sys mount.h=""> line in the file cmdline/portable.h</sys> It's just a try, but maybe it works. Ciao, Andrea
It's something that should be fixed in the git code. You can get it from: https://github.com/amadvance/advancemame/ Ciao, Andrea
Which gcc version is used ? You can get it with gcc --version
The two patches, included in the SUSE src distribution, makes it working. http://download.opensuse.org/update/13.2/src/curlftpfs-0.9.2-61.3.1.src.rpm
advancecomp fails to build with GCC 11
Just made a v2.3 release to fix this. Ciao, Andrea
Hi Kevin, Did that rsync run while sync was in progress the first time you got that error ? If yes, it could be the cause. To replace a disk see: http://www.snapraid.it/faq#repdatadisk Ciao, Andrea
Hi Kevin, SnapRAID was thinking that such files were copies of other files, but the hash was not matching the copies. But it's not clear why this happened. Ciao, Andrea
Hi Kevin, Try running sync with the --force-nocopy option. Ciao, Andrea
SnapRAID v12.1 has been released at : http://www.snapraid.it/ SnapRAID is a backup program for a disk array. SnapRAID stores parity information in the disk array, and it allows recovering from up to six disk failures. This is the list of changes: * Reduce stack usage to work in environments with limited stack size, like MUSL. * Increase the default disk cache from 8 MiB to 16 MiB.
Hi saintdev, Yes. It looks like a stack overflow issue. MUSL gives only 128 kB to threads, compared to the typical 1 MB. Please try the beta version at http://beta.snapraid.it/ It reduces a lot the stack usage, and it should fit also in MUSL. Ciao, Andrea
Hi Frederik, Ensure to cleanup everything before rebuilding. Like with: make distclean ./configure --enable-debug make gdb --args ./snapraid diff -v run and when it crashes in gdb, type "bt" to get the full stack backtrace. Note also the use of "./snapraid", instead of "snapraid" to ensure to run the one just built. Ciao, Andrea
Hi saintdev, Which Alpine version is it ? Does SnapRAID pass the "make check" test after building ? Try also building it with starting with "./configure --enable-debug". It should give even more debug information inside gdb. Anyway, from your gdb log, it looks like that the issues is inside the readdir() function of the musl library. Not sure yet, but it's possible that such function is not thread safe, and crashes due to the use of multithreading added in 12.0. POSIX doesn't require such function...