deviceshelf

joined 1 month ago
[–] deviceshelf@lemmy.world 3 points 2 weeks ago (2 children)

Here's the shape, if it saves you the fiddling. Put it in the compose file rather than a cron:

healthcheck:
  test: ["CMD-SHELL", "wget -qO- http://localhost:3000/api/v1/trending >/dev/null || exit 1"]
  interval: 5m
  timeout: 10s
  retries: 3
restart: unless-stopped

Port and path to match your setup, and use wget rather than curl unless you know the image ships curl, since a healthcheck that fails because the binary is missing looks exactly like a service that is down.

One catch: Docker marks a container unhealthy but won't restart it for you. Either pair it with something like autoheal, which watches for that state, or keep your cron and have it check first and restart only on failure.

Either way you get the thing the blind hourly restart can't give you: a log of how often it actually fired. Never, and you didn't need the restarts. Constantly, and there's a real bug worth chasing rather than a schedule papering over it.

[–] deviceshelf@lemmy.world 1 points 2 weeks ago (4 children)

That line predates invidious-companion. When the player and signature handling still lived in the main process, a periodic kick was the honest workaround, and the docs never really caught up after companion split it out.

What I'd push back on is the blind hourly restart, because it hides exactly the failure you just had. A companion image sitting a version behind shows up as things half-working, and a scheduled restart makes that go away for an hour at a time, so you never trace it. If you're going to script something, script a check instead: hit an endpoint that actually plays a video, restart only when that fails, and log it when it does. Then a restart tells you something happened.

Small thing that would have caught your case: docker compose pull with no service name pulls all three, and docker compose images prints the digests you're actually running.

 

I'm the developer. Some of you saw my earlier posts about DeviceShelf, the local-first network scanner with a headless server edition. The iOS app just cleared App Store review, so you no longer need TestFlight to run it.

It's the same scanning engine as the desktop app: network scan, device identification, open ports per device, a security report, presence alerts, and export/share from the phone. Apple's multicast entitlement is active in this build, which means SSDP/UPnP discovery works on iOS as well.

The download is free with a trial. Full features unlock with a DeviceShelf license (one license covers desktop, mobile and server) or through an in-app purchase. Scans stay on the device; the AI device ID is bring-your-own-key.

App Store: https://apps.apple.com/app/deviceshelf/id6779666567

Still a young app. If it mislabels something on your network, tell me and I'll fix it.

[–] deviceshelf@lemmy.world 2 points 3 weeks ago

Before you redo the rest by hand, check whether the broken ones share a format. Black frames that render fine on the phones but not in a desktop browser usually mean the original file is intact and it was the server-side preview that failed to generate, with the phones quietly decoding the original themselves. HEIC and HEVC and 10-bit HDR are the usual suspects, since those lean on libheif and ffmpeg on the server and older builds choke on them.

If that's the cause, re-uploading only "works" because it reruns preview generation, so you're really just triggering a fresh encode. Grep the museum logs around one of the bad files for a decode error, and see whether a rescan or clearing the thumbnail cache regenerates them in place. That would save you doing the whole library one file at a time.

[–] deviceshelf@lemmy.world 2 points 3 weeks ago

Your own calculation is the thing that should pick the machine. At 0.35 EUR/kWh a single watt running around the clock costs roughly 3 EUR a year, so the gap between a 25 W old laptop and an 8 W mini PC is about 50 EUR a year, or 260 EUR over five years. Half your hardware budget, paid in electricity.

That's also why cheap used enterprise gear tends to be a trap at German prices: low purchase price, 40 W at idle. An N100 or N150 box with 16 GB and an NVMe drive sits around 6 to 10 W idle and fits inside 500 EUR comfortably. On the storage side, two 3.5" disks add something like 8 to 12 W if they never spin down, so spindown is worth configuring when access is bursty, and if your data fits on SSDs the power question mostly goes away.

[–] deviceshelf@lemmy.world 2 points 3 weeks ago (1 children)

The bland logs are themselves a data point. If the journal just stops mid-line with nothing unusual before it, that points at a hard hang or a power cut rather than something userspace did, because a kernel oops normally leaves a trace behind. There's also a catch-22 in the SD theory: a card that's failing can't reliably write the log that would prove it's failing.

Two things worth doing before the card swap, both cheap. Check vcgencmd get_throttled: bit 16 stays set if undervoltage happened at any point since boot, so you get an answer on power-versus-card without having to catch the crash live. And switch on the hardware watchdog, bcm2835_wdt plus RuntimeWatchdogSec in systemd, so the Pi resets itself instead of waiting for someone to pull the plug. That doesn't fix the cause, but it stops every crash from becoming an outage that lasts until you're back home.

 

I'm the developer. DeviceShelf scans your LAN and tells you what each device is: vendor, type, open ports, and a per-device security report. It runs on macOS, Windows, Linux, iOS and Android, and there's a headless server edition (Docker + .deb) for 24/7 monitoring with ntfy, Gotify or webhook alerts.

It's local-first: nothing about your network leaves your machine unless you turn on an opt-in feature, there's no account, and the AI device ID uses your own API key. One-time purchase, with a trial.

It's still a young project, so bug reports and feedback are very welcome. If something looks off on your network, tell me and I'll fix it. Happy to answer questions too.