Project

General

Profile

Actions
Copy link

Bug #916

closed

Autokiosk mode should run piboxd with -I -s -S to disable IoT, smb and camera streams.

Added by Hammel 11 months ago. Updated 11 months ago.

Status:
Closed
Priority:
Immediate
Assignee:
Hammel
Target version:
PiBox - 2.0 - Harkonnen
Start date:
30 Oct 2022
Due date:
% Done:

100%

Estimated time:
Severity:
01 - Critical

Description

This would be done using an update to the cross.sh script and the opkg/Makefile.am to update the S89piboxd init script, just as is done with piplayer, pisentry and xeon.
The pkglist.autokiosk in the meta build would then need to be updated to use the new cross.sh argument.

Related issues

Related to piboxd - Bug #913: Does piboxd take too much CPU?ClosedHammel13 Oct 2022

Actions
Actions
Copy link
 #1

Updated by Hammel 11 months ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 20

piboxd cross.sh has been updated. The build is ready to be tested on an autokiosk system.

Actions
Copy link
 #2

Updated by Hammel 11 months ago

  • % Done changed from 20 to 50

Updated piboxd build works with autokiosk. Needs to be tested against media build as well, to make sure non -a option use still works.

Testing metabuild update to use -a option when building piboxd for autokiosk.

Actions
Copy link
 #3

Updated by Hammel 11 months ago

Spoke too soon. With -I -S -s, piboxd is not only crashing but it causes a full reboot. This is probably due to some of the issues of RM #913.

Actions
Copy link
 #4

Updated by Hammel 11 months ago

  • Related to Bug #913: Does piboxd take too much CPU? added
Actions
Copy link
 #5

Updated by Hammel 11 months ago

Hmmm. This problem may be a dying Pi3 board. I switched to another Pi3 and it seems to be working okay. Will let it run for a bit, switch back and see if the board behaves better after being disconnected for awhile and then see where to go from there.

Actions
Copy link
 #6

Updated by Hammel 11 months ago

Well, it might not be hardware. It may be that the master RPi firmware causes the hardware to heat up and act badly.

I let the original Pi sit idle for awhile, then tested the second Pi with newest firmware. Eventually it locked up (but it took awhile). So I made a new build with the back rev'd firmware and tested on the original Pi. That seems to work fine. It's been running longer now than most of my previous tests with the newest firmware.

It's possible this IS the newest firmware - I got a little mixed up switching SD cards between the two Pis - but I'm pretty sure it's the back rev. To be certain I'm building a new instance of the back rev SD image and will test it too.

Actions
Copy link
 #7

Updated by Hammel 11 months ago

  • Status changed from In Progress to Closed
  • % Done changed from 50 to 100

Yeah, it's a combination of the following:

  • The firmware version - older is better.
  • Overheating - playing the videos appears to overheat the board and it behaves badly after that until it cools down.
  • Possibly having the ethernet connected at boot time.
  • Possibly having a dying USB stick

Once videos start playing the board seems fine. Certainly with the older firmware. So I'll use the older firmware for 2.0 and consider updating when I bump the kernel for later releases.

I disconnected the ethernet for testing just to remove unnecessary components. But it might be that eth use plus video playback is overheating the board. Maybe.

I did not test a second usb stick directly, but two other tests (one test and another production running in the garage) using different USB sticks are working fine and have not shown the problem I'm seeing here.

The changes to piboxd to use -I -s -S certainly reduce CPU overhead and don't appear to be causing any functional problems with video playback.

Changes committed and pushed for both piboxd and metabuild.

This issue can be closed.

Actions
Copy link

Also available in: Atom PDF