@johnster000 Nice! You could check the “Hints For Devs” for your modules on the modules list. Some of these are just nitpicks; you can decide for yourself whether to fix them or not :)

@HeikoGr The repository (https://github.com/HeikoGr/MMM-LibraryMonitor) is not available :(

@sdetweil Yes, but not in this thread :)

My module is MMM-AtomVisualizer.

@plainbroke You have to ask @wswenson not me :)

@Qthulhu It would be great if you could create a PR so it can be included in the module README :)

@eddiebrok

This minimal config works for me:

let config = {
  address: "0.0.0.0",
  port: 8080,
  ipWhitelist: [],

  modules: [
    {
      module: "MMM-Remote-Control",
      position: "top_left",
    },
    {
      module: "MMM-JukeBox",
      position: "top_left",
    }
  ]
};

/*************** DO NOT EDIT THE LINE BELOW ***************/
if (typeof module !== "undefined") { module.exports = config; }

@tommyk Update MMM-JukeBox and it should work now :)

@sdetweil said:

Don’t know why node 24 causes so much trouble.

There is an issue with the newest versions of node v24 and v26. Here is our related issue: https://github.com/MagicMirrorOrg/MagicMirror/issues/4150

@karsten13 implemented a workaround in the develop branch, so our next release will be working with these new node versions. It’s a frustrating situation for new users, but it was caused externally.

I tracked this down to a likely root cause: after the HTTPFetcher 304 change, some consumers were trying to process empty responses. In PR #4180, I fixed that for calendar and other consumers.

@rkorell That should already be fixed in the develop branch by https://github.com/MagicMirrorOrg/MagicMirror/pull/4161 and will be in the next release. It would be great if you could switch to the develop branch and test it before the release :) Good analysis, by the way!

@wimthoelke
Please update to the new version (v4.4.3). Your stationID works for me.
If this doesn’t work: use the profile dbweb.
If this doesn’t work, checkout this module: MMM-PublicTransportHub

@Volkae said:
everything worked fine, but since two days it does not work anymore. It only signs “Abfahrtsschnittstelle nicht erreichbar”.

There have been some recent issues with certain APIs (we use different ones depending on the profile). Tell me which profile you’re using and which station and I’ll check. If you don’t want to share the station here, you can also send it to me via private message.

@sdetweil said:

this used to be default behavior

Are you sure? Do you remember in which version it worked that way? I’m not aware of it ever being the default, but I could be wrong :)

@sdetweil CX3 should use each event’s source-calendar color even when multiple calendars are shown together in the same month view. Does it work with multiple calendars?

@kkmirr04 Does it work when you add this to your custom.css?

.CX3 .event.singleday .headline .title,
.CX3 .event.singleday .headline .time {
  color: var(--calendarColor);
}

@Richard238 I haven’t had any problems with this new version.

@angeliKITTYx This shouldn’t happen with the just released new version v2.36.0. I recommend to update :)

@sdetweil said:

@kristjanesperanto what do you think of this?

Hmm… I didn’t expect something like that in the current release. But I won’t be able to take a closer look at it right away. It would be interesting to see if this also happens in the develop branch.

@Phantomkommander said:

Currently, if a client reconnects during the backend’s “protection phase,” it stays on “Loading…” until the next scheduled fetch. It would be the icing on the cake if the module could immediately push the cached data to a newly connected client, instead of making it wait for the next real API call.

Good suggestion. I’ve opened a PR (https://github.com/MagicMirrorOrg/MagicMirror/pull/4121) to implement that :)

@iamktothek You don’t need node-fetch. The fetch API is built-in meanwhile :-)