dashcam 1.4.13-beta.2 → 1.4.13-beta.3

package/bin/dashcam.js

@@ -460,8 +460,6 @@ program
   .description('Stop the current recording and wait for upload completion')
   .action(async () => {
 
-    console.log('!!!! Updated Stop')
-
     try {
       // Enable verbose logging for stop command
       setVerbose(true);

package/lib/recorder.js

@@ -469,10 +469,10 @@ export async function startRecording({
     });
 
     if (currentRecording.all) {
-      currentRecording.all.setEncoding('utf8');
       currentRecording.all.on('data', (data) => {
         // Parse FFmpeg output for useful information
-        const output = data.toString().trim();
+        // Handle potentially invalid UTF-8 sequences by replacing them
+        const output = data.toString('utf8').replace(/\uFFFD/g, '').trim();
         logger.info(`FFmpeg output: ${output}`);
         
         // Check for actual permission issues (not fallback messages)

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "dashcam",
-  "version": "1.4.13-beta.2",
+  "version": "1.4.13-beta.3",
   "description": "Minimal CLI version of Dashcam desktop app",
   "main": "bin/dashcam.js",
   "bin": {

package/LINUX_PERF_FIX.md

@@ -1,184 +0,0 @@
-# Linux Performance Tracking Fixes
-
-## Problem
-Performance data from dashcam-cli-minimal was not working on Ubuntu Linux.
-
-## Root Causes Identified
-
-### 1. **ps command compatibility**
-- Some Linux distributions (especially minimal/container images) use BusyBox `ps` which doesn't support the `--sort` option
-- The code was failing when trying to use `ps --sort=-pcpu`
-
-### 2. **Missing error handling**
-- Insufficient logging made it hard to diagnose where the performance tracking was failing
-- No fallback mechanisms when certain system calls failed
-
-### 3. **Network metrics parsing**
-- The macOS netstat parsing had an off-by-one error in the parts length check
-- Could cause network metrics to fail silently
-
-### 4. **Import optimization**
-- The Linux network code was using `await import('fs')` dynamically when `fs` was already imported at the top
-
-## Fixes Applied
-
-### topProcesses.js
-1. **Added fallback for ps --sort**:
-   ```javascript
-   try {
-     // Try with --sort first
-     const result = await execFileAsync('ps', ['-eo', 'pid,pcpu,pmem,comm', '--sort=-pcpu'], ...);
-   } catch (sortError) {
-     // Fallback to unsorted and sort in JavaScript
-     const result = await execFileAsync('ps', ['-eo', 'pid,pcpu,pmem,comm'], ...);
-   }
-   ```
-
-2. **Improved parsing with filtering**:
-   - Now filters out invalid entries (pid <= 0)
-   - Handles missing/undefined CPU and memory values
-   - Always sorts by CPU in JavaScript as a backup
-
-3. **Added timeouts**:
-   - All process listings now have 5-10 second timeouts to prevent hanging
-
-### performanceTracker.js
-1. **Fixed network metrics**:
-   - Corrected macOS netstat parsing (parts.length >= 10 instead of >= 7)
-   - Removed redundant `await import('fs')` on Linux
-   - Already using `fs` from the top-level import
-
-2. **Enhanced error handling**:
-   - All metric collection methods now have comprehensive try/catch blocks
-   - Graceful degradation - if one metric fails, others continue
-   - Better logging with platform and error context
-
-3. **Improved logging**:
-   - Added debug logs for successful operations
-   - More detailed error messages including platform info
-   - Stack traces for debugging
-
-## Testing
-
-### Quick Test (10 seconds)
-```bash
-cd dashcam-cli-minimal
-node test-perf-linux.js
-```
-
-This will:
-- Test `pidusage` library
-- Test `getTopProcesses` function
-- Test network metrics reading
-- Test system metrics
-- Run full performance tracker for 10 seconds
-- Show detailed results and identify any failures
-
-### Full Recording Test
-```bash
-# Start a recording with performance tracking
-dashcam start
-
-# Do some work for 10-15 seconds
-# ...
-
-# Stop recording  
-dashcam stop
-
-# Check the output for performance data
-```
-
-### Expected Output
-The test should show:
-```
-✓ pidusage: PASS
-✓ topProcesses: PASS  
-✓ networkMetrics: PASS
-✓ systemMetrics: PASS
-✓ performanceTracker: PASS
-
-Overall: ✓ ALL TESTS PASSED
-```
-
-## Platform-Specific Notes
-
-### Ubuntu/Debian
-- Should work on all versions
-- Uses `/proc/net/dev` for network stats
-- Falls back if `ps --sort` not available
-
-### Alpine Linux / Docker
-- BusyBox `ps` detected automatically
-- Sorts processes in JavaScript instead
-- May have limited network stats in containers
-
-### CentOS/RHEL
-- Full GNU ps support
-- Should use `--sort` option
-- Full network stats available
-
-## Troubleshooting
-
-### If performance data is still empty:
-
-1. **Check pidusage works**:
-   ```bash
-   node -e "import('pidusage').then(m => m.default(process.pid).then(console.log))"
-   ```
-
-2. **Check ps command**:
-   ```bash
-   ps -eo pid,pcpu,pmem,comm --sort=-pcpu | head -5
-   # If this fails, try:
-   ps -eo pid,pcpu,pmem,comm | head -5
-   ```
-
-3. **Check /proc/net/dev exists**:
-   ```bash
-   cat /proc/net/dev
-   ```
-
-4. **Run with verbose logging**:
-   ```bash
-   dashcam start --verbose
-   # ... do work ...
-   dashcam stop --verbose
-   ```
-
-5. **Check the performance file directly**:
-   ```bash
-   # Look for performance.jsonl in the output directory
-   cat ~/.dashcam/recordings/*/performance.jsonl | head -1 | jq
-   ```
-
-## What Gets Tracked
-
-Even with the fixes, the following is tracked every 5 seconds:
-
-- ✅ Process CPU usage (dashcam process)
-- ✅ Process memory usage (dashcam process)
-- ✅ System-wide memory usage
-- ✅ System CPU core count
-- ✅ Top 10 processes by CPU
-- ✅ Network I/O (where available)
-
-## API Upload
-
-The performance data is uploaded to the API with the recording:
-
-```javascript
-{
-  performance: {
-    samples: [...], // Array of samples taken during recording
-    summary: {      // Aggregated statistics
-      avgProcessCPU: 12.3,
-      maxProcessCPU: 18.7,
-      avgProcessMemoryMB: 128.0,
-      maxProcessMemoryMB: 192.0,
-      // ...
-    }
-  }
-}
-```
-
-This data is then displayed in the web UI under the "Performance" tab.

package/LOG_TRACKING_GUIDE.md

@@ -1,225 +0,0 @@
-# Dashcam CLI - Log Tracking Guide
-
-The Dashcam CLI can track both **file-based logs** (from CLI applications) and **web browser logs** (from browser extensions). This guide explains how to use the log tracking features.
-
-## File Log Tracking (CLI Applications)
-
-### Adding Log Files to Track
-
-Track log files during recordings:
-
-```bash
-# Add a single log file
-dashcam logs --add /var/log/myapp.log
-
-# Add multiple log files
-dashcam logs --add /tmp/debug.log
-dashcam logs --add ~/.npm/_logs/npm.log
-dashcam logs --add /var/log/nginx/access.log
-```
-
-### Removing Log Files
-
-```bash
-# Remove a log file from tracking
-dashcam logs --remove /var/log/myapp.log
-```
-
-### Viewing Tracked Files
-
-```bash
-# List all currently tracked log files
-dashcam logs --list
-
-# Show detailed tracking status
-dashcam logs --status
-```
-
-## Web Browser Log Tracking
-
-### Setting Up Web App Tracking
-
-Web log tracking requires configuring patterns for URLs you want to monitor:
-
-```bash
-# Create a config file for web apps (web-logs.json)
-cat > web-logs.json << 'EOF'
-[
-  {
-    "id": "my-web-app",
-    "type": "web",
-    "name": "My Web Application",
-    "enabled": true,
-    "patterns": [
-      "*localhost:3000*",
-      "*myapp.com*",
-      "*staging.myapp.com*"
-    ]
-  },
-  {
-    "id": "github",
-    "type": "web", 
-    "name": "GitHub",
-    "enabled": true,
-    "patterns": [
-      "*github.com*"
-    ]
-  }
-]
-EOF
-```
-
-### Updating Web Log Configuration
-
-```javascript
-// In your Node.js script or through the API
-import { logsTrackerManager } from './lib/logs/index.js';
-
-const webConfig = [
-  {
-    id: 'my-app',
-    type: 'web',
-    name: 'My Application',
-    enabled: true,
-    patterns: ['*localhost:3000*', '*myapp.com*']
-  }
-];
-
-logsTrackerManager.updateLogsConfig(webConfig);
-```
-
-## Recording with Log Tracking
-
-### Start a Recording with Logs
-
-```bash
-# Start recording (logs are automatically included if configured)
-dashcam record --duration 30
-
-# The recording will include:
-# - All tracked log files (--add files above)
-# - Web browser events (if browser extension is installed)
-```
-
-### Browser Extension Setup
-
-1. **Install the Dashcam browser extension** (Chrome/Firefox)
-2. **The CLI automatically starts a WebSocket server** on ports: 10368, 16240, 21855, 24301, or 25928
-3. **Extension connects automatically** when CLI is running
-4. **Web events are captured** based on your URL patterns
-
-## Log Event Types
-
-### File Logs
-- **Line events**: Each new line written to tracked files
-- **Timestamps**: Precise timing for synchronization with video
-- **Error detection**: Automatic highlighting of error lines
-
-### Web Logs  
-- **Console logs**: `console.log()`, `console.error()`, etc.
-- **Network requests**: HTTP requests and responses
-- **Navigation events**: Page loads and URL changes
-- **Tab management**: Tab switches and window focus
-
-## Example Workflow
-
-```bash
-# 1. Add log files to track
-dashcam logs --add /var/log/myapp.log
-dashcam logs --add /tmp/debug.log
-
-# 2. Check status
-dashcam logs --status
-# Output:
-# Log tracking status:
-#   Active recording instances: 0
-#   Configured CLI log files: 2
-#   Total recent events: 15
-#   File tracker details:
-#     /var/log/myapp.log: 8 events (last minute)
-#     /tmp/debug.log: 7 events (last minute)
-
-# 3. Start recording
-dashcam record --duration 60
-
-# 4. During recording:
-# - CLI monitors all tracked log files in real-time
-# - Browser extension sends web events via WebSocket
-# - All events are timestamped and synchronized
-
-# 5. After recording:
-# - Logs are automatically trimmed to match video duration
-# - Events are saved in JSONL format alongside video
-# - Logs can be replayed in sync with video
-```
-
-## Advanced Configuration
-
-### Custom WebSocket Port
-
-```javascript
-// If you need to use specific ports
-import { server } from './lib/websocket/server.js';
-await server.start(); // Uses predefined port list
-```
-
-### Pattern Matching for Web Apps
-
-Patterns support wildcards:
-- `*example.com*` - Matches any URL containing "example.com"
-- `*localhost:3000*` - Matches local development server
-- `*github.com/myuser/*` - Matches specific GitHub paths
-
-### Log File Requirements
-
-- **Files must exist** before adding to tracking
-- **Files must be readable** by the CLI process  
-- **Real-time writes** are monitored (uses `tail` library)
-- **Log rotation** is automatically handled
-
-## Troubleshooting
-
-### Common Issues
-
-1. **"Log file does not exist"**
-   ```bash
-   # Ensure file exists first
-   touch /var/log/myapp.log
-   dashcam logs --add /var/log/myapp.log
-   ```
-
-2. **"WebSocket connection failed"** 
-   - Check that browser extension is installed
-   - Verify no firewall blocking local ports
-   - Ensure CLI is running when opening browser
-
-3. **"No events captured"**
-   ```bash
-   # Check if files are being written to
-   tail -f /var/log/myapp.log
-   
-   # Verify tracking status
-   dashcam logs --status
-   ```
-
-### Getting Help
-
-```bash
-# Show all log tracking options
-dashcam logs --help
-
-# Show general CLI help
-dashcam --help
-```
-
-## Integration with Recordings
-
-When you create a recording, all configured logs are:
-
-1. **Automatically included** in the recording
-2. **Synchronized** with video timestamps  
-3. **Trimmed** to match video start/end times
-4. **Saved** in JSON Lines format for replay
-5. **Uploaded** along with video files
-
-The result is a complete recording with both visual and log context, making debugging and analysis much more effective.

package/NPM_PUBLISH_FIX.md

@@ -1,104 +0,0 @@
-# NPM Publish & Version Sync Issues
-
-## Problem
-
-The npm publish workflow was failing with:
-```
-npm error 404 'dashcam@1.0.1-beta.17' is not in this registry.
-```
-
-## Root Cause
-
-**Version drift** between local git tags, package.json, and npm registry:
-
-- **NPM registry**: `1.0.1-beta.13` (latest successfully published)
-- **Local package.json**: `1.0.1-beta.16` (from failed publish attempts)
-- **Git tags**: Only up to `v1.0.1-beta.9`
-
-This happened because the workflow:
-1. Bumped version in package.json
-2. Created git tag
-3. Tried to publish
-4. **Publish failed** (possibly due to test failures or video encoding issues)
-5. Git changes were not reverted, leaving version incremented
-
-## Fixes Applied
-
-### 1. Updated Publish Workflow
-
-**Before**: Version bump → Push → Publish (wrong order!)
-
-**After**: 
-1. Sync with npm registry version
-2. Bump version
-3. **Publish first** ✅
-4. Push only if publish succeeded ✅
-
-```yaml
-- name: Bump version
-  run: |
-    # Get current version from npm
-    CURRENT_NPM_VERSION=$(npm view dashcam dist-tags.beta)
-    
-    # Sync before bumping
-    npm version $CURRENT_NPM_VERSION --no-git-tag-version --allow-same-version
-    
-    # Bump to next
-    npm version prerelease --preid=beta
-
-- name: Publish to npm
-  run: npm publish --access public --tag beta
-
-- name: Push changes  # Only runs if publish succeeded
-  run: git push --follow-tags
-```
-
-### 2. Created Version Sync Script
-
-`scripts/sync-version.sh` - Helps detect and fix version drift:
-
-```bash
-./scripts/sync-version.sh
-```
-
-This will:
-- Compare local version with npm registry
-- Offer to sync package.json
-- Show unpublished git tags that need cleanup
-
-### 3. Synced package.json
-
-Reset from `1.0.1-beta.16` → `1.0.1-beta.13` (current npm version)
-
-## Video Issue Connection
-
-The failed publishes were likely caused by **test failures due to the video encoding bugs** we fixed:
-
-- Frame rate conflicts
-- Buffer size issues
-- Frame dropping
-- Incomplete container metadata
-
-All of these are now fixed in the recorder.js, so future CI runs should succeed.
-
-## Next Steps
-
-1. ✅ Package.json is synced
-2. ✅ Workflow is fixed
-3. ⚠️  Need to clean up unpublished git tags manually (optional):
-
-```bash
-# List tags
-git tag | grep beta
-
-# Delete local tags for unpublished versions (14-16)
-git tag -d v1.0.1-beta.14 v1.0.1-beta.15 v1.0.1-beta.16
-
-# If they exist on remote, delete them
-git push origin :refs/tags/v1.0.1-beta.14
-git push origin :refs/tags/v1.0.1-beta.15
-git push origin :refs/tags/v1.0.1-beta.16
-```
-
-4. Push the fixes to trigger a new publish
-5. Next version will be `1.0.1-beta.14` ✅

package/PERFORMANCE_TRACKING.md

@@ -1,139 +0,0 @@
-# Performance Tracking
-
-The Dashcam CLI now includes comprehensive performance tracking during recordings. This feature monitors CPU and memory usage throughout the recording session and includes the data in the log files.
-
-## What's Tracked
-
-### 1. Dashcam Process Metrics
-- **CPU Usage**: Percentage of CPU used by the Dashcam process
-- **Memory Usage**: Memory consumed by the Dashcam process in bytes and MB
-- **Process Info**: PID, parent PID, CPU time, elapsed time
-
-### 2. System-Wide Metrics
-- **Total Memory**: System total and free memory
-- **Memory Usage Percentage**: Overall system memory utilization
-- **CPU Count**: Number of CPU cores available
-
-### 3. Top Processes
-- **Top 10 by CPU**: The most CPU-intensive processes running on the system
-- **Top 10 by Memory**: The most memory-intensive processes running on the system
-- **Process Details**: For each top process, tracks:
-  - Process name
-  - PID
-  - CPU usage percentage
-  - Memory usage in bytes
-  - Parent process ID
-  - CPU time and elapsed time
-
-## Sampling Frequency
-
-Performance metrics are sampled every **1 second** (1000ms) during the recording session.
-
-## Output Format
-
-Performance data is included in the recording result with the following structure:
-
-```javascript
-{
-  performance: {
-    samples: [
-      {
-        timestamp: 1700000000000,
-        elapsedMs: 1000,
-        system: {
-          totalMemory: 17179869184,
-          freeMemory: 8589934592,
-          usedMemory: 8589934592,
-          memoryUsagePercent: 50.0,
-          cpuCount: 8
-        },
-        process: {
-          cpu: 15.5,
-          memory: 134217728,
-          pid: 12345,
-          ppid: 1,
-          ctime: 5000,
-          elapsed: 10000
-        },
-        topProcesses: [
-          {
-            pid: 54321,
-            name: "ffmpeg",
-            cpu: 85.2,
-            memory: 268435456,
-            ppid: 12345,
-            ctime: 8500,
-            elapsed: 10000
-          },
-          // ... up to 10 processes
-        ],
-        totalProcesses: 342
-      }
-      // ... one sample per second
-    ],
-    summary: {
-      durationMs: 10000,
-      sampleCount: 10,
-      monitorInterval: 1000,
-      avgProcessCPU: 12.3,
-      maxProcessCPU: 18.7,
-      avgProcessMemoryBytes: 134217728,
-      avgProcessMemoryMB: 128.0,
-      maxProcessMemoryBytes: 201326592,
-      maxProcessMemoryMB: 192.0,
-      avgSystemMemoryUsagePercent: 52.5,
-      maxSystemMemoryUsagePercent: 55.3,
-      totalSystemMemoryBytes: 17179869184,
-      totalSystemMemoryGB: 16.0
-    }
-  }
-}
-```
-
-## Summary Statistics
-
-The performance tracker calculates summary statistics including:
-- **Average and Max Process CPU**: How much CPU the Dashcam process used
-- **Average and Max Process Memory**: Memory consumed by the Dashcam process
-- **Average and Max System Memory Usage**: Overall system memory pressure
-- **Total Duration**: How long the tracking ran
-- **Sample Count**: Number of samples collected
-
-## Logging
-
-Performance data is logged to the standard Dashcam log files:
-- `~/.dashcam/logs/combined.log` - All log levels including performance samples
-- `~/.dashcam/logs/debug.log` - Debug-level information
-- Console output when running with `--verbose` flag
-
-## Testing
-
-Run the performance tracking test:
-
-```bash
-node test-performance-tracking.js
-```
-
-This will:
-1. Start a 10-second recording
-2. Collect performance samples every second
-3. Display detailed performance statistics
-4. Show the top 10 processes at the end of the recording
-
-## Use Cases
-
-Performance tracking helps with:
-- **Debugging Performance Issues**: Identify when recordings are resource-intensive
-- **Optimization**: Track the impact of code changes on resource usage
-- **System Monitoring**: Understand what other processes are running during recordings
-- **Troubleshooting**: Correlate performance issues with specific applications or system states
-- **Capacity Planning**: Understand resource requirements for different recording scenarios
-
-## Implementation Details
-
-The performance tracker uses:
-- `pidusage` - For detailed per-process CPU and memory statistics
-- `ps-list` - For listing all system processes
-- `os` module - For system-wide memory and CPU information
-
-The tracker runs in parallel with the recording and has minimal overhead (~1% CPU on average).