Make igir output less verbose for hardware-specific collections/compatibility❓

[fooness]

When running igir similar to your igir_pocket_sync.sh script, as you state in the docs, the command/script “will cause a lot of warning spam for the {pocket} [or {mister}] output token because not every ROM of mine is playable on the Pocket, but this command will make sure every playable ROM is copied over.”

Is there any way to filter/silence/suppress these specific “compatibility”—so to say—warning messages, so that the output is less cluttered and maybe more important (in this specific situation) warning or error messages are better to be grasped?

--

If I don’t interpret these messages wrong, then I very much appreciate that the {pocket} and respectively {mister} keywords/tokens basically function as a filter/preset which, when specified, create collections only viable for these systems.

It seems the Hardware Target Game Database is somewhat similar to what I just described? Maybe that’s something igir could make use of for enabling/supporting the creation of such hardware- or platform-specific collections.

[emmercm]

That Hardware Target Game Database project is interesting. At first glance, it looks like it duplicates a lot of information in DATs, and that it just adds an opinionated way of sorting ROMs. Being able to support the SMDB .txt files instead of DAT files could be really interesting.

---

Good question about the replaceable symbol warnings, I'll have to think about reducing the spam there. Maybe an --ignore-macro-warnings flag, or maybe making those warnings INFO instead of WARN. Any thoughts there?

[fooness]

That Hardware Target Game Database project is interesting. At first glance, it looks like it duplicates a lot of information in DATs, and that it just adds an opinionated way of sorting ROMs. Being able to support the SMDB .txt files instead of DAT files could be really interesting.

That’s also how I understand that project, where “opinionated” aims to be 100% hardware-specific compatibility and naming/sorting/structure; and if that understanding of mine is correct, then I think this sounds pretty great.

Maybe an --ignore-macro-warnings flag, or maybe making those warnings INFO instead of WARN. Any thoughts there?

Both approaches sound good to me; adding some flag like --log-level=INFO might be more generally useful, as it could also be used with e.g. --log-level=WARNING or --log-level=ERROR … I’m not sure about the specifics of the currently implemente log levels, so maybe this would require more change than it sounds at first? --ignore-macro-warnings on the other side would probably need some detailed documentation, what exactly that flag filters out.

[emmercm]

I tried to hide the internals of log levels because I figure they might be confusing to most people, but the default log level is WARN, -v puts it into INFO, -vv puts it into DEBUG, and -vvv puts it into TRACE. I think the "verbose" flag tends to be more CLI-idiomatic than specifying a log level, but I have no strong opinion there.

I'm thinking about just changing the log level of the message in order to not add hyper-specific CLI options.

[emmercm]

I broke this out into two feature requests:

• Support Hardware Target Game Database SMDBs as DATs #318
• Drop log level for output token replacement failure messages #320

[fooness]

I'm thinking about just changing the log level of the message in order to not add hyper-specific CLI options.

That sounds reasonable. And thank you for elaborating on the log levels; having a better understanding now.

Also, thank you very much for formulating the two feature requests.