FastMediaSorter v2 - Test Scenarios

Date: November 19, 2025
Version: 2.25.1119.xxxx
Purpose: Verify core functionality with LOCAL, SMB, and FTP resources

Prerequisites

Setup Required Resources:

  1. LOCAL: Folder with 20-50 media files (images/videos mix)
  2. SMB: Network share accessible from Android device (e.g., \\192.168.1.112\down)
  3. FTP: FTP server with media files (optional, can skip if unavailable)

Enable Logging:

Test Scenario 1: LOCAL Resource - Basic Operations

Objective: Verify file operations work correctly on local storage without unnecessary reloads

Steps:

1.1 Add Local Resource

1.2 Browse Files (Grid View, No Thumbnails)

1.3 Copy Operation (No Reload Test)

1.4 Move Operation (Targeted Removal Test)

1.5 Delete Operation (Targeted Removal Test)

1.6 Rename Operation

Log Collection Point 1:

Settings → "Show current session log" → Copy to clipboard
Paste log in response with label: "LOG SCENARIO 1 - LOCAL"

Test Scenario 2: SMB Resource - Network Operations

Objective: Verify SMB client doesn’t block after operations, no connection starvation

Steps:

2.1 Add SMB Resource

2.2 Browse SMB Files

2.3 Copy from SMB (Source Remains Unchanged)

2.4 Move on SMB (If Writable)

2.5 Player Screen - SMB File

2.6 Command Panel Mode Test

Log Collection Point 2:

Settings → "Show current session log" → Copy to clipboard
Paste log in response with label: "LOG SCENARIO 2 - SMB"

Test Scenario 3: FTP Resource (Optional)

Objective: Verify FTP operations if FTP server available

Steps:

3.1 Add FTP Resource

3.2 Basic FTP Operations

3.3 FTP Connection Stability

Log Collection Point 3:

Settings → "Show current session log" → Copy to clipboard
Paste log in response with label: "LOG SCENARIO 3 - FTP"

Test Scenario 4: Mixed Operations (Integration Test)

Objective: Verify system stability with multiple resource types

Steps:

4.1 Multiple Resources Active

4.2 Cross-Resource Copy

4.3 Grid View Toggle Test

4.4 Filter Test

Log Collection Point 4:

Settings → "Show current session log" → Copy to clipboard
Paste log in response with label: "LOG SCENARIO 4 - MIXED"

Critical Issues to Watch For

❌ MUST NOT HAPPEN:

  1. Full reload after Copy - check log for “reloadFiles” or “loadResource”
  2. SMB connection blocking - “connection pool exhausted”, “socket timeout”
  3. Grid cells too narrow - text truncated with “..” in text-only mode
  4. Crashes on file operations - any unhandled exceptions

✅ EXPECTED BEHAVIOR:

  1. Copy: NO reload, source files remain in list
  2. Move/Delete: Files removed instantly via removeFiles() method
  3. Grid text-only mode: Wide cells (1-2 columns), full file names visible
  4. SMB stability: Multiple operations without connection errors
  5. Command Panel: Buttons grouped with visual spacing

Not a Defect: Screen Capture on Secure Screens

A screenshot of a secure screen comes back black, or as a zero-byte file, on every device. This is FLAG_SECURE working, not a rendering bug. BaseActivity.applySecureFlagIfEnabled sets it whenever isSensitiveScreen() is true and the secureSensitiveScreens setting is on, which it is by default (S1045). Settings, Add Resource and Resource Editor all declare themselves sensitive.

Recognise it before spending a session on it (S1284 cost one):

Confirm in one command, and read the window’s own flags rather than guessing:

adb -s <device> shell "dumpsys window windows | grep -A 6 '<ActivityName>'"

SECURE in the fl= line settles it. To capture such a screen for a report, turn the secureSensitiveScreens setting off first, then back on.

You no longer have to remember any of this while looking at a black PNG: scripts/devtest/adb.ps1 shot checks the focused window itself and prints the explanation next to the file it just wrote (-Json carries it as secureWindow). The check was added by S1506, after this section had already been written and two device-test sessions on the same day still read a secure capture as a broken screen and filed a P90 ticket for it.

Test Scenario 5: User-Auditor Agent Multi-Device Profile Scenarios

Objective: Formal User-Auditor evaluation protocol across 5 distinct hardware device profiles

Profile 5.1: Smartphone (Portrait & Landscape Touch UI)

Profile 5.2: Tablet (Dual-Pane Multi-Grid UI)

Profile 5.3: Automotive / Car Head Unit (High-Contrast Large Touch & D-Pad)

Profile 5.4: Photo Frame / Leanback TV (D-Pad Remote & Slideshow)

Profile 5.5: Smartwatch / Wear OS (Compact Screen & Rotary Input)

Log Analysis Keywords

When reviewing logs, look for:

GOOD (should see):

BAD (should NOT see after Copy):

CRITICAL ERRORS:

How to Submit Logs

For each test scenario:

  1. Execute all steps in the scenario
  2. Go to Settings → General → “Show current session log”
  3. Copy log to clipboard
  4. Reply with log labeled with scenario number
  5. Describe any unexpected behavior observed

Format:

## SCENARIO X - [NAME]
 
### Observed Behavior:
[Describe what you saw - any errors, unexpected reloads, UI issues]

### Log:
[Paste full log here]

Success Criteria

✅ Test passes if:

❌ Test fails if:

Ready to start testing! Execute scenarios in order and provide logs after each scenario.