Repository navigation
Duplicate ir data files for Dyson fan / purifier : Suggest reorganizing/restructuring repository to eliminate possibility of duplicates #1081
Description
I believe that Air_Purifiers/Dyson/Dyson_HotCool_HP02.ir and Fans/Dyson/Dyson_HP02.ir both correspond to the same device. Fans/Dyson/Dyson_HP02.ir is the inferior file (wrong directory) and could likely be removed.
Activity
reefsofts-rhosds commentedon Jul 27, 2026
Hello,
The Dyson Hot+Cool HP02 does do purifying and cooling, plus what a fan does. I encourage you to close this issue.
Sources: https://www.leroymerlin.fr/produits/ventilateur-et-purificateur-air-dyson-hp02-pure-hot-cool-link-blanc-74858070.html
kcpants commentedon Jul 27, 2026
The primary problem described in this issue is that there are two files in the repository that correspond to the same device and one of them should be removed. Which one is superior is certainly up for discussion. The suggestion is to keep the one in the purifier directory and remove the one in the fan directory since the HP02 is a purifier in addition to a fan.
@reefsofts-rhosds It sounds like you are suggesting closing the issue without removing the duplicate, if so I encourage you to understand the problem before suggesting a solution that does not address it.
reefsofts-rhosds commentedon Jul 28, 2026
kcpants commentedon Jul 28, 2026
Duplicate files corresponding to the same device is a code maintainability problem. Suppose a contributor wants to update the files for this device to add new functionality but are not aware of the second file in the repo. They push a change resulting in the content of the files diverging and becoming inconsistent with one another. New users are then unsure which file to use when they want to interact with the device.
The suggestion of keeping both files clearly does not scale. As a concrete example of why, consider the Dyson_HotCool_HP07.ir which is currently in the Air_Purifiers directory but not the Fans directory. Should it be copied into the Fans directory because like the HP02 it is a fan in addition to a purifier? When a new ir file for a device that is marketed as both a fan and a purifier is added to the repo should it be added to both directories? How would new contributors know to do this when the ir files for other devices exist in a single location in the repository?
It sounds like you may be advocating for keeping the duplicate so users can more easily find the file since it is discoverable under either fans or purifiers. If so that is problem that should be solved with searchable metadata, not duplication of source files.
A symlink (or more appropriately a hardlink to avoid the possibility of dangling links) would prevent the contents of the files from diverging but would still leave new contributors unsure of when symlinks/hardlinks are necessary when contributing ir files for new devices.
reefsofts-rhosds commentedon Jul 28, 2026
This is a filesystem problem. Tags would probably be the best for this situation. I do advocate for keeping the files, since such tags do not yet exist, and because Flipper Zero users are not always pro hackers. Indeed, the use of Flipper-IRDB is recommended by many YouTubers in their videos on how to get started with the Flipper.
Also, this repo along with every GitHub repo has pretty much unlimited storage space. Many people buy their Flippers in a pack which usually includes a 32g SD card. FOR TEXT FILES. Let's be honest, there's no running out of space in this situation and it helps beginners or people who are unsure about under what categories their devices might fall. Beginners can't read into the minds of developpers. You can try and teach them but you'll run into problems fast. It's better to accomodate everyone. Therefore duplication is not a problem, it's a solution to the problem. Not the best one, but the only one that's actually feasible
I once again recommend you to close this issue as it is really non-justified.
Before finishing this comment, i wanted to adress this particular paragraph of your previous message:
I'm under the impression that it should be added into the 'Fans' directory, since it also serves as a fan. So yes, when you add an IR flie, it should be copied everywhere it matches, be it 'Fans' and 'Air Purifiers', or 'AV Receivers' and 'Speakers', or any other kind of mismatch. I've got the same problem for my Squeezebox Touch: it's an AV receiver, a speaker and a sound system. How do i classify and make it so that other people find the codes? My suggestion would be instead of categories, manufacturers, but this does not seem like something most people agree with.
kcpants commentedon Jul 29, 2026
I am not sure why you are insinuating that storage space was ever the reason why duplicates are problematic as, if you read through all the previous comments that has never been suggested anywhere in the issue. As previously stated, this issue is not about storage space it is about the long-term maintainability of .ir files in this repo and the discoverability of .ir files by new users. As such, I will leave it open for the maintainers of the repository to decide what to do about it.
The problem you describe experiencing as a contributor is a good example of why intentional duplication is undesirable.
Speaking from personal experience, I was searching for ir files for a Dyson fan and did not find it in the fans directory only to later discover closely related devices in the air purifier directory. My specific device was not in there but if I were searching for the HP07 mentioned above I would have missed the file initially and assumed I needed to submit a new ir file for the device to the repository (which I eventually did for my device).
Ultimately, the best solution to this problem would be to introduce a straightforward, unambiguous, canonical way of organizing ir files so that it is always clear how to find them and where contributors should put them.
Your suggestion of reorganizing the .ir files by manufacturer rather than device type seems reasonable (i.e. instead of [DeviceType]/Dyson it would simply be Dyson/[ir files]. This structure would also result in the deduplication of the files.
reefsofts-rhosds commentedon Jul 29, 2026
You interpreted my examples wrong. My example for the Squeezebox shows why duplication is a solution while we keep the current file structure. This means that the project should create a guideline to always put the .ir files into ALL directories that they apply to, or change the file structure. Ultimately, what should be done is a universal way of creating tags across all filesystems and repositories so that you wouldn't have to use folders for archives. But that is clearly not going to happen, which is why I recommend that duplication becomes the norm across projects until such a tagging system is created. Or, the best no-duplication alternative I can think of is the [Manufacturer]/[device].ir file naming convention. So effectively, the problem here is NOT the duplication of files, it's the fundamental way that the project manages files. Which is why I recommend, once again, you close this issue and open a new one on your problems with the file organisation.
kcpants commentedon Jul 29, 2026
An issue need only document a problem, it need not prescribe the eventual solution to that problem. This one now contains discussion that the maintainers may find valuable and as such will remain open. How the maintainers decide to address and eventually close it (whether by removing the duplicate files or reorganizing the repository) is ultimately up to them.
Duplication in a repository is almost always an indication of a problem. I recommend and encourage that you not advocate for it to be used intentionally in the future.
reefsofts-rhosds commentedon Jul 29, 2026
Fair point, but if you bring potential solutions that can be implemented it will be simpler for the maintainers.
Not so fair point. I just asked friends in the medical research scene that have a huge archive of bibliography. If it weren't for duplication in the correct directories, they would never find articles they search for, because sometimes Zotero isn't fast enough. So no, duplication is almost never a problem per se. It becomes a problem when it can be easily avoided and/or is unintentional. So not in this situation. It is correctly used here because no easy and viable alternatives exist.
I have an officially documented C1 Proficiency in British English, I do not need caveman dialect to understand your thoughts, thank you very much. You can ignore this message if these were errors, but I highly doubt it considering your previous messages which are redacted in a very formal and quite correct way.
kcpants commentedon Jul 29, 2026
It seems you are citing an example of duplication being used as the solution to a search-ability / discoverability problem when a traditional SQL database would solve the problem in a much cleaner and more scalable way. It is not necessary to create a copy of an article within every directory in which it might be relevant when you can instead query a searchable column in a database which contains the pertinent metadata about the article that you want to search against (i.e. topics, authors, etc). In this way, if the article becomes relevant in other contexts the contents of the column can simply be updated instead of creating an additional copy of the article in a new directory.
As stated in the comments above, duplication IS almost always indicative of a problem and does not scale. However, it is especially problematic in software where the source files are living documents and may be updated over time. Imagine if the medical articles in your example were living drafts rather than finalized papers. Each time an update were made to a draft each duplicate copy would need to be updated. If one copy were overlooked due to human error and someone later relied on that overlooked copy as the foundation for future research they may base new conclusions on invalid / outdated information.
I apologize if the language I chose to convey the rationale behind leaving this issue open came off as antagonistic in any way. It was meant to be no more adversarial than your persistent encouragement to close it prematurely.
reefsofts-rhosds commentedon Jul 29, 2026
This IRDB also needs to be easily searchable. And no, a SQL database is NOT cleaner: you need to run it, you need to make sure it doesn't fail, you need to make sure updates work, backups are much more complicated, bulky datasets take SO. F-ing. LONG to load (cf my Nextcloud instance), etc. Generally, flat-file approaches are much more clean, since the role of the server is much less important.
A great example of scaled duplication is my friend's paper organisations once again. Over a thousand papers, easily searchable through the same place they find their PowerPoints, Word docs, living drafts, demonstrative MRIs, demonstrative X-Ray/CT scans, other tables they might have compiled or found, etc.
Which is why we are talking about archives, not living drafts. Living drafts just live in their /drafts/ folder, and they modify it there. Once published, one or two simple drag and drops suffice to correctly classify it.
Which brings us to another problem of organisation in general (be it tags, databases, folders, etc.): you need to know your setup. If you know your setup well and aren't fully overloaded (which you almost certainly shouldn't be if you are writing serious scientific papers on which people's lives depend if you wish for the result to be entirely without errors), then a bit of thought into the procedure (which you probably already have if you write papers as a part of daily life) and you're ready to go. If you are stressed about miscategorisation, you could script your way out of it by creating a classifier in under 200 lines of Python and Qt, and just run it periodically.
No worries, I understand your point of view. However, since the problem is not duplication in itself, but rather organisation of the files, it might be an interesting idea to change issues where we discuss this, to make the title more straight to the point, and because our conversation is beginning to move off the topic.
Honestly, I think the best move for the project would be to either keep duplication as a lazy way of doing stuff, or to add a real archive behind with a database, an API, a frontend, etc. But honestly this takes immense time and I do not think it will be implemented since, even if your issue persists, it's relatively minor. This isn't really code, there's no chance of getting spaghetti code out of it. So honestly this doesn't need to be at a Victorian Garden level of organisation unlike, for example, the Linux kernel. This can just be your average backyard's level of organisation and beauty.
kcpants commentedon Jul 29, 2026
I used the drafts example because the IR files in this repository are more comparable to living drafts rather than finalized papers. Many of the IR files I looked at were incomplete in the sense that they do not contain IR data for every function of the remote that they encode and as such may be updated in the future. User-generated function names across remotes are also inconsistent and someday may be standardized. While its true the IR files are not code in the strictest sense they are consumed by code (the flipper itself) and are code-adjacent enough that they would benefit from being managed as such.
Regardless, at this point I believe the discussion in this issue captures the ideal solution (a canonical system of organizing these files that does not produce duplicates) as well as the downsides of the current system. That should be enough for a dedicated maintainer invested in the long term health of the project to act on. I will update the issue title to include the suggested solution and hope that someday such a maintainer will have the time and energy to address it properly.
[-]Duplicate ir data files for Dyson fan / purifier[/-][+]Duplicate ir data files for Dyson fan / purifier : Suggest reorganizing/restructuring repository to eliminate possibility of duplicates[/+]reefsofts-rhosds commentedon Jul 30, 2026
It is true, but generally we do not see remote improvement but remote multiplication (Quantity over Quality). In that case, maybe the simplest solution for organisation is just a complex Github Action that acts as the classifier script I talked about in my previous post that handles duplications as PRs and commits are approved.
Yes, so maybe a new system that works with tags instead of folders, but that will have to be built and is fairly complex.
I did not know you could change the issue titles, but it does seem like the best option to continue moving forward with the issue without completely starting from a blank slate.
For the maintainers reading this and that don't want to read the whole thread, the solutions we discussed to solve the issue are:
If anybody has new ideas, I'll add them in this post as they come. I would consider this to be the last "angry argument" style comment that I will send here since it has been a bit, let's just say, nerve-wracking to try to win a competition that will get a pull request in like 5 months and require a complete change of the repo in which everybody will be able to share their thoughts when it will be time.
kcpants commentedon Jul 30, 2026
Just for the sake of clarity (without any intent to be argumentative), I am advocating for either:
I do not advocate for databases as a solution to this problem. They appear in the discussion because they are a tool appropriate for making very large datasets searchable across competing axes that is more extensible/customizable than filesystem layout. For the particular problem at hand, a well thought out, organized directory structure should be more than sufficient to address it as the only question a user really has to answer when interacting with this repository is "I have [device] created by [manufacturer] where would I find its corresponding IR file?"
I am also against any attempt at automated duplication as such a system seems like a true maintenance nightmare (would need to keep an up-to-date list of devices mapped to directories they should be duplicated into along with some code to try to match the names of user-created IR files to said devices).
reefsofts-rhosds commentedon Jul 30, 2026
Which is very understandable. A database is generally not a great solution but it is one nonetheless.The best long-term solution that still keeps it easy to find devices is clearly a new file naming strategy since it is low effort and cheap compared to others. I just wanted to summarise all the ideas we mentioned, good or bad, since we do for quite a lot of them, have diverging opinions. I do advocate for a change of the system since this is an important question: what happens when you have a truly complex multifunction device?