<folder> entries not being generated in gamelist.xml files

[samwelnella]

Describe the bug When a platform directory has ROMs organized by subfolders (e.x: /snes/Retail/USA/mygame.sfc) corresponding <folder> entities for each subfolder are not generated in the gamelist.xml.

To Reproduce Organize a platform’s ROMs into various subfolders and then scrape and generate the gamelist.xml with Skyscraper.

Expected behavior Expected behaviour is to generate a <folder> entity with child <path> and <name> entities for each subfolder. For instance if ROMs were organized within a platform subfolder with /Retail/USA and /Retail/EUR/ subfolders then the generated gamelist.xml should include 3 <folder> entities as follows:

  <folder>
    <path>./Retail</path>
    <name>Retail</name>
  </folder>
  <folder>
    <path>./Retail/USA</path>
    <name>USA</name>
  </folder>
  <folder>
    <path>./Retail/EUR</path>
    <name>EUR</name>
  </folder>

Technical information

• Skyscraper version: 3.9.1
• OS and Version: Debian 12.2

Additional context Unlike emulation station (which I believe auto generates folder entities) some frontends that support gamelist.xml files (such as Titanius launcher) need <folder> entities in order to display roms in subfolders.

[Gemba]

Thanks for being precise. Helps a lot.

Looks like the Titanius launcher is a relatively new project. I do not use it. However, I could imagine a support as additional frontend in Skyscraper. Skyscraper could preserve existing folder elements when rewriting a gamelist.

Some assumptions/questions:

1. The <folder> elements are put into the gamelist via the Titanius launcher or are the added manually with an editor outside the launcher?
2. When <folder> element(s) are used, how does the <path> look like? (absolute, relative to system, relative to folder, ...)?
3. How many gamelist.xml files are used per system in Titanius? If "relative to folder" (from prev question), I assume there is more than one gamelist.xml for that system (e.g., one in each folder)

[samwelnella]

Thanks for taking a look at this report!

I don’t think it needs to be a separate frontend in Skyscraper. The gamelist.xml spec document from the Emulation Station GitHub also has <folder> elements. They are just optional because ES will auto generate them (without modifying your gamelist.xml file) if they don’t exist already. I haven’t had any issues using a gamelist.xml that has <folder> elements in ES so we probably don’t need a way to generate a gamelist.xml without them.

To answer your points in order:

1. <folder> elements are not auto generated at all in Titanius Launcher. It expects your scraper to add the folder elements. I know that at least Skraper will add the folder elements when generating a gamelist.xml file.
2. The <path> element is relative to the folder that has the gamelist.xml file. So for example if the absolute path to the gamelist.xml file is /home/games/snes/gamelist.xml and the the absolute paths to your snes subfolders are /home/games/snes/usa/games a-m and /home/games/snes/usa/games n-z then three <folder> elements are created one with a <path> element of ./usa/games a-m another with a <path> element ./usa/games n-z and one more with a <path> element of ./usa. Every subfolder within a platform folder that contains ROM/game files or contains a subfolder that has ROM/game files needs its own <folder> entity.
3. Only 1 gamelist.xml file is used per system.

[Gemba]

Thanks for shedding more light on this, the dormant feature of ES: One can also add folder description and image/video and other info manually for folders that get rendered by ES.

You may try this branch https://github.com/Gemba/skyscraper/tree/fb_folder_elem_in_gamelist If it works well on your side it will be part of the next release.

[samwelnella]

I tried out the new branch and Skyscraper generating <folder> entities in the gamelist.xml file. However it looks like some of the <name> entities are named incorrectly if the folder is a subfolder 2 levels deep. This is some example output:

  <folder>
    <path>./Retail/USA</path>
    <name>il/USA</name>
  </folder>
  <folder>
    <path>./Retail</path>
    <name>Retail</name>
  </folder>
  <folder>
    <path>./Retail/JPN</path>
    <name>il/JPN</name>
  </folder>
  <folder>
    <path>./Demo/USA</path>
    <name>/USA</name>
  </folder>
  <folder>
    <path>./Demo</path>
    <name>Demo</name>
  </folder>
  <folder>
    <path>./Retail/KOR</path>
    <name>il/KOR</name>
  </folder>
  <folder>
    <path>./Demo/JPN</path>
    <name>/JPN</name>
  </folder>
  <folder>
    <path>./Retail/WORLD</path>
    <name>/WORLD</name>
  </folder>
  <folder>
    <path>./Translations/English</path>
    <name>ions/English</name>
  </folder>
  <folder>
    <path>./Translations</path>
    <name>Translations</name>
  </folder>
  <folder>
    <path>./Demo/EUR</path>
    <name>/EUR</name>
  </folder>
  <folder>
    <path>./Unlicensed/USA</path>
    <name>censed/USA</name>
  </folder>
  <folder>
    <path>./Unlicensed</path>
    <name>Unlicensed</name>
  </folder>
  <folder>
    <path>./Retail/EUR</path>
    <name>il/EUR</name>
  </folder>
</gameList>

It looks like the Unlicensed, Translations, Demo and Retail folder all get a correct <name> but the subfolders all have incorrect names.

[Gemba]

Thanks for testing. For this there was only one offending line. I remediated also some other cases.

[samwelnella]

I tried your latest changes. It looks like the <folder> elements are generated with no obvious errors.

Thank you very much for adding this feature and for your help.

[Gemba]

@samwelnella a quick heads up: With the upcoming 3.10.3 release new/additional <folder/> entries are no longer created by default (the existing ones will still be preserved as in 3.10.0). You can restore the default behaviour for folder creation from 3.10.0 by adding this to your config.ini:

[emulationstation]
addFolders="true"

Default value is false with 3.10.3. Rationale: The RetroPie-Team had a concern about the automatic folder creation, even it is does not create a regression.