Test failures: Panasonic Lumix DMC TZ61

[juleskers]

As promised in #6, I've finally made some time, and dug out my old-ish handheld camera, Panasonic Lumix DMC TZ61.

It's discontinued (sold 2014-2016), but I found an old spec-sheet in a review
(Just for reference and a picture, so we all understand what I'm talking about).

This device offers "pictbridge (PTP)", but, from the looks of it, in read-only mode.
In fact, it seems to actively filter the contents of the SD-card: files and folders that I manually create on the SD-card (taking the card out of the camera, inserting it directly into my PC) are invisible via the PTP-view.
Even copying a camera-made photo 'up' into the root folder doesn't show it, so it seems photos need to be named exactly /DCIM/1nn_PANA/nnnmmmm.jpg. The same file also doesn't show if I put it in the "MISC" folder.

I tested commit 73fd145 "Docs: Correct 0.18.0/0.19.0 changelog,"
(main at time of writing)

I first tried to 'just' run the tests: cargo test --test integration -- --ignored --nocapture --test-threads=1

• device connection -> ✔️ works
• All the tests that attempt writing -> 💣 panic;
• the rename-test -> 🦺 detects Device doesn't support rename, skipping
• test_list_root_folder -> ✔️ works (sees only the two explicitly firmware-whitelisted folders offered by the camera)
  • manually adding a "TEST" folder to the root doesn't show up, neither in the test-listing, nor in the 'normal' gphoto2 mountpoint created by my linux distro.
• test_cancel_download_then_reuse_session -> Since the camera shows nothing at the root, it can't find a file to download.
  However, it also cannot find one recursively, despite hundreds of photos being in the exposed folders, many of which in the 4-9MB range.

   Searching for file (100KB-10MB) to cancel...
     [00:00:00.267] No file in common folders, trying recursive listing...
  

• I consider it 'working as intended' that the tests panic if I forget to unmount the camera from my linux (device already claimed by the OS -> not available for mtp-rs to claim it)

I'm attaching the full log, with backtrace and custom test folder:
RUST_BACKTRACE=1 MTP_TEST_FOLDER=MISC cargo test --test integration -- --ignored --nocapture --test-threads=1 2>&1 | tee Panasonic_Lumix_DMC_TZ61.txt ->
Panasonic_Lumix_DMC_TZ61.txt

---

In summary, the basic reading works, though I'm wondering why the recursive-search cannot find any good files, even though they are present..
Writing is not supported by the device, but it seems that however-this-is-communicated (if at all) isn't picked up by mtp-rs, so leads to panics.

I hope the backtraces will help you identify areas for improvement, and I'll happily retest version you care to show (just understand that it might be days/weeks/months before I can make time again)

[vdavid]

Hi again, Jules,

Thanks for digging out the camera, and for all the logs, custom test folder, and SD-card filtering experiments! These are all super useful! (The firmware-level filtering is a fun find! Even camera-made photos copied to root stay hidden, interesting.)

I see two separate things here:

1. Write tests panicking. The cam is read-only. The tests should've skipped instead of panicking. I've just fixed this in 2bc64bf: destructive tests now check a new supports_upload() (true when the device advertises both SendObjectInfo and SendObject) and skip with a clear log line instead of panicking.
   • One caveat: if your camera does advertise SendObjectInfo, the new gate won't trigger, and you'd still see the panics. The diagnostics below will tell us.
2. Recursive search finding nothing. No clue about this one yet. The ~46s/search means the lib traversed a lot before returning zero files. My best idea is that maybe the camera reports parent handles differently than we expect, so our exact-parent filter silently drops everything, and the traversal never descends past DCIM. Also possible that the listing errored mid-way; the old test code swallowed that error, but I've also fixed in the commit above, it now logs it.

When you find the time, could you pull the latest main, and run these two with the camera plugged in, and attach the output?

cargo run --example diagnose
cargo run --example ptp_diagnose

The first shows exactly where the recursive listing loses your photos. The second dumps the camera's advertised operations, which settles the SendObjectInfo question.

If you also re-run the test suite, the three write tests should now skip cleanly instead of panicking. 🤞

Thanks again! First camera-shaped device in the tracker! :)

[juleskers]

Wow, that was fast!

Here are the results of the updated tests, and the diagnostics:

• Test improvements worked, no more panics 🎉

  Device doesn't support upload (no SendObjectInfo/SendObject)
  

• The recursion failure seems to be due to a "weird" datetime coming from the device:

  === Test 2: Recursive listing (smart) ===
  Device is Android: false
  Error: InvalidData { message: "invalid datetime format: 20480000T000000" }
  

• I definitely ran into a firmware bug in the camera. At one point I Ctrl+C-aborted the recursive listing, and the camera was completely locked up, wouldn't even respond to power-button. Running the diagnostics would complain about "Transaction ID mismatch".
  I reset it by removing the battery, after which everything worked normally again.

Log-files:

• diagnose-git2bc64bf.txt
• Panasonic_Lumix_DMC_TZ61-git2bc64bf.txt

[vdavid]

Hey Jules,

Thanks for the diagnostics! Both solved:

1. Writes: the cam doesn't advertise SendObjectInfo/SendObject at all (none in the 21 ops), so the new gate is the complete fix. ✅
2. Recursion failure: your cam reports 20480000T000000 (year 2048, month 0, day 0, Panasonic's pretty fun "no date" value) as the create/modify date of apparently everything. Our datetime parser treated that as a hard error, which failed the whole object parse, which killed the entire listing. One bogus metadata field hid hundreds of photos. Fixed in 82de0c8: unparseable datetimes now parse as None instead of erroring (Windows is clearly lenient here too, so we're in good company).

Bonus from your logs: the camera advertises ResetDevice and a few other standard ops we only displayed as Unknown(4112) etc. Added them all in the same commit, so ptp_diagnose output reads nicer now.

About the freeze: sorry about the battery pull! That one's camera firmware (it locks up when the host vanishes mid-transaction), so there's not much we can do library-side. I've recorded it in our quirks notes. If it ever happens again: the camera does advertise ResetDevice (0x1010), so a tiny PTP reset call might un-stick it without opening the battery hatch. Untested, though.

When you next have time (no rush at all): pull latest main and re-run the suite and/or cargo run --example diagnose. I expect the recursive listing to find your photos now, and the whole read-only suite to pass. If it does, I'll add the TZ61 to the tested devices table (as read-only). This would be the third device family in the tracker after phones and watches :)

[juleskers]

Glad to be of service!
A world where memory-safe code handles random devices plugged into my trusted computer, is a world where I'll sleep better, so there is some (long-range) self-interest going on ;-) 🧡

I have some spare minutes (but not hours) this weekend, so attached is a partial batch of updates.
I didn't try too often, because I didn't have time to sit and watch the screen for extended periods.
I ran a couple of fire-and-forget commands instead.

The unit-test fallback to the slow recursive search is really bothersome in this situation. See below for some ideas in that direction.

---

• ptp_diagnose output indeed looks better:
  2_ptp_diagnose-git8fef633.txt

  • no more "Unknown" 🎉
  • Is there any meaning to the "endpoint stalled" in the "Standard Property Tests" section?
    I suspect that needs digging, because if I immediately re-run ptp_diagnose a second time, it only reports:

    === PTP camera diagnostic ===
    
    Error: Io(Custom { kind: Other, error: "endpoint stalled" })
    

  • Every time I open the file, I get an "encoding-warning" from my text-editor (gnome built-in).
    I think there may be an embedded null-character in the serial number?

• a tiny PTP reset call might un-stick it without opening the battery hatch. Untested, though.

  Sounds useful. How would I do that? A quick ripgrep-search of "reset" on the codebase didn't immediately show any obvious (to me?) commands to run?

  • ideally, I'd love if there were an example-command I could run that tries to "unstuck" the device. There's probably other reset-like things you can do?

• diagnose now runs significantly longer, thanks to the recursive search no longer giving up.
  I ended up aborting it a couple of times (rendering all subsequent output of tests/diagnosis bad until camera-reset.)

  • I understand the camera-firmware is not something you can fix, but perhaps there is something you can do to intelligently detect the situation?
    The symptoms are that whatever test or example-command I run, it errors out with one of (rotating)

    • Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.05s
      Running `target/debug/examples/ptp_diagnose`
      === PTP camera diagnostic ===
      
      Error: InvalidData { message: "expected Response container type (3), got 2" }
      

    • === PTP camera diagnostic ===
      
      Error: InvalidData { message: "Transaction ID mismatch: expected 1, got 0" }
      

• I had successful(?) recursive searches in the normal unit-tests, during the test_cancel_download_then_reuse_session test. It found a picture, Then either the camera and/or the computer went to sleep. Not sure in which order, because I was away-from-keyboard.

  • logfile: Panasonic_Lumix_DMC_TZ61-git8fef633_2026-06-06_Partial-before-suspend.txt
  • idea: could the fallback-search in the unit-tests be made less stringent/faster somehow? I'm not sure how the search goes right now, but the fact that it picked a file from the "last" (111_PANA) folder leads me to think it crawled everything else first. Perhaps it can be less picky, and early-exit if it finds any file above 2MB? That should hit at basically the first folder, first handful of files.
  • alternative idea: MTP_TEST_READFILE=/111_PANA/P1110001.JPG -> skip the recursive search, only verify the file is readable and big enough.
  • MTP_RUN_SLOW_TESTS=1 -> not having this skips the tests that intentionally does the recursion, but doesn't stop all the other tests from trying it as a terribly-slow fallback?

• While I was typing all this up, I re-ran the test suite in the background. After 15 minutes I became impatient and switched of the camera. (nothing showed on screen during those 15m, as the sed+tee buffer all output until the buffers are flushed, that happens after "a lot" of text, or whenever the producing program exits..)
  operative output:

  test readonly::test_cancel_download_then_reuse_session ... [00:00:00.039] Searching for file (100KB-10MB) to cancel...
  [00:00:00.133] No file in common folders, trying recursive listing...
  [00:10:10.749] Starting download of P1110001.JPG (7195648 bytes)
  [00:10:11.428] Read 65524 bytes (0.9%), now cancelling...
  [00:10:12.033] Cancel succeeded
  [00:11:12.033] SKIPPING: list root after cancel - Timeout
  [00:11:12.033]   Check: phone unlocked? USB authorized? Cable connected?
  

  • Resulting logfile: Panasonic_Lumix_DMC_TZ61-git8fef633-2026-06-06-23:52:56.txt
  • It seems the test_cancel_download_then_reuse_session works initially, the output matches the one from above where I returned to a sleeping computer.
    However, the second stage immediately fails on a timeout, which seems weird?
    • Wild guess / gut feeling: the recursion-search isn't actually completed normally, but aborted because after 10m the camera goes into a timeout-mode? Otherwise it would be weird that the timestamps line from this run and the partial-before-sleep line up so precisely on 10 minutes...

Lots of food for thought.
Iḿ sorry that I'm only throwing it over the fence half-digested.

---

For travelers from the future (including myself), the useful one-liners for the fire-and-forget cycles:

# Run all tests, capturing output into a logfile 
#  - including stdout + stderr
#  - timestamped, git-revision stamped
#  - anonymizes logged in username as `username`
RUST_BACKTRACE=1 MTP_TEST_FOLDER=MISC cargo test --test integration -- --ignored --nocapture --test-threads=1 2>&1 | sed "s/$(id -un)/username/g" | tee Panasonic_Lumix_DMC_TZ61-git$(git rev-parse --short HEAD)-$(date "+%F-%T").txt

# ptp_diagnose
cargo run --example ptp_diagnose 2>&1 | sed "s/$(id -un)/username/g" | tee > ptp_diagnose-git$(git rev-parse --short HEAD)-$(date "+%F-%T").txt

# diagnose (with the slooooow recursive listing)
cargo run --example diagnose 2>&1 | sed "s/$(id -un)/username/g" | tee > diagnose-git$(git rev-parse --short HEAD)-$(date "+%F-%T").txt

---

Fun aside: 2048-00-00 isn't an impossible date.. At least according to PHP's distorted logic.
PHP would parse that as "2047-11-30". 🤪
This is marked "Not a bug" by PHP devs..
Before I spoil the link, I invite you to break your brain coming up with their logic.

PHP bug #45647: strtotime() returning 1999-11-30 for 00-00-00 00:00:00, which I have had bookmarked for over a decade because I find such things professionally hilarious and professionally sad.

[vdavid]

Hey Jules,

Wow, thanks for all that input! I found some real bugs along your feedback, plus did a bunch of quality of life improvements.

Let me list what I did. (These are all on main, and CI is green!)

1. Camera dead after cancel: It was our bug! It seems there was no 10-minute-timeout. The timestamps line up because the search visits the same files in the same order every run. The real problem was that the "USB Still Image Class" spec has a step we skipped: after a cancel, the camera reports "Device_Busy" and expects the host to poll GET_DEVICE_STATUS until it finishes; only then does it accept new commands. We never polled (Android doesn't implement that request, and our flow was validated on Android), so your camera waited forever. --> Fixed in 6a90769. Now we do poll after the drains and clear any endpoint halts the camera reports. The cancel test's second stage should now pass.

2. Endpoint stalled: Also our bug. The camera STALLs the bulk endpoint to say "unsupported property" (instead of a nice error response), and that halt remains there until the host clears it, even across program restarts. That's exactly why your immediate re-run failed at GetDeviceInfo. --> We now clear the halt at every spot a stall can happen.

3. The null char: Nice catch! Your camera pads the serial number to a fixed width with several NUL bytes, and we only stripped one. --> Strings now truncate at the first NUL (5a12704).

4. Unstick feature: Added a new mtp-rs reset CLI command (also PtpDevice::reset_device() in the lib). It sends the USB-level Device Reset request (0x66), clears halted endpoints, and drains stale data, all without opening a PTP session (which is the thing a stuck device can't answer). From your checkout: cargo run -p mtp-rs-cli -- reset. It should cure the "Transaction ID mismatch" / "got 2" state. Whether it also cures the full power-button-dead freeze, IDK, but I'd love to hear!

5. Test speed: I took all your ideas. Here is the list:

   • Early exit: The fallback search now streams and stops at the first match. With your 4-9 MB photos it should hit in the first folder, in seconds instead of ~10 mins.
   • The env var MTP_TEST_READFILE=/DCIM/111_PANA/P1110001.JPG sets an exact file, so it can skip the search (thanks for the suggestion!).
   • The found file is reused across tests within a run, so the search happens once, not three times.
   • diagnose caps its recursion at 200 objects.

When you next have time, could you pull main and re-run the suite? What I'm the most curious about is:

1. Does "list root after cancel" pass now?
2. Do the tests after it run instead of timing out?
3. If the camera ever freezes again, does reset fix it?

Re: PHP date logic: Yeah, I did my fair share of PHP (until 2015 I think) and TBH I actually liked it :D So I'm familiar with that 0=-1 behavior for dates, and, well, it's not wrong, but yeah, a bit weird and more error-prone than useful 😅

Looking forward to hearing from you!

(And yeah, I was this quick to do all of these changes because Claude helped a lot with the debugging and implementation. You can see the commit messages are classic AI stuff. But the message above is mine, I only got the technical details from the agent!)

[juleskers]

1. Camera dead after cancel ..

I wish to clarify: not all of those hangs were full "pull the battery"-lockups. That seems to have only happened the one time.
All the other hang-ups I could resolve via the power-button, so it wasn't that big of a deal. 🧡

2. The stalled-fixes seem to suffer the typical problem of iterating-without-hardware-access:
   The fix suffers from a new bug: "Awaiting blocking syscall without an async runtime: enable the smol or tokio feature of nusb."

Full log:

ptp-diagnose-gitf0f2f04.txt

3. Null char in serial number fixed 🎉
4. I tried cargo run -p mtp-rs-cli -- reset to un-stuck the camera, but it suffers from the same "awaiting blocking syscall without an async runtime" error (probably because it tries the exact same thing to clear the stalls)
5. Test speed 🏎️ 🪽

• with the short-circuit finder ✅

  test readonly::test_cancel_download_then_reuse_session ... [00:00:00.057] Searching for file (100KB-10MB) to cancel...
  [00:00:00.148] No file in common folders, trying recursive search (early-exit)...
  [00:00:00.840] Starting download of P1070423.JPG (6841344 bytes)
  [00:00:01.099] Read 65524 bytes (1.0%), now cancelling...
  [00:00:01.706] Cancel succeeded
  [00:00:01.748] Session healthy: listed 2 root objects after cancel
  [00:00:03.138] Second full download succeeded (6841344 bytes). Cancel test PASSED
  

• with MTP_TEST_READFILE ✅

  test readonly::test_cancel_download_then_reuse_session ... [00:00:00.059] Searching for file (100KB-10MB) to cancel...
  [00:00:00.059] Using MTP_TEST_READFILE=DCIM/107_PANA/P1070423.JPG
  [00:00:00.732] Starting download of P1070423.JPG (6841344 bytes)
  [00:00:00.989] Read 65524 bytes (1.0%), now cancelling...
  [00:00:01.596] Cancel succeeded
  [00:00:01.640] Session healthy: listed 2 root objects after cancel
  [00:00:03.026] Second full download succeeded (6841344 bytes). Cancel test PASSED
  ok
  

As for your questions: full log attached: Panasonic_Lumix_DMC_TZ61-gitf0f2f04-2026-06-12-22:44:59.txt

1. "Session healthy: listed 2 root objects after cancel" ✅
2. Tests continue successfully ✅
3. Didn't have a freeze this evening during my quick repro (which is great!)
   I could force one by reverting to the old version, triggering the freeze, and doing the reset, but as I wrote above, the --reset command runs into the missing nusb setting.

---

PHP: We might have different definitions for "wrong". I consider "Accepts dates that do not exist on a calendar and which surprise 100% of normal non-programmers" to be a clear error in interpreting the date-specification 🤷
Then again, I never did any serious PHP-work. The one time I forced myself onto PHP (a Phabricator plugin), in order to "walk a mile in their shoes", I absolutely loathed the amount of footguns every line held, which I of course had to look up beforehand, since it was my first time..

---

Claude / genAI: I am.. conflicted.. on cloud-based, scrape-the-internet-until-it-breaks generative AI.
I personally consider the external costs (including, but not limited to: dos-ing source websites, raising energy prices for consumers, big-tech forsaking their climate goals, hollowing out the copy-left movement) to be not worth increased speed of producing mediocre code.

Then again, the amount of enablement it gives people to do amazing things, especially in Rust-lang (where the compiler helps keep the LLM on-track more effectively than in any other programming language), is undeniable, and makes me wonder what socially-responsible genAI would look like.

I am fairly certain that the price increases in the last few month are just the tip of the iceberg.
Copilot for $38/mo flatrate? Amazing deal, obviously to good to be true.
Given that it's looking like an economically sustainable price is more like 15x-30x that.. No longer very attractive..
I don't believe the hallucination-laden mediocrity that is AI-produced code is worth €500 per month; that's no longer "coffee budget / hobby money", and that seems to be the lower bound for economic break-even..

That said: you're doing something amazing here, regardless of which tools you use, and I'm happy I could help you onwards in your journey 🧡

[vdavid]

Hey Jules,

Oh, oops, looks like I added a bug. It was indeed the "iterating without hardware" problem.

What happened: clear_halt (the call that un-stalls an endpoint) is a blocking operation in nusb, not an async one. I .await-ed it, which panics unless you turn on nusb's tokio/smol feature. We're deliberately runtime-agnostic, so the fix is to run it synchronously with .wait() (same thing we already do for claim_interface). The async-looking control_in/control_out calls were fine, only clear_halt was the troublemaker.

Fixed in 58e8ff8. And yeah, this never showed up in my tests or CI, because a STALL only happens on real hardware, never against the mock device. Thanks for testing it!

Everything else from your last batch looks great.

Could you re-test on latest main when you find the time? The two paths that were broken are:

• cargo run --example ptp_diagnose (should get past the property probes without panicking now)
• cargo run -p mtp-rs-cli -- reset (the unstick command)

If it works, I'd be happy to cut a release.

---

On the genAI stuff:

• I somewhat agree on your energy/climate point, although, model training is what seems to take a lot of compute, while inference is relatively cheap. So if we just used the current models and didn't develop new ones, it'd be much more sustainable. (It's not the business reality, though, not to train new models 😅) Anthropic is profitable now, which proves to me that their current pricing is the right price for inference, and they can even cover their new model training efforts from it.
• The copyleft point is totally true, and sad. Plus, I'm genuinely worried about the increased RAM+electricity cost affecting everyone, while the benefits centralize in few hands. That's very much not nice.
• With the "mediocre code" point, I totally disagree, actually. I do agree that there is a lot of AI slop in the world now, and that non-tech people will inevitably produce slop with the current tooling. But when I write code with AI, even when it's 100% AI-generated, it's totally not slop. I'm actually proud of the code quality, and I think it's better than what I'd produce on my own. Saying this after 30+ years of coding in the traditional way. I use tons of guardrails, reviews, feedback loops, and the best models (which counts a lot!). I think mtp-rs is a great example, actually: MTP either works or doesn't work, right? Like, the lib either messes up device state, data consistency, etc., OR it doesn't. Well, mtp-rs surely wasn't perfect in the beginning, but after real-device tests (like what we're doing, and what I did with my own devices), and a few fixes, it just works. I mean, even if I decided to code mtp-rs 100% manually, it'd probably have been just as buggy and wouldn't have worked with your old cam until we tested. So I see not much difference besides speed. And yeah, Rust's strictness helps, sure, but my main project, Cmdr is about 40% TypeScript/Svelte, and AI-first coding works equally well there.

Devs are still extremely divided on this topic now, so I know this is all pretty controversial. But I've been skeptical with AI-generated code until it gradually earned my trust, and I'm now super confident in the quality of the code I produce with AI.

David