19 votes

RomM: an open source, self-hosted emulation platform

9 comments

  1. kfwyre
    Link
    I posted about Afterplay here, which is a paid rom emulation platform. Meanwhile, this one is for those that prefer an open-source DIY version of the same concept. I haven’t used it so I can’t...

    Scan, enrich, browse and play your ROM collection from one beautiful & free self-hosted app. Metadata from 10+ providers, save sync across your devices, and support for over 400 platforms.

    I posted about Afterplay here, which is a paid rom emulation platform.

    Meanwhile, this one is for those that prefer an open-source DIY version of the same concept.

    I haven’t used it so I can’t recommend it personally, but I know we have a lot of people here with the knowhow to use something like this.

    6 votes
  2. Carrow
    (edited )
    Link
    Oh, I guess I'm the clown thinking that would include Steam Deck. Flatpak seems fine for this, wonder why they wouldn't build one, do the handhelds not like them? The git page lists several...

    native linux handhelds client

    looks inside

    "A compatible device running Allium, ArkOS/dArkOS, Batocera, Knulli, Koriki, MinUI, muOS, NextUI, Onion, ROCKNIX, Spruce v4/SprigUI/TwigUI, or TrimUI"

    Oh, I guess I'm the clown thinking that would include Steam Deck. Flatpak seems fine for this, wonder why they wouldn't build one, do the handhelds not like them? The git page lists several alternatives if you aren't keen on running it in browser on deck such as syncing with RetroArch and a decky plugin that syncs ROMs as non steam games and boots them through RetroDECK. (And even a Switch app!)

    https://github.com/rommapp/romm

    ETA: my guess re flatpak is that flathub has certain requirements that they didn't want to tackle since they may pertain more to desktop and the goal was retro handheld.

    3 votes
  3. 0x29A
    (edited )
    Link
    I have always leaned towards managing my rom libraries manually just in folders of files and running emulators separately at least on regular desktop (the frontends like RetroArch or Batocera...

    I have always leaned towards managing my rom libraries manually just in folders of files and running emulators separately at least on regular desktop (the frontends like RetroArch or Batocera don't always vibe with me except on handhelds or hidden-desktop kiosk type of machines). I find RetroArch extremely annoying to configure and set up via its UI

    This looks enticing enough to actually at least try out. Even if only used for metadata and management. It may not end up working for me but I think it's really neat. Sync is cool too. Maybe this solves enough problems to make it worth it, idk. Ultimately I am just excessively picky about these types of things, but I can envision a nice setup where I move between different machines in my house and everything (saves, etc) is synced and ready to play

    Always looking for cool new useful things to try out on the home server, especially since stuff like this I don't want to trust to cloud servers and companies and subscriptions and all that. Trying to get away from that in all the places where it's reasonable

    3 votes
  4. Rudism
    Link
    Kind of excited to see this one supports handheld devices like my TrimUI Brick. Definitely going to play around with this when I get some time.

    Kind of excited to see this one supports handheld devices like my TrimUI Brick. Definitely going to play around with this when I get some time.

    3 votes
  5. F13
    Link
    I use Romm with the Romm Sync plugin for Decky on my handheld gaming PC (which I have decided to call my GameBoy because it isn't technically a Steam Deck and "Legion Go" doesn't really sound like...

    I use Romm with the Romm Sync plugin for Decky on my handheld gaming PC (which I have decided to call my GameBoy because it isn't technically a Steam Deck and "Legion Go" doesn't really sound like something a human would say). It's honestly a great experience.

    3 votes
  6. Carrow
    (edited )
    Link
    OK I've been running this a couple weeks now, plus Argosy Launcher. There's some things I like, some I don't, but I'm keeping it. Syncing works, not much to say here since that's a base...

    OK I've been running this a couple weeks now, plus Argosy Launcher. There's some things I like, some I don't, but I'm keeping it.

    Syncing works, not much to say here since that's a base requirement. The built in emulator seems fine, serviceable, nothing special -- EmulatorJS is a LibRetro implementation, Argosy used them too. If RetroArch inundates you with options you don't care for, these are trimmed back.

    The thing I think I like the most: IT RELIABLY GRABS MANUALS!!! Only ScreenScraper.fr has those (I assume some legal license loophole like VLC), it's barely mentioned in the docs. But holey moley is it nice to pull up a manual right from the game page, especially for old games. I sat down and just went through a bunch for nostalgia's sake. I like that I can write notes and store txt walkthroughs with the ROM too.

    The UI is slick, but extremely opinionated. You can't reorder the homepage, only add/remove elements. You can override some metadata values by manually editing, but if you want to remove a value, you've got to edit the json for the provider (listed next to the metadata details, showing only 5 lines at a time). I can't find how to delete screenshots it pulled when they are wrong. Manual collections don't have custom ordering, either manually assigned or specifically "year, ascending" without it being the sort across all views. It can autogenerate virtual collections based on tags, but you can't rename them, it's the name of the tag. You can direct it to maintain smart collections based on tags, but it only does AND filtering, no OR. So no NES or SNES for a 'retro Nintendo', only like title Zelda and franchise legend of Zelda in case your metadata decides smash bros is a Zelda game (IGDB will do that). The more I use it, the more little nuisances like that I find.

    It has a patching tool, you can store the patches in the game folder and it recognizes them, but I'm somewhat disappointed with the implementation. You can either download the patched file or have it save to the library. The web emulator (and Argosy) let you select the patch file as a version to play, but don't support softpatching, crashing the emulator. If I make Argosy launch into RetroArch, match the rom and patch filenames, and don't stick the patch file in the suggested patch subfolder, then it works... But at that point I may as well hard patch to give it its own entry and stay able to use built-in emulators. I guess you could keep a list of patches, apply one and download the copy if you intend to plug it into an 'offline' emulator and not use any other RomM features?

    Metadata for ROM hacks sucks -- I don't blame RomM or any provider for this though. However, TGDB seems to have some, I see TGDB in the settings, but it is undocumented so I haven't checked if I need credentials. I don't think it was effectively pulling from there by default, but the defaults are a mess.

    The default is to enable every provider, regardless of API credentials. Maybe I goofed the start wizard by trying to start with minimal credentials? So the defaults create inconsistent metadata, like games in a series may not have the same franchise value (or collection -- metadata value different from the collection feature). Somehow, I'm getting fragments of IGDB metadata without credentials (though their screenshot collections are best I've found so far and I can give it a screenshot override priority). It seeks RetroAchievement matches even when I have it turned off.

    Scanning is treacherously slow compared to every other media server I've got. I assumed hashing was part of this, but even tiny files are slow. I think part of the issue is it seeking matches with more providers than I enabled (I went in and disabled all but a couple, no improvement). Also unlike every other media server I've run, it cannot detect when the filesystem has changed and run an update scan then. If you queue up an item to scan while it is scanning, it either silently aborts the previous scan or silently doesn't do the requested one.

    As I alluded, some features and docs feel half baked. Not in the "this is an early open source project" way, but in a "AI implemented/wrote this and a human didn't really use it/seriously review it" kind of way. I don't recall if it was Argosy or RomM, but one claimed features in the docs that it just didn't have. (I only just checked, GitHub reveals Claude as the second largest contributor, beggars can't be choosers.)

    I wanted to give my partner a simple way to play ROMs and ROM hacks, and this will do that well. I can do all the dirty work and say "it's on the server" rather than manually configuring everything on a specific device, I'm ultimately happy with it despite the gripes.

    Thanks for sharing :)

    2 votes
  7. [3]
    vord
    Link
    And here I am misreading the title, thinking to myself 'Gee, an easy self-hosted AWS? That sounds amazing!' Disappointed, but also not really cause this is also cool.

    And here I am misreading the title, thinking to myself 'Gee, an easy self-hosted AWS? That sounds amazing!'

    Disappointed, but also not really cause this is also cool.

    1 vote
    1. [2]
      kfwyre
      Link Parent
      I laughed, but also, honest question: am I even using "cloud" correctly here? Like, is saying "self-hosted" and "cloud" redundant? Or the opposite: does something that's "self-hosted" even qualify...

      I laughed, but also, honest question: am I even using "cloud" correctly here?

      Like, is saying "self-hosted" and "cloud" redundant? Or the opposite: does something that's "self-hosted" even qualify as "cloud"? I genuinely don't know.

      2 votes
      1. vord
        Link Parent
        The cloud is just someone else's computer. You're leasing various quantities of computation from AWS or Azure. If you can self-host it, you could also host it in the cloud. I'd probably just drop...

        The cloud is just someone else's computer. You're leasing various quantities of computation from AWS or Azure. If you can self-host it, you could also host it in the cloud.

        I'd probably just drop 'cloud' from it, as the self-hosted does the heavier lifting here IMO.

        4 votes