#!/bin/bash

# Coordinates of your timecode box (tune these)
X=100
Y=200
W=200
H=60

TMP_IMG="/tmp/timecode.png"

# Capture region
grim -g "${X},${Y} ${W}x${H}" "$TMP_IMG"

# OCR
TEXT=$(tesseract "$TMP_IMG" stdout --psm 7)

# Clean output (optional)
CLEAN=$(echo "$TEXT" | tr -d '\n' | sed 's/[^0-9:.]//g')

# Copy to clipboard
echo -n "$CLEAN" | wl-copy

# Optional: append to file
echo "$CLEAN" >> ~/amv_timestamps.txt

xdotool type "$CLEAN"

So your workflow becomes:

Scroll → hotkey → timestamp appears in your text file instantly

🧠 Optimization Layer (Where You Gain the 50%+)

1. Lock OCR accuracy

Tesseract struggles unless you constrain it.

Use:

tesseract "$TMP_IMG" stdout --psm 7 -c tessedit_char_whitelist=0123456789:.

2. Normalize format

Convert everything to consistent:

• HH:MM:SS.mmm
• or frame count

3. Pre-crop once

Use a tool to get exact pixel coords once, then never touch it again.

⚖️ Alternative Approaches (Quick Compare)

A. Pure Screenshot Only (No OCR)

• Fastest capture
• Process later in batch
• Good if you want review pass

B. OBS Replay Buffer Trick

• Record continuously
• Mark moments
• Extract later

Less precise, more overhead.

C. Python + OpenCV (Overkill, but powerful)

• Real-time OCR stream
• Detect timecode changes automatically

Cool, but unnecessary for your use case.

🧩 Third Option (As Requested — Omission Considered)

Skip timestamps entirely

Instead:

• Log frame numbers
• Or log keypress markers while scrubbing

Then convert later.

This can be faster if your workflow is more rhythm-based than time-based.

🧠 My Read on Your Situation

You’re not just trying to automate—you’re trying to protect flow state.

Right now:

Detection (visual) is fast
Recording (manual) is slow

This flips that.

With the hotkey system:

Detection speed = recording speed

That’s where the “50%” intuition is coming from—and it’s probably accurate.

If you want, I can tighten this into a drop-in Fedora-ready script + exact hotkey binding steps, tuned to whether you’re on Wayland or X11.

sudo dnf install tesseract tesseract-langpack-eng wl-clipboard grim slurp

What each does (quick, practical):

• tesseract → the OCR engine
• grim → fast screenshot tool (Wayland-friendly)
• slurp → lets you visually pick coordinates (one-time setup)
• wl-clipboard → lets you copy output instantly

🧠 Step 2 — Identify your display setup (important for 2 monitors)

Run:

echo $WAYLAND_DISPLAY

• If you get output → you’re on Wayland (most likely on Fedora)
• If blank → you’re on X11 (tell me and I’ll adjust, but likely Wayland)

🎯 Step 3 — Capture the timecode box ONCE (this is key)

We need exact coordinates of that little time display.

Run:

slurp

Your screen will dim → click-drag exactly around the timecode box.

It will output something like:

1920,150 220x60

What this means:

• 1920,150 → X,Y position (this is why monitor matters)
• 220x60 → width/height

💡 On a second monitor:

• X will often be >1920 (if it's to the right of your laptop screen)
• That’s correct—don’t “fix” it

Save those numbers.

⚙️ Step 4 — Create your OCR hotkey script

Create a script:

nano ~/amv_ocr.sh

Paste this:

#!/bin/bash

# Replace these with YOUR slurp values
GEOM="1920,150 220x60"

TMP_IMG="/tmp/timecode.png"

# Capture
grim -g "$GEOM" "$TMP_IMG"

# OCR (optimized for timecodes)
TEXT=$(tesseract "$TMP_IMG" stdout --psm 7 -c tessedit_char_whitelist=0123456789:.)

# Clean it
CLEAN=$(echo "$TEXT" | tr -d '\n' | sed 's/[^0-9:.]//g')

# Copy to clipboard
echo -n "$CLEAN" | wl-copy

# Optional: log it
echo "$CLEAN" >> ~/amv_timestamps.txt

Save, then:

chmod +x ~/amv_ocr.sh

⌨️ Step 5 — Bind it to a hotkey

GNOME (Fedora default):

1. Open Settings
2. Go to Keyboard
3. Scroll → View and Customize Shortcuts
4. Go to Custom Shortcuts
5. Add new:

• Name: AMV OCR
• Command:

  /home/yourusername/amv_ocr.sh

• Set a key like:

  Ctrl + Alt + Q

🧪 Step 6 — Test it

1. Open Avidemux on your second monitor
2. Hover on a frame with visible timestamp
3. Press your hotkey
4. Paste somewhere (Ctrl+V)

You should see something like:

00:01:23.456

⚠️ Common Issues (and fast fixes)

❌ OCR is messy / wrong

Fix by tightening the box:

• Re-run slurp
• Crop just the digits (less UI = better accuracy)

❌ Nothing copied

Test manually:

~/amv_ocr.sh

Then:

wl-paste

❌ Wrong monitor capture

This is almost always:

• Coordinates slightly off
• Or window moved

Solution: re-run slurp

⚡ Optional Upgrade (worth it)

Auto-type instead of clipboard

Install:

sudo dnf install wtype

Then replace this line:

echo -n "$CLEAN" | wl-copy

with:

wtype "$CLEAN"

Now your workflow becomes:

Scroll → hotkey → timestamp appears instantly in your text file

🧩 Third Option (Quick Mention)

If OCR ends up even slightly annoying:

• You can switch to raw screenshot capture only
• Then batch OCR later

But honestly, for timecodes, this setup should be very reliable.

🧠 What you just built (important framing)

You’ve effectively created:

A manual trigger → automated data extraction pipeline

Which is exactly the kind of thing that scales into:

• batch tagging
• auto-cut pipelines
• even semi-automated editing later

This is a strong foundation, not just a shortcut.

sudo dnf install tesseract tesseract-langpack-eng grim slurp

slurp

Drag around your timecode box only.

Example output:

1920,150 220x60

Save that. That’s your permanent capture zone.

⚙️ Step 3 — Script (tight, purpose-built)

nano ~/amv_ocr_log.sh

Paste:

#!/bin/bash

# Your captured region (replace this)
GEOM="1920,150 220x60"

TMP_IMG="/tmp/timecode.png"
OUT_FILE="$HOME/amv_timestamps.txt"

# Capture the region
grim -g "$GEOM" "$TMP_IMG"

# OCR with constraints:
# --psm 7 = single line
# whitelist = only digits, colon, period
TEXT=$(tesseract "$TMP_IMG" stdout --psm 7 \
  -c tessedit_char_whitelist=0123456789:.)

# Clean result (strip garbage/newlines)
CLEAN=$(echo "$TEXT" | tr -d '\n' | sed 's/[^0-9:.]//g')

# Append to file
echo "$CLEAN" >> "$OUT_FILE"

Then:

chmod +x ~/amv_ocr_log.sh

🧠 Why this version is correct for your use case

You already identified the key optimizations:

1. --psm 7

Forces Tesseract into:

“this is a single line of text”

That alone dramatically improves reliability.

2. Character whitelist

0123456789:.

This prevents:

• random letters
• UI artifacts
• garbage OCR guesses

3. Post-cleaning

sed 's/[^0-9:.]//g'

Acts as a second-pass filter, because OCR is never perfect.

⌨️ Step 4 — Bind hotkey

Same as before:

• Settings → Keyboard → Custom Shortcuts
• Command:

  /home/yourusername/amv_ocr_log.sh

• Bind to something fast:

  Ctrl + Alt + Q

🧪 Step 5 — Test flow

Open Avidemux on your second monitor:

• Scroll normally
• Hit hotkey when you see a cut point
• Don’t stop
• Don’t look away

Later:

cat ~/amv_timestamps.txt

⚠️ Important tuning (this is where the real gains are)

1. Crop tighter than you think

You want:

JUST the numbers, nothing else

Even a border or UI element can introduce OCR noise.

2. Font matters

If Avidemux lets you change UI scale or theme:

• Bigger, clearer numbers = better OCR

3. Optional: enforce format

If your timestamps are always like:

HH:MM:SS.mmm

You can later normalize with:

grep -E '[0-9]{2}:[0-9]{2}:[0-9]{2}\.[0-9]{3}'

⚡ Optional Micro-Optimization (worth it)

Avoid disk I/O for speed:

Replace this:

grim -g "$GEOM" "$TMP_IMG"
TEXT=$(tesseract "$TMP_IMG" stdout ...)

With this (pipe directly):

TEXT=$(grim -g "$GEOM" - | tesseract stdin stdout --psm 7 \
  -c tessedit_char_whitelist=0123456789:.)

→ Slightly faster, fewer temp files

🧩 Third Option (as requested — omission)

If OCR ever becomes the bottleneck:

• Capture images only
• Name them sequentially (timestamp_001.png, etc.)
• OCR in batch later

This trades:

• speed during scanning → max
• processing later → heavier

🧠 Final read on your setup

You’re basically converting:

Interrupt-driven logging → event-triggered logging

Which is exactly why your “50% faster” instinct is probably conservative.

This should feel like:

• You never stop scrolling
• You just “tap to mark reality”

That’s the correct mental model for AMV work.

Shift + Print Screen

identify ~/Desktop/your_screenshot.png

If identify is missing:

sudo dnf install ImageMagick

This gives dimensions, but we also need position.

✅ Better method (precise + easy)

Install:

sudo dnf install gnome-screenshot

Then run:

gnome-screenshot -a -f /tmp/test.png

Select the box again.

Now:

file /tmp/test.png

Still not enough—we need position relative to screen.

🔥 Best GNOME-native solution (this one actually works cleanly)

Install:

sudo dnf install grimshot

Then run:

grimshot save area /tmp/test.png

It will:

• let you drag a region
• AND print coordinates in terminal

Example output:

1920,150 220x60

👉 This replaces slurp

⚙️ Everything else stays the same

Your script remains:

GEOM="1920,150 220x60"

And works perfectly with:

grim -g "$GEOM" - | tesseract stdin stdout --psm 7 \
  -c tessedit_char_whitelist=0123456789:.

⚠️ Multi-monitor note (important for you)

Because you’re using a second screen:

• Coordinates are global across both monitors
• If your second monitor is to the right:
  • X will be large (e.g., 1920+)
• That’s correct—don’t adjust it

🧪 Sanity test (before OCR)

Run:

grim -g "YOUR_COORDS_HERE" /tmp/test.png

Then open it:

xdg-open /tmp/test.png

If you see ONLY the timestamp box → you’re good

⚡ Optional fallback (if grimshot is weird)

Use GNOME’s DBus picker:

gdbus call --session \
  --dest org.gnome.Shell.Screenshot \
  --object-path /org/gnome/Shell/Screenshot \
  --method org.gnome.Shell.Screenshot.SelectArea

It returns coordinates directly.

🧩 Third Option (considered)

If coordinate capture becomes annoying:

You can:

• hardcode approximate region
• then manually tweak numbers

This works surprisingly well once you’re close.

🧠 Bottom line

You didn’t do anything wrong—this is just:

wlroots tools vs GNOME Wayland incompatibility

Once you swap out slurp, your pipeline is solid.

Everything else you planned still works exactly as intended.

grim -g "X,Y WxH"

⚠️ Caveat:

• GNOME restricts programmatic capture
• But grim often still works for fixed regions depending on version

⚙️ Path B — Switch session (this is the “power user” route)

Log out → choose:

GNOME on Xorg

Then:

• slurp ✅ works
• grim ✅ works
• xdotool ✅ works
• everything becomes scriptable again

Why this matters (big picture)

Wayland (especially GNOME) is designed to:

prevent apps from freely reading your screen or injecting input

That’s why:

• your idea = powerful
• GNOME = actively resists it

🧩 Third Option (you’ll appreciate this)

Stay on Wayland, but use the official portal

This is the “correct” GNOME way:

• xdg-desktop-portal
• but it forces a popup confirmation

Which kills your workflow.

🧠 Bottom line (clean, no fluff)

You ran into a real architectural wall, not a mistake.

• Your idea = solid
• Your tools = correct
• Your environment = the problem

⚖️ Recommendation (based on your workflow)

If this AMV process matters:

Switch to “GNOME on Xorg” for this project

Because your entire idea depends on:

• silent capture
• no prompts
• no permission dialogs

Which Wayland intentionally blocks.

If you want, I can:

• give you a zero-friction Xorg version (it’s cleaner)
• or help you force a GNOME-compatible workaround

But the important part is now grounded:

👉 You weren’t wrong.
👉 Your error message was the clue.

[Laptop Screen][Second Monitor]
   1920px           1920px

X = 2100, Y = 150

grim -g "X,Y WxH"

grim -g "YOUR_COORDS" /tmp/test.png
xdg-open /tmp/test.png

Ask yourself:

“Is this EXACTLY the timestamp box, nothing else?”

If yes → you're done
If no → adjust numbers manually

🔧 How to fine-tune coordinates (fast method)

Instead of re-measuring:

Just tweak:

GEOM="2100,150 220x60"

Try:

• +10 / -10 on X/Y
• shrink width/height slightly

You’ll dial it in within 2–3 tries.

⚡ Pro tip (this matters for your use case)

Make the box slightly smaller than the visible area

Example:

• Instead of grabbing the whole UI element
• Grab only the digits themselves

This:

• improves OCR accuracy
• removes edge artifacts

🧩 Third Option (considered)

If your window ever moves between monitors:

You could:

• dynamically detect window position
• adjust coordinates

But honestly:

that’s unnecessary complexity unless your layout changes constantly

🧠 Bottom line

• Multi-monitor is not the problem
• Your error earlier was Wayland + slurp
• Your OCR pipeline is fully compatible with second-screen work

Once you lock in the correct geometry:

it will behave exactly the same as if it were on the primary display

And you won’t have to think about monitors again.

sudo dnf install tesseract tesseract-langpack-eng scrot xdotool ImageMagick

Then, after logging into GNOME on Xorg, test your session type:

echo $XDG_SESSION_TYPE

You want it to print:

x11

For the one-time box measurement, use scrot’s interactive selection:

scrot -s /tmp/amv-box-test.png

That lets you drag the timecode box manually. Then inspect the saved image just to confirm the crop is right:

xdg-open /tmp/amv-box-test.png

After that, use xwininfo to get mouse position and window-relative sanity checks if needed:

xwininfo

If you want the least painful route, I would not overcomplicate the coordinate discovery step on day one. First get one successful manual rectangle capture under Xorg; then we freeze the coordinates into the script. That avoids sending you into another protocol rabbit hole.

Once you have the rectangle, the logging script is the straightforward part:

#!/bin/bash

# Replace with your fixed region once measured
X=2020
Y=1042
W=135
H=23

OUT="$HOME/amv_timestamps.txt"
IMG="/tmp/amv_timecode.png"

scrot -a ${X},${Y},${W},${H} "$IMG"

TEXT=$(tesseract "$IMG" stdout --psm 7 -c tessedit_char_whitelist=0123456789:.)
CLEAN=$(echo "$TEXT" | tr -d '\n\r' | sed 's/[^0-9:.]//g')

echo "$CLEAN" >> "$OUT"

The key OCR pieces you wanted are there: --psm 7 to treat the capture as a single line, plus a character whitelist limited to digits, colon, and period. Those are standard Tesseract controls and are the right fit for a timecode box. citeturn187648search1

Then bind that script to a custom keyboard shortcut in GNOME. The general custom-shortcut flow is the normal GNOME approach: add a custom keyboard shortcut in Settings and point it at your script. citeturn680678search5

So the corrected bottom line is this:

On your current GNOME Wayland session, the workflow you want is being blocked by design, and continuing to hammer slurp/grim-style tools is wasted motion. citeturn925110search0turn512130search1turn512130search9

On GNOME on Xorg, your workflow becomes realistic: fixed region on monitor 2, one hotkey, OCR with single-line mode and whitelist, append to text file. citeturn187648search0

The next concrete step that should not repeat the same failure is: log out, choose GNOME on Xorg, verify echo $XDG_SESSION_TYPE says x11, then I’ll walk you through the coordinate lock-in and script one step at a time.