Big news: RomM 2.0 has been released! The coolest self-hosted ROM manager just got a little cooler. Included in this release are a couple big features, a number of improvements, and a LOT of small fixes.

Authentication

Support for session based, Basic and OAuth-backed authentication is now stable and generally available. Limit access to your library by enabling authentication, and grant limited access to your friends and family by giving them a specific role (viewer, editor or admin).

Machine-to-machine communication is now possible via the API, and one of the supported authentication methods (basic or token based). Read more about it on the wiki.

Background worker

This release adds experimental support for Redis, which, along with enabling session-backed authentication, allows RomM to run library scans in a background worker. This means any scan you run against your library will continue to run, even if you navigate to another page, or close the window entirely.

Not included in 2.0 (but coming in a future 2.x release) is the ability to schedule and run asynchronous tasks, which will help manage your library behind-the-scenes.

Bulk selection

Managing large libraries is now much easier using the gallery bulk selector, which allows you to mass rescan, update, download and delete a selection of games.

So what’s next?

In the short term, we plan to improve basic functionality, add more features to the client (collections, recently added, UI options, etc.), introduce scheduled backend tasks (automated library management), and refactor the backend to make it easier to build on later

In the long term, there are two feature we’re keen to build: .DAT file support (automated game recognition via hash comparison) and physical device management. This would allow you to send games to your devices (Retrodeck, OnionOS, GarlicOS, PC, Android, etc.) and sync save states/save files between devices.

If you have any questions, please post them in the comments and we’ll be happy to answer them!

Check the release notes to check the breaking changes that this version has. You will need to adapt your docker-compose.yml file.

Thanks to u/arcaneasada_romm for all his effort and help because without him RomM v2.0.0 wouldn’t be possible.

Thanks to all the contributors that made RomM a better software!

  • TheEClassGuy@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    11 months ago

    The link to the docker-compose example in the release notes doesn’t work, but I was able to get it working piecing together the other release notes, finally able to scan my library now due to the background worker :D

    Amazing work all around!

    • arcaneasada_romm@alien.topB
      link
      fedilink
      English
      arrow-up
      1
      ·
      11 months ago

      Thanks for the heads up! We recently switched the exposed API port but forgot to update the docs, which have now been fixed.

  • zn448sk39@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    11 months ago

    Can I use this app organise my roms and manage which ones are on my steam deck?

  • tratriod@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    11 months ago

    This seems amazing! Stupid question: I’ve already my big Roms folders, I need to change the structure of my files / folders or can I use the same I’m using?

      • l0033z@alien.topB
        link
        fedilink
        English
        arrow-up
        1
        ·
        11 months ago

        I have a lot of ROMs that aren’t well organized/named. I have lots of dupes too.

        What would you recommend me to use to organize? Most of the programs for this are pretty old and for Windows. Is that still as good as it gets? Any suggestions?

        • zurdi15@alien.topOPB
          link
          fedilink
          English
          arrow-up
          1
          ·
          11 months ago

          I don’t know any program to organize and/or rename rom files, but as u/arcaneasada_romm said, RomM will have a cli (and eventually through the web UI) to do such things, but that’s in the long term.

    • arcaneasada_romm@alien.topB
      link
      fedilink
      English
      arrow-up
      1
      ·
      11 months ago

      If you find it’s too much work right now to restructure your roms in a way that conforms with RomM, we do plan to build cli commands in the near future, one of which will “import” files into a common structure.

  • ivdda@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    11 months ago

    I’ve been out of the loop regarding game emulation for a few years now. Is there a way to integrate this with some emulator that’ll allow all ROMs to be stored in RomM, but accessed through the emulator?

    • zurdi15@alien.topOPB
      link
      fedilink
      English
      arrow-up
      1
      ·
      11 months ago

      Integrating RomM with emulatorjs is actually in the roadmap! But not yet.

  • iiiiiiiiiiip@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    10 months ago

    Not sure if you still see replies to this thread but is there an option to store metadata (mostly images) in the folder or a subfolder? For example this is how Jellyfin is storing it if you tick the store metadata in folders option. https://i.imgur.com/F2ku5wa.png

    It stores folder.jpg (main image), logo.jpg (logo), background.jpg (if you use backgrounds/headers) in the main folder and can also store all other metadata in a .nfo. Sometimes it also stores metadata in a subfolder for example the episode thumbnails are stored in a subfolder.

    I think this is an important option for a proper collection, one reason is because an emulator or emulator manager might use these images themselves to populate their navigation menus which if they’re all hidden away in an romm database, won’t be seen. Another is that it makes browsing your collection in a regular file browser a lot more visual and aesthetic

    • zurdi15@alien.topOPB
      link
      fedilink
      English
      arrow-up
      1
      ·
      10 months ago

      Hi! I think this can be a good improvement for our current metadata resources structure. Could you open a GitHub issue to keep the track?