Xibo isn't responding / Stuck on home launcher selection after updating

[MrStefan]

After putting a new Android version in the CMS, some of the DSCS9X players display one of the following problems right after the update, or at random some time later. I’ve had this issue with upgrading to R406, R407, R408, and now R409.

1. Xibo isn’t responding
   
   
2. Stuck on home launcher selector (usually resolves after a minute, but not all the time)
   
   

Is there a solution that can automatically detect if the player is in such a state, and resolve it automatically without having to use TeamViewer, SSHelper, or any other remote software?

My own thought is to create a script that would run on the device itself, once it detects one of the two scenarios, it would simply stop the Xibo app and start it again. If someone had already made something like this, I’d love to hear about it!

[MrStefan]

I’ve created a potential solution, but I haven’t been able to fully test it yet.

• The “Xibo is not responding” pop‑up couldn’t be reproduced during testing. To test the script, the search function in the settings app was used instead, which eventually triggers a crash pop‑up for the Settings app.
• For the home launcher, I simulated the behavior by long‑pressing the home button, (closing Xibo), and switching to different apps.

The script I’ve written is as follows:

#!/system/bin/sh

# Startup delay
# Sleep 600

PACKAGE="uk.org.xibo.client"
ACTIVITY="uk.org.xibo.player.Player"
COMPONENT="$PACKAGE/$ACTIVITY"

while true; do
    echo "Monitor loop running"

    # Detect crash in system window manager
    if dumpsys window windows | grep -Ei "Error"; then
        echo "Crash detected — rebooting"
        reboot
    fi

    # Check if Xibo process is running
    if ! pgrep -f "$PACKAGE" >/dev/null; then
        echo "Xibo not running — starting"
        am start -n "$COMPONENT"
    else
        echo "Xibo running - bringing to foreground"
        am start -a android.intent.action.MAIN \
                 -c android.intent.category.LAUNCHER \
                 -n "$COMPONENT"
    fi

    sleep 300
done

As of now I haven’t yet found a way to run this script at boot, and if I do, I want the solution to be something that can be set up using commands sent directly from the CMS.