Beiträge von AMJ

I found the Pi zero was stressed (CPU wise) doing the most basic hyperion setup. I never checked the delay but the CPU usage made me think again using it as a hyperion server. Like, the same settings on the WP was ~70% usage but the Pi3 is about ~25%.

I used the Wireless zero just for testing but now use a Pi 3+ for the "production" hyperion. And have negligible lag running a ~250 chain LED backlight.

It's not all about CPU usage but even if not, the Pi3 is quad core vs the zero dual core, and the clock speeds are much lower. And to add to that the Pi3 probs has more hardware acceleration than the zero.

But yeah, PI3 for me has negligible lag.

Just to be clear, you are using/installing vanilla PI O/S? Using this tool and selecting one of the built in builds?

On older versions of PI O/S the default username/password was pi/raspberry. However at some point they changed it to prompt for a username/password when installing. In any case in every build I've ever installed it's asked for username and password when SSH'ing to it. I'm not familiar with MacBooks, it's not a user access control window as part of the Mac OS?

This is what it looks like in Putty.

I don't mind helping but this seems to be centred around general Pi (or maybe Mac) help rather than Hyperion. If the Pi can install Hyperion then (assuming you are using apt-get and not a local copy) clearly it can see the internet, and thus the local network, but seems you're struggling to connect from your mac.

I'm relatively new to Hyperion but fair experienced with Raspberry Pis.

I think you need to forget about Hyperion for the time being and focus on getting general network connectivity working on the Pis. If you've tried three Pis and cannot get connectivity working then with the deepest respect it sounds like you need help here, not with Hyperion (yet).

With a fresh install use raspi-config to set the wireless SSID. Set a static IP. Enable SSH. You should be able to SSH in to the IP you set- if you can't SSH then there is no point proceeding with Hyperion as that's not the problem, the problem is network access. Does the Macbook have a built in software firewall? I genuinely do not know. Also if you are using 2.4Ghz make sure your router is set to a static channel that is 11 or below. Above that get's murky; some WiFi points roam using channels 12 & 13 but those are unreliable, at least here in the UK.

If you can't SSH remotely, work on this. If you can SSH then next step would be to make sure Hyperion is running and listening.

user@pi:~ $ netstat -anop |grep 8090
tcp6       0      0 :::8090          :::*       LISTEN      581/hyperiond        off (0.00/0/0)

If Hyperion is running, listening, SSH is enabled and verified as working remotely but you still cannot http to the PI then try accessing hyperion from the PI itself using the built in browser. Try IP:8090, if not localhost:8090 or 127.0.0.1:8090.

If you can access Hyperion locally but not remote then you need to check whatever it is that's blocking your client from accessing the PI on port 8090. Proxy settings? Firewall? Access lists?

Zitat

AMJ As you rightly assumed, the capturing is not throttled currently when a black screen was detected.

That would be a new feature.

Thanks for the confirmation/clarification. I believe it's a valid request for new feature then, though seeing as no one else has requested it then it doesn't seem like it'd be very important.

Zitat

With 2.0.16 you can also use your Remote and put Hyperion into Suspend mode.

Just enable CEC events.

Might be easier and out of the box than a GPIO solution.

Thanks. I'll look into the remote CLI in more detail and will probably be handy for what I am thinking of doing. I'm a special case due to my setup which is why I'm thinking using a GPIO pin to turn on/off Hyperion when going high/low. CEC is a no (my HDMI splitter doesn't support it) and all my entertainment devices share the same 5v supply, some which come on/off with the TV (Via the TV's USB power & a couple of relays) so it's a ready made source for an on/off trigger.

I was just testing really, and something I noticed. Using the above reduces loaded CPU to about 25% and idle to around 13-14%, which is in improvement, but can't help think that it's just wasted resources when it seems to be just watching a black screen for activity. It would be more of a problem, say, if I was using my Pi Zero (all my Pi's are multipurpose so on all the time/servicing other tasks & apps) as it's got much more limited CPU resources.

If there's no appetite to change this (or if I'm wrong entirely) then that's fine. That command line utility looks useful, if the idle CPU usage bothers me in the future I'll throw something together that disables it through a GPIO pin.

Just got into Hyperion and it's great. Very easy to use.

I've put this in feature requests as I believe it's working as intended but I'm seeing high CPU usage (RPI3) even when Hyperion correctly identifies "no signal".

This is idle/suspended. (no Signal)

This is active/processing LED's. (signal detected)

It took some tweaking to identify no signal as my capture card outputs a black screen, but after setting them up it's for sure working fine.

2024-02-05T13:03:12.479Z [V4L2] (INFO) Signal detected
2024-02-05T13:03:12.482Z [LEDDEVICE|Hue Lights] (INFO) Switching device philipshue ON
2024-02-05T13:04:39.151Z [V4L2] (INFO) Signal lost
2024-02-05T13:04:40.070Z [LEDDEVICE|Hue Lights] (INFO) Switching device philipshue OFF

What I think is happening, and I may be wrong, is that Hyperion is still polling the black screen at the same rate it's configured to capture at. So 30fps. The slightly lower CPU usage is probably just because there are less changes to process. Would it better to save CPU resources and poll slower when a no signal state is detected? Even once a second would probably be acceptable for most users. In fact for me, my Firestick takes 10-15 seconds to boot up so every 5 seconds would be fine.

If I'm wrong then I can post in support. It's no major issue, I was going to use a GPIO pin to trigger start/stop the service, and I can see new update has integrated OS event support so probably something I can use in there.

Alternatively, if the above is true but the CPU usage is unavoidable as it's locked to the capture settings (1024x768 MJPG 30FPS) then perhaps an option to switch to a lower capture when detecting no signal? 640x480 YUYV 5FPS is a much more respectable 3-4% CPU usage and Hyperion is able to detect signal. Once it detects, switch back to the higher quality user configured settings.