G: I hear you — that’s deeply frustrating, especially since the AverMedia Live Gamer Portable 2 Plus is supposed to give you confidence with its hardware-based recording and LEDs. When it randomly spits out an audio-only file with no warning, you’re right: that feels like a betrayal, not just user error. Let’s walk through what’s going on and how to corner the problem.

---

What Might Be Happening

There are a few recurring culprits with the LGP2+ that cause video-less recordings:

1. HDCP Handshake Issues

   • If the source console/PC enables HDCP (copy protection), the LGP2+ sometimes records audio only. This can happen intermittently because some games/apps toggle HDCP differently.
   • Example: PlayStation menus often have HDCP, while most games don’t.

2. Resolution/Refresh Mismatch

   • If your input is set to a resolution or refresh rate outside what the device expects (e.g., 1440p passthrough, or 120 Hz without compatibility), it can silently drop video but keep audio.
   • The device doesn’t always warn you — it just outputs what it can.

3. SD Card Mode Glitches

   • In PC-free mode, if the SD card is too slow, fragmented, or near capacity, the device may fail to commit video frames while still recording audio.
   • Certain card brands/speeds trigger this more often.

4. Firmware Bugs

   • Early firmwares were notorious for random “audio-only” clips. Even later updates still have scattered reports of this.
   • Firmware mismatch with RECentral (their software) also causes silent errors.

5. Cable or Signal Integrity Problems

   • A borderline HDMI cable/connection can pass audio but fail to reliably carry video data.
   • Slight bumps or electrical noise may cause intermittent loss.

---

What You Can Do to Pin It Down

Here are practical steps (no “just reinstall drivers” fluff):

1. Force Disable HDCP

   • On PlayStation: Settings → System → Disable HDCP.
   • On PC: Ensure your GPU output is set to standard, non-protected content paths.

2. Lock Resolution/Framerate

   • Set your console/PC to 1080p60 explicitly. Don’t rely on “auto.”
   • The LGP2+ sometimes chokes when the signal changes (e.g., game launches in a different resolution).

3. Test a Known-Good SD Card

   • Use a UHS-I U3 (e.g., Samsung EVO Plus, Sandisk Extreme).
   • Reformat in FAT32 or exFAT before each session.
   • If possible, try PC mode to rule out the SD card entirely.

4. Update Firmware

   • Grab the latest firmware from AverMedia’s support site and flash the device.
   • Check RECentral’s version too (they need to match).

5. Swap HDMI Cables

   • Use short, certified High-Speed HDMI cables. Long or cheap ones often cause the exact “audio but no video” failure.

6. Watch the LED Carefully

   • Red = standby, Blue = recording, Purple = streaming/PC.
   • If it ever flickers or doesn’t hold solid, that’s your early warning something is wrong with the handshake.

---

Workaround for Confidence

Since you said none of your setups can give you a live echo:

• Cheap HDMI Splitter/Preview Monitor: Run the signal through a $15 splitter to a second screen. Even a tiny capture preview lets you see if video is working before wasting hours.
• Short Test Clip Habit: Record 5–10 seconds before a session, then check playback on the SD card. Annoying, but saves heartbreak if it’s misbehaving.

---

TLDR

Your “audio-only” bug is almost always caused by HDCP flipping on, unsupported resolution/refresh, or SD card write failures. The LGP2+ is infamous for not warning you — it just silently saves audio. The fix: lock your source to 1080p60, disable HDCP, use a fast freshly formatted SD card, and if possible, run a preview (via splitter or PC mode) to confirm video is coming through.

---

Do you want me to help you set up a minimal stress-test checklist — like a “do these 3 things before every recording and you’ll catch 90% of failures” — so you don’t have to keep second-guessing?

G: Got it — if HDCP is off and the failure isn’t patterned (same game, same HDMI source, sometimes fine, sometimes 2-hours of audio-only), then you’re right: this smells less like user error and more like firmware or SD-card handling on the box itself. The LGP2+ is notorious for this “silent fail” mode.

---

How to Update the Firmware (LGP2+)

AverMedia made it a bit clunky, but here’s the clean path:

1. Download RECentral (their control software) from the official AverMedia support page for the Live Gamer Portable 2 Plus (GC513).
   → AverMedia Support: GC513

2. Install RECentral on a PC (Windows recommended; macOS support is partial).

3. Connect the LGP2+ to your PC via USB (not in PC-Free mode, just USB mode).

   • The device LED should show purple when it’s connected in PC mode.

4. Launch RECentral.

   • If a newer firmware exists, RECentral will usually pop up an “Update Firmware” prompt automatically.
   • If not, go to Settings → Device → Firmware Update.

5. Run the update.

   • It will push the firmware over USB.
   • Don’t disconnect until it finishes and the LED cycles.

6. Verify version.

   • In RECentral, check the device info tab — it should list firmware version number.

---

Why This Matters

• Pre-2019 firmwares were especially prone to the “audio-only” bug.
• Later firmwares improved SD card compatibility and reduced silent failures.
• Updating RECentral and firmware in sync matters — sometimes RECentral doesn’t play nice with older firmware.

---

What to Do After Updating

• Reformat your SD card in-device (hold down the function button until the LED blinks, or format via RECentral).
• Do a short 1–2 min test recording in the same conditions before long sessions.
• If the problem persists even on the newest firmware and a fresh SD card, then it’s hardware instability (internal encoder not locking). In that case, a workaround like running PC mode + external preview becomes the only reliable fix.

---

👉 Given that your LED transitions look normal, and HDCP is off, firmware is the #1 suspect here. The unit can look fine while silently failing to buffer video — exactly the bug the updates were meant to squash.

Do you want me to lay out a step-by-step “ritual” (like: update check → SD reformat → test clip) so you’ve got a fixed procedure before sessions, instead of wondering each time? That way you’d at least have a predictable safety net.

G: Ah, that makes more sense now — if it’s that rare, it’s not going to show up in test clips or daily rituals easily, and your stress is the fact that you can’t predict or catch it until you’ve lost hours of footage.

Unfortunately, AverMedia designed the LGP2+ firmware updater to run only through RECentral, which is Windows-only (and partially macOS). There’s no official Linux utility to push firmware to the box.

That said, here are your real options:

---

1. Borrow/Boot a Windows Environment (One-Time)

• The firmware update is not recurring — once you flash the newest version, you’re done unless they release another patch.
• Easiest path:
  • Boot into a Windows machine (friend, family, even a public lab if you trust it enough).
  • Or spin up Windows via dual-boot, spare drive, or temporary USB install.
  • Install RECentral, connect LGP2+, run the firmware update, done.
• You don’t have to record from Windows afterward — the firmware lives on the device.

---

2. Run Windows in a VM (Linux Host)

• If you’ve got enough horsepower, you can pass the LGP2+ USB device into a Windows VM (VirtualBox, QEMU/KVM, VMware).
• Needs USB passthrough support.
• Some people have reported successful firmware flashes this way, though it’s not officially supported. The main risk is if the VM hiccups mid-flash, you could brick the device.

---

3. MacOS Option (If Available)

• AverMedia does ship RECentral for macOS, but it’s less maintained. If you can borrow a Mac, you can update from there too.

---

4. Last Resort: SD Card Image Trick (Not Confirmed for LGP2+)

• On a few AverMedia models, firmware updates could be applied by placing a firmware .bin file on the SD card and booting into a hidden mode.
• I checked the LGP2+ documentation — they don’t expose this officially. It might exist, but unless AverMedia support hands you the exact file + instructions, I wouldn’t risk it.

---

Realistically:

For you, the cleanest bet is grab a temporary Windows environment once, flash the firmware, then go back to Linux recording as usual. Since the bug is rare, it’s probably sitting on a fixed version that never got pushed to your unit.

---

Would you like me to check what the latest firmware version number is supposed to be for the LGP2+, so you know whether it’s worth the trouble of finding a Windows machine? That way you can confirm if you’re actually running an older one that’s vulnerable to this audio-only bug.

G: Good question — because when you’re talking about local network (LAN) speeds, the internet doesn’t matter at all. The bottleneck is entirely the type of connection between the two machines and the switches/routers in the middle. Here’s the breakdown:

---

Common LAN Speeds (as of 2025)

• Fast Ethernet (100 Mbps)

  • Rare today, but some old routers/NICs still only support this.
  • Max throughput: ~12.5 MB/s (megabytes per second).

• Gigabit Ethernet (1 Gbps)

  • Standard for most consumer gear for the past 10–15 years.
  • Max throughput: ~125 MB/s.
  • Real-world transfers: 80–115 MB/s (depending on overhead, disk speeds, etc.).

• 2.5 GbE (2.5 Gbps)

  • Becoming common on mid-range motherboards and new routers.
  • Max throughput: ~312 MB/s.
  • Real-world: ~250–290 MB/s.

• 5 GbE (5 Gbps)

  • Less common, mostly pro gear or enthusiast setups.
  • Max throughput: ~625 MB/s.
  • Real-world: ~500–580 MB/s.

• 10 GbE (10 Gbps)

  • High-end, but dropping in price.
  • Max throughput: ~1.25 GB/s (gigabytes per second).
  • Real-world: ~900 MB/s to 1.1 GB/s.

• Wi-Fi (varies a ton)

  • Wi-Fi 5 (802.11ac): typically 200–600 Mbps real-world.
  • Wi-Fi 6/6E: 600 Mbps–1.5 Gbps real-world under good conditions.
  • Wi-Fi 7 (early 2025 gear): theoretically up to 40 Gbps, but home users today see 2–5 Gbps if conditions are perfect.

---

Remote Login vs. File Transfer

• If you’re just remoting in (SSH, RDP, VNC), the traffic is tiny — a few Mbps at most, because you’re just moving keyboard/mouse signals and screen data.
• If you transfer a file between two systems on the same LAN, the speed ceiling is set by the slowest link in the chain:
  • The NIC speed of both computers.
  • The router/switch port speed.
  • The cable standard (Cat 5e, Cat 6, etc.).
  • The read/write speed of the drives on both ends.

Example:
Two PCs with gigabit Ethernet connected to the same gigabit switch → you should see ~100 MB/s file transfer speed, assuming both drives can read/write that fast.

---

TLDR

On a typical modern LAN with gigabit Ethernet, you’ll usually max out around 100 MB/s file transfer speed. If you’ve got newer 2.5 Gbps or 10 Gbps gear, you can push 250 MB/s to over 1 GB/s, but only if both computers and your network hardware support it.

---

Do you want me to give you a step-by-step test method (like using iperf3 or a quick file copy) to check the actual speed of your setup, so you’ll know what number to expect instead of guessing?

G: Ah, perfect clarification — Wi-Fi behaves differently than wired LAN, and you’re right to suspect it’s not as simple as “everyone gets their own lane.” Let me lay it out:

---

How Wi-Fi Bandwidth Works

• Shared medium: All devices on the same Wi-Fi band (say, 5 GHz channel 36) share the total available bandwidth. It’s like walkie-talkies — only one “talks” at a time, and others wait.
• Total capacity is finite: If your router advertises 1200 Mbps, that’s the combined theoretical max across all devices. One device can get close to that if it’s alone, but add more devices and they divide the airtime.
• Overhead eats into throughput: Protocol chatter, interference, encryption, etc., mean you usually only get 50–70% of the “headline” Wi-Fi speed.

---

Typical Real-World Speeds (2025 gear, one device in good conditions)

• Wi-Fi 5 (802.11ac): 200–600 Mbps (≈25–75 MB/s).
• Wi-Fi 6 (802.11ax): 600–1500 Mbps (≈75–180 MB/s).
• Wi-Fi 6E: Similar to Wi-Fi 6, but less crowded spectrum, so more consistent.
• Wi-Fi 7 (early consumer gear): Can push multi-gig speeds (2–5 Gbps), but only if both router and client support it.

So your Raspberry Pi server over Wi-Fi 5 might give ~30–50 MB/s sustained transfer, while over Wi-Fi 6 you could see ~100–150 MB/s if everything lines up.

---

Multiple Users

• Yes, they affect each other.
  If two people are pulling files from your Pi at once, the Wi-Fi splits its airtime. Each person gets roughly half the available throughput (assuming equal demand and conditions).
• Unlike wired Ethernet switches, which can give each port full bandwidth simultaneously, Wi-Fi is more like a single “pipe” shared by all clients on that frequency.

---

Other Bottlenecks

• Pi’s Wi-Fi hardware:
  • Pi 3: ~40–50 Mbps real-world max.
  • Pi 4: ~150–200 Mbps on 5 GHz.
  • Pi 5: supports Wi-Fi 6 — in theory ~1 Gbps, but likely 400–600 Mbps in practice.
• Storage speed: A USB 3.0 SSD will keep up, but microSD cards won’t — they often bottleneck under 30 MB/s.
• Router quality: Cheap ISP routers choke under load, while decent consumer routers handle multiple Wi-Fi streams more gracefully.

---

TLDR

On Wi-Fi, your Pi’s file server speed will depend on:

• Which Pi model (3, 4, or 5).
• Your Wi-Fi standard (5 vs 6 vs 7).
• How many people are transferring at once.

Expect anywhere from 30 MB/s on the low end (Pi 3, Wi-Fi 5) to 150 MB/s+ on the high end (Pi 5, Wi-Fi 6). But yes, every extra user slices up that capacity — it’s not like Ethernet where each gets their own lane.

---

Do you want me to sketch out a “best-case vs. worst-case” scenario for each Pi model (3, 4, 5) so you’ll know exactly what performance tier to expect if you set up a Pi file server?

G: Got it — let’s make this concrete. You said 2 GB file (which is 2,048 MB).
We’ll run the math for the typical real-world Wi-Fi throughputs I sketched earlier, assuming good conditions and one transfer at a time.

---

Time to Transfer 2 GB (one direction)

Wi-Fi 5 (802.11ac)

• 200 Mbps ≈ 25 MB/s → ~82 seconds
• 400 Mbps ≈ 50 MB/s → ~41 seconds
• 600 Mbps ≈ 75 MB/s → ~27 seconds

Wi-Fi 6 (802.11ax)

• 600 Mbps ≈ 75 MB/s → ~27 seconds
• 1000 Mbps ≈ 125 MB/s → ~16 seconds
• 1500 Mbps ≈ 180 MB/s → ~11 seconds

Wi-Fi 6E

• Similar to Wi-Fi 6, but less interference, so take the lower end (~20–30 s) as more reliable.

Wi-Fi 7 (early 2025 gear)

• 2.5 Gbps ≈ 312 MB/s → ~6.5 seconds
• 5 Gbps ≈ 625 MB/s → ~3.3 seconds

---

Raspberry Pi Constraints

• Pi 3 (Wi-Fi 4/5-ish): Tops out closer to ~40–50 Mbps real world → 5–7 minutes for 2 GB.
• Pi 4 (Wi-Fi 5, decent chip): 150–200 Mbps real world → ~1.5–2 minutes.
• Pi 5 (Wi-Fi 6 capable): 400–600 Mbps real world → ~25–40 seconds.

(That’s before considering SD card vs. SSD as the storage bottleneck — an SD card may not keep up with even Pi 4 speeds, meaning the card becomes the limiter.)

---

TLDR

• On a Pi 3, 2 GB could take ~6 minutes.
• On a Pi 4, ~2 minutes.
• On a Pi 5, ~30 seconds if Wi-Fi 6 and storage are up to it.

So yes, reading back from the Pi should be about the same time, unless the Pi’s storage (SD card or slow USB drive) is the limiting factor.

---

Do you want me to map this out as a little table you can reuse (file size vs. Pi model vs. Wi-Fi standard → expected time), so you can estimate quickly no matter what file size you’re thinking about?

G: Ah, I see where you’re coming from — this isn’t about “how many seconds per file,” it’s about workflow friction. Right now your setup is:

1. Download to a scratch drive.
2. Sort / delete / decide what’s worth keeping.
3. Move final files onto the big drive directly attached to the laptop.

If you switch to the Pi setup:

• Step 3 turns into a network transfer.
• Even if the transfer speed is “acceptable,” it’s slower enough that you won’t want your download client itself handling the copy directly.

That makes sense — download clients tend to be optimized for fast, direct local moves. If you pointed them at the Pi share:

• They’d have to stream the file through Wi-Fi, not just move it locally.
• If the client crashes, times out, or tries to “move” instead of “copy + delete,” you could end up with broken transfers.

---

Practical Implications of Pi-as-Server

• Extra step: Instead of “download client → big drive,” you’d go “download client → scratch → Pi share.”
• Manual or scripted copy: You’d likely want to script or manually copy files after sorting, rather than letting the client handle it.
• Consistency vs. speed: Network moves (especially over Wi-Fi) aren’t as “atomic” as local filesystem moves. There’s a higher chance of partials if interrupted.

---

Usage Impact

• If you only do this occasionally and your files are 1–2 GB at a time, a Pi 4/5 will feel fine — just a slightly longer wait during the final copy step.
• If you do this constantly, with dozens of large files per session, the slowdown will make you resent the Pi unless you either:
  • Use wired Ethernet for the Pi (much faster and more consistent).
  • Or build a simple “copy-to-server” script that you run once at the end of your sorting.

---

TLDR

You’re right: introducing a Pi server means you’ll want to separate the sorting stage from the transfer stage. Doing the copy inside the client is riskier over Wi-Fi (too slow, more things can go wrong). Better workflow would be:

1. Keep downloading/sorting locally as you do now.
2. When you’ve got a batch of “keepers,” run a copy/move to the Pi server in one go.

That way the Pi’s slower Wi-Fi link isn’t in the middle of your client’s delicate juggling, and you can just let the transfer churn in the background.

---

Would it help if I showed you how to make a one-liner command/script (Linux → Pi over Wi-Fi) so you can dump all “keepers” in one shot, instead of dragging them around manually? That way it’s just an extra keystroke, not a whole new hassle.