[Zastava]

If you can that would be great. Always willing to learn.

@Wintermute0110 I managed to find a fix/workaround for the issue, I think.
So, for art assets to be portable and always work good, the special://... is needed.
But for roms you get the duplicated issue everytime you add a new game to an existing launcher. The solution for the roms is using a normal portable (without special and so on) path in the launcher. This only works for roms, not art assets. Like this: ..\..\collections\Commodore Amiga\roms\...

If you use a path that starts with special:// it is a Kodi path. It needs to be translated to a path that Python can use. The translation is done using a call to a function in the Kodi API. AEL keeps a copy of both the original and the translated path and I try to always use original, non-translated paths into the database. When scanning for ROMs for some reason the translation is being done but instead of storing the original path in the database.

The problem could be during the removal of dead ROMs (dead ROM is a ROM in the database and not in the disk, for example, you deleted the ROM file). The scanner first scans all files in the ROM path, and then it goes file by file in the DB checking that the file exists. If not, the ROM is removed from the database. During the ROM scanner proper, the list of files is traversed and check if the file is in the DB. If yes the file is skipped, and if not the file is added to the database, scraped, etc.

In conclusion, I need to verify the operation of the ROM scanner carefully to try to fix the bug. I am not sure if the bug can be fixed because original paths can be translated but translated paths cannot be put in the original form.

If you use a relative path that does not start with special:// then it should work, yes. In that case, the original and the translated path are the same. I think the Python starting path is $ADDON_DATA/plugin.program.advanced.emulator.launcher/ and AEL internally does not change it, so you can use relative paths from there for your ROMs.

The artwork/assets is another story because it is used by Kodi and Kodi understands perfectly the special:// protocol. However, in recent version of AEL I introduced some utilities to verify the artwork integrity (for example, whether you have corrupted images or images with wrong extension, etc.) and those utilities may fail.

-------------------------------

Also, I will take the opportunity to give you all an update of how things are going. I have been teleworking over the past 2 months and basically confined home. The amount of free time I have has increased somewhat. However, it is difficult to do some coding. It's a mixed feeling, like kind of lack of motivation with some anxiety because of the situation. Truth is I am OK and my family is OK, however this situation is difficult and I think it is taking a physiological toll on everybody, including myself. All in all, I would like to continue the development of the advanced launchers ASAP, myself and collaborators have a lot of ideas and exciting features we want to materialize soon.

Thank you so much for explaining it! At least the workaround seems to work good if you are unable to track the bug or fix it.

I feel you on that update and glad to hear that you and your family are OK.
It's like a paradox, we seem to have more free time but not the best state of mind to use it. But I can tell you, at least, that using AEL is helping me keep focus and seeing Kodi as great viable emulation platform. Can't wait to see some of those new ideas materialize.