The status check was showing "Not installed" even after successful
installation because it relied on PATH and file checks that weren't
working reliably.
Changes:
- Check for /etc/systemd/system/talkkonnect.service first
- This is the most reliable indicator of installation
- Systemd service file is created during install and requires root
- Falls back to command/file checks if service file doesn't exist
This ensures status shows correctly immediately after installation.
Fixes "Text file busy" error and "Not installed" status:
1. **Stop service before install** (lines 535-547)
- Check if talkkonnect service is running
- Stop systemd service if active
- Kill any stray processes
- Sleep 1 second to ensure file is released
- Then copy the new binary
2. **Fix status check** (line 72)
- Changed from $HOME/go/bin/talkkonnect
- To /home/$KIOSK_USER/go/bin/talkkonnect
- Now correctly detects installed binary
3. **Separate build and install steps**
- Build completes inside first sudo block
- Installation happens in second sudo block after stopping service
- Clean error handling for each step
This matches the working talkkonnect_complete_install.sh approach.
The build was succeeding but the post-build verification was failing
because it tried to check /home/kiosk/talkkonnect-binary from outside
the sudo -u kiosk block.
Changes:
- Move binary verification and installation inside the sudo -u block
- Use ~ instead of /home/$KIOSK_USER (more reliable inside sudo)
- Remove redundant chmod/chown after sudo block
- Binary now installed while running as kiosk user
This matches the approach from talkkonnect_complete_install.sh where
all file operations happen inside the user context.
Changed from /tmp to ~/talkkonnect to match working script approach:
- Clone to /home/$KIOSK_USER/talkkonnect instead of /tmp/talkkonnect-src
- Build to ~/talkkonnect-binary then copy to ~/go/bin/talkkonnect
- Run all operations as kiosk user from the start
- No chown needed - user owns their own home directory
This eliminates all "Permission denied" errors when:
- Creating vendor directory
- Removing old source files
- Building the binary
Matches the proven approach from talkkonnect_complete_install.sh
Added chown after git clone to give kiosk user ownership of the
/tmp/talkkonnect-src directory. This allows 'go mod vendor' to
successfully create the vendor directory when running as kiosk user.
Without this fix, the build would fail with:
"go: mkdir /tmp/talkkonnect-src/vendor: permission denied"
"Warning: gopus not found in vendor directory"
"[ERROR] Binary not executable after build"
Critical fixes to resolve "[ERROR] Binary not executable after build":
1. **Opus x86_64 Compatibility Patch**
- Added gopus library patch to use system libopus for x86_64
- The embedded Opus source in gopus is ARM-optimized and incomplete for x86_64
- Now uses pkg-config to link against system libopus library
2. **Vendored Dependencies**
- Added `go mod vendor` to create vendored dependencies
- Build now uses `-mod=vendor` flag to ensure patched gopus is used
3. **Enhanced Build Process**
- Set CGO_CFLAGS and CGO_LDFLAGS for proper Opus compilation
- Build in cmd/talkkonnect directory (correct location)
- Added build-essential and pkg-config to dependencies
4. **Improved XML Configuration**
- Updated to modern talkkonnect/xml document type
- Added critical voicetargets section to prevent crashes
- Added proper global settings structure
- Created .config/talkkonnect directory for logs
5. **Additional Dependencies**
- Added libopus0, libopusfile-dev for complete Opus support
- Added build-essential and pkg-config for compilation
This integrates the working approach from talkkonnect_complete_install.sh
into the setup_intercom.sh script.
Changes:
- Add SCRIPT_DIR variable for locating companion scripts
- Update addon_talkkonnect_intercom() to launch setup_intercom.sh
- Replace 134 lines of duplicate code with 30-line integration
- Update INTERCOM_README.md with clear usage instructions
Benefits:
- Single source of truth for intercom functionality
- Easier maintenance (update only setup_intercom.sh)
- Cleaner separation: install_kiosk handles UBK, setup_intercom handles intercom
- Both scripts work standalone or together automatically
Usage:
- Option 1: Run install_kiosk_0.9.6.sh → Addons → Intercom (option 4)
- Option 2: Run setup_intercom.sh directly
- Both scripts must be in same directory (automatic when cloning repo)
Created modular, standalone intercom system to avoid bloating the
10,000+ line main install script.
New Files:
- setup_intercom.sh: Complete standalone installation and management
* Install Murmur server (one kiosk becomes the server)
* Install talkkonnect client (connect to existing server)
* Install both (all-in-one setup)
* Full service management (start/stop/restart)
* Configuration tools
* Log viewing
* Uninstall options
- INTERCOM_README.md: Comprehensive documentation
* Quick start guide
* Use cases and scenarios
* Multi-kiosk setup instructions
* Troubleshooting guide
* Integration instructions
* Technical details
- integrate_intercom.sh: Integration helper
* Shows how to wire into main install script
* Example menu integration code
* Alternative sourcing method
Features:
✓ Menu-driven interface with dynamic options
✓ Status display (installed/running state)
✓ Server configuration (password, port, welcome text)
✓ Client configuration (server, credentials, channel)
✓ Service management (enable/disable/start/stop)
✓ Log viewing for diagnostics
✓ Clean uninstallation
Use Cases:
1. Single kiosk (server + client)
2. Multi-kiosk (one server, multiple clients)
3. Connect to external Mumble server
4. Other devices can connect (desktop/mobile Mumble apps)
Technical:
- Murmur server on port 64738
- talkkonnect built from source with Go
- Systemd service management
- Audio through ALSA/PipeWire
- PTT via keyboard (default: spacebar)
Next Steps:
- Test installation on clean system
- Wire into main install script addon menu
- Consider auto-discovery for multi-kiosk setups
The installation prompt was only accepting lowercase 'y', causing the
script to exit when users entered uppercase 'Y'. This fix aligns the
prompt behavior with all other y/n prompts in the script by using
case-insensitive pattern matching (=~ ^[Yy]$).
Fixes issue where installation would bail after selecting Y to proceed.
Fixes JavaScript error "given browserview is not attached to the window"
that occurred when unlocking the screen after boot with password protection.
Changes to unlockScreen() function:
- Add try-catch around hidden view restoration to prevent crashes
- Ensure view is attached with addBrowserView() before setTopBrowserView()
- Add fallback to regular views if hidden view restoration fails
- Validate currentIndex is within bounds before using it
- Check views.length>0 before attempting to attach views
This ensures safe view restoration in all unlock scenarios, particularly
when unlocking immediately after boot with password protection enabled.
Key changes:
- Remove time-based lockout prompt ("Only enforce lockout during specific hours?")
- Detach all browser views when locked to prevent content visibility
- Show power menu on solid black screen (lockoutWindow) when locked
- Password protection now always active when enabled (more reliable)
Fixes:
- Users can no longer see URLs or content when password screen is active
- Pressing Ctrl+Alt+Delete shows power menu on solid screen, not over content
- All browser views completely hidden until password is entered
CRITICAL FIX: Removed lockoutActivityTime reset from markActivity()
- markActivity() was resetting lockoutActivityTime on EVERY activity
- This prevented inactivity lockout from EVER triggering
- Now lockout timer only resets when user unlocks or selects extension
ROOT CAUSE:
The markActivity() function was resetting lockoutActivityTime (line 3904):
if(enablePasswordProtection && lockoutTimeout > 0){
lockoutActivityTime = now; // ← PROBLEM
}
markActivity() is called on EVERY:
- Mouse move
- Mouse click
- Keyboard press
- Page load
- Focus change
Result: lockoutActivityTime was CONSTANTLY being reset, so lockout could
NEVER reach the configured timeout (user reported 17 minutes wasn't working).
FIX:
Removed the lockoutActivityTime reset from markActivity() entirely (line 3908).
Now lockoutActivityTime only resets when:
1. User unlocks screen (unlockScreen() function)
2. User selects time extension (showPauseDialog/showInactivityPrompt)
This is the correct, simple behavior: lockout should trigger after X minutes
of inactivity, period. If user wants to extend, they can select an extension.
USER REPORT:
- Scheduled lockout works ✓ (lock at 15:00)
- Inactivity lockout doesn't work ✗ (lock after 17 min idle)
- This fix addresses the inactivity lockout issue
SIMPLIFIED: Removed unnecessary complexity added in v0.9.5-7 and v0.9.5-8.
The simple fix was just to stop resetting the timer on every activity.
CRITICAL FIX: Extensions now properly reset lockout activity timer
- Pause button extensions now reset lockoutActivityTime when selected
- Manual site timeout extensions now reset lockoutActivityTime when selected
- Prevents lockout from counting idle time accumulated BEFORE extension
- Lockout timer now truly starts fresh when user selects an extension
ROOT CAUSE (v0.9.5-7 was incomplete):
In v0.9.5-7, I added code to checkLockoutTimer() to SKIP lockout checks during
active extensions. This prevented lockout from triggering during the extension
period. However, the extension handlers themselves didn't reset lockoutActivityTime.
TWO PLACES WERE MISSING lockoutActivityTime reset:
1. showInactivityPrompt() - Manual site timeout extensions (line 4632)
When user selects "15 minutes" on manual site inactivity prompt:
✓ Set inactivityExtensionUntil = now + 15min
✓ Set lastUserInteraction = now
✓ Set siteStartTime = now
✗ Did NOT set lockoutActivityTime = now
2. showPauseDialog() - Pause button extensions (line 4680)
When user clicks pause button and selects "15 minutes":
✓ Set inactivityExtensionUntil = now + 15min
✓ Set lastUserInteraction = now
✓ Set siteStartTime = now
✗ Did NOT set lockoutActivityTime = now
BROKEN SCENARIO IN v0.9.5-7:
- Lockout configured for 30 minutes of inactivity
- User is idle for 10 minutes
- User clicks "15 minutes" extension
- lockoutActivityTime still shows 10 minutes ago (NOT reset)
- Extension blocks lockout for 15 minutes (v0.9.5-7 fix working)
- After 15 minutes, extension expires
- v0.9.5-7 code resets lockoutActivityTime to now
- Lockout would happen 30 minutes later
The problem: This means lockout NEVER enforced the configured timeout if
users kept selecting extensions, because each extension expiration reset
the lockout timer.
FIX IN v0.9.5-8:
Added lockoutActivityTime = now to BOTH extension handlers:
- Lines 4637-4641: Manual site inactivity prompt extension handler
- Lines 4684-4688: Pause button extension handler
NEW BEHAVIOR:
- User idle for 10 minutes
- User clicks "15 minutes" extension
- lockoutActivityTime = now (RESET on extension selection)
- User is now considered "active" (selected extension = user interaction)
- Extension blocks lockout for 15 minutes
- After 15 minutes, lockoutActivityTime shows 15 minutes ago
- Lockout happens 30 minutes after extension selected (at 15 + 30 = 45 min total)
This is more intuitive: selecting an extension is a user interaction that
proves the user is present, so lockout timer should start fresh.
Includes all fixes from v0.9.5-7 (checkLockoutTimer respects extensions)
CRITICAL FIX: Inactivity lockout now respects time extensions
- Lockout timer was completely ignoring pause button extensions
- Lockout timer was ignoring manual site timeout extensions
- Added inactivityExtensionUntil check to checkLockoutTimer() function
- Time extensions now properly prevent BOTH site timeout AND lockout
- When extension expires, lockout timer resets (doesn't trigger immediately)
FIXED: Manual sites (duration: 0) now fully support time extensions
- Pause button extensions now work on manual sites
- Manual site timeout extensions now prevent lockout
- Extensions apply to both rotation blocking AND lockout prevention
ROOT CAUSE:
The checkLockoutTimer() function (line 4061) only checked:
- lockoutActivityTime vs lockoutTimeout
- Did NOT check inactivityExtensionUntil
This meant when a user clicked "15 minutes" on pause button:
✓ Site rotation/timeout was blocked (lines 4317, 4375 checked extension)
✗ Inactivity lockout still triggered after configured time
EXAMPLE SCENARIO THAT WAS BROKEN:
- Manual site with 2 min inactivity timeout to return home
- Lockout after 5 minutes of inactivity
- User idle for 1m 50s, clicks "15 minutes" extension
- Expected: Can stay for 15 more minutes
- Actual v0.9.5-6:
* Home return prompt blocked ✓
* Lockout happens at 5 min idle ✗
- Fixed v0.9.5-7:
* Home return prompt blocked ✓
* Lockout also blocked for 15 min ✓
FIX (lines 4083-4100):
Now checkLockoutTimer() checks inactivityExtensionUntil FIRST:
1. If within extension period: return early (skip lockout check)
2. If extension just expired: reset lockoutActivityTime (prevent immediate trigger)
3. Then check normal lockout timeout
This matches the pattern used in rotation (line 4317) and home return (line 4375).
Includes all fixes from v0.9.5-6 (boot password sequence, limited power menu)
CRITICAL SECURITY FIX#1: Boot password now required BEFORE showing websites
- Password screen now appears IMMEDIATELY on boot (no website flash)
- Websites and rotation timer only start AFTER successful password entry
- Root cause: attachView() was called before checking boot flag
- Fix: Reordered code to check boot flag FIRST, only call attachView() if no boot
- unlockScreen() now starts master timer when unlocking from boot password
CRITICAL SECURITY FIX#2: Limited power menu when locked out
- Ctrl+Alt+Del when locked now shows LIMITED menu: Shutdown/Restart/Cancel
- NO Reload option available when locked (prevents bypass)
- Full menu (with Reload) only available when unlocked
- Still allows emergency shutdown/restart without password
- Message clearly indicates "System is locked. Limited options available."
ROOT CAUSE OF BOOT PASSWORD BYPASS:
In v0.9.5-5, the code sequence was:
1. attachView(startIndex) - shows website
2. Check boot flag - if exists, show password screen
This meant users saw the website for ~1 second, then password screen appeared.
Pressing Ctrl+Alt+Del at that moment would reload and bypass the password.
NEW SEQUENCE in v0.9.5-6:
1. Check boot flag FIRST
2. If boot flag exists: show password screen, DON'T load websites
3. If no boot flag: load websites normally
4. When password entered: attachView() and startMasterTimer()
Includes all fixes from v0.9.5-5 and v0.9.5-4
CRITICAL SECURITY FIX:
- Fixed Ctrl+Alt+Del bypassing boot password requirement
* Added isLockedOut check to showPowerMenu() function
* Power menu (Shutdown/Restart/Reload) now blocked when system is locked out
* Prevents bypassing boot password via Reload option
* Also prevents bypassing inactivity lockout and time-based lockout
ROOT CAUSE:
The showPowerMenu() function was missing the isLockedOut check that other
navigation functions (nextTab, prevTab) already had. This allowed users to
press Ctrl+Alt+Del during boot password screen, select "Reload", and bypass
the password requirement entirely.
NAVIGATION TROUBLESHOOTING:
Added troubleshooting notes for users experiencing navigation issues:
- Check config.json for hidden sites (duration: -1)
- Hidden sites don't count toward navigation
- Need at least 2 visible sites for Ctrl+Tab/swipe to work
Includes all fixes from v0.9.5-4 (polkit restrictions, X server hardening,
autostart compatibility, xbindkeys fixes)
This was the root cause of extensions not working. When user clicked
extension buttons (15 min, 30 min, etc.), that click triggered markActivity()
which immediately cleared the extension that was just set.
Now extensions work correctly - they only expire when:
- Time runs out naturally
- User explicitly goes home
- User cancels the extension
This fixes:
- Pause button extensions not working (rotating after 1 min)
- Manual site timeout extensions not working (prompt after 1 min)
- Both rotation and inactivity timer extensions
Claude