The datasheet said "6ms bounce, 6ms jitter", so I tried 6ms, and had one bounce in couple dozen tests....  then I realised that the datasheet might be trying to tell me to use 12ms total... and then I said, hell, let's be safe, if the frame rate is so low anyway, and bumped it all the way up to 20 like the power button uses.....    but then even at that point, I still got a single bounce in a few dozen more tests, so I gave up adjusting anything, lol.   So yeah, the exact numbers are a little up for debate (especially since, like I mentioned in the pull request, I realised that there's actually a slight bug, in that it'll wait for the specified duration AFTER the signal settles....  but again, it didn't seem worth worrying about because these amounts are still imperceptibly small, to me.)

I don't even have to reformat, I can just tell windows to "fix" it, which makes it stop but leaves the data intact.    It just, comes back again sooner or later.   Note the end of the world, but I thought I'd see if there was a permanent solution just in case.

Good news; I finally got some time off work, and gathered up the executive function to read that datasheet, and I've now got a pull request in that fixes the debounce issue   So hopefully there's no need for me to send it back in after all, at this point.

So actually, things have gotten moving again, and if you're prepared to build the firmware yourself, it's up as a pull request right now:  https://github.com/TinyCircuits/TinyCircuits-TinyTVs-Firmware/pull/8

If not, hopefully they'll have an official build up soon, but if they don't, I could put mine up in the meantime.    (I'm actually getting debounce in at the moment...)

Windows seems very prone to telling me that there's a problem with my TinyTV's drive, when it's in USB Storage Mode.   It offers to fix it, and if I let it, it tells me there was no problem after all, so I guess it's harmless?    But it is annoying, and gives me one more thing to click through whenever I try to change the files on it;  does anyone else get this, and is there anything I could be doing differently to prevent it?

The whole thing sort of went on hold while I waited for them to review my first pull request, which I think hasn't happened yet....  so at this point, maybe I'll just publish my own fork of the firmware and worry about whether it gets merged down the road....    I'm going to be a little occupied the next few days, but I'll try and look it over and put it online soonish, and I'll post here when I do!

I have a feeling there's nothing to be done about this, but I thought I'd just check:  is it normal that adding new files to the TinyTV 2 tops out at about 700 KB/s?  Or is it something that I could possibly improve with a different cable, or USB port, or something.

Sure, I'm willing to send the old one back if it helps the process.  Things are crazy at work right now though so I might not get around to it for a couple of weeks.  I will need your address though, yes.

I've got the old one set aside for now (with a little sticker on it so I can tell it apart from the new one) and with the default videos loaded back onto it.   Also just mentioning before I forget: at the moment it has your debounce test firmware on it (which causes the wheel to simply be ignored a lot of the time).

Okay -- the new one arrived, and it's got the same problem!   It's only like 1 in every 6 turns now, which is way better than the old one....  but the old one started that way too, and gradually got worse over a few weeks, so only time will tell if the new one is headed down the same road :/

I'm officially back on team "can we implement any kind of proper software debouncing", then.   How does the encoder mechanism work internally, is it switches or what?  Are there docs for the drivers that read the values?

OK, I just tried your patch -- now the situation is like:
- 25% of the time, it changes channels as it should
- 25% of the time, it changes channels correctly for a split second but then automatically changes back to the previous channel a split second later (so, similar to the original problem, just with a tiny flash of the intended channel first)
- 50% of the time, turning the wheel does nothing, no static or anything.

At this point, I think I'd be willing to drop it, assuming my replacement TV doesn't have the same problem.

Someone's already taking care of it on the email side of things, thanks
I'll try this change soon!

Checking back in here to say I've got this working (as an extra option in the settings file) in my checked-out copy of the source; I'll file a pull request once my previous pull request (customizable power-off timeout) goes through (I don't want to worry about awkward merges between them).

Okay, good news and bad news!   I can finally build my own firmware for the TinyTV, and I implemented some simple debouncing!   The good news is, turning the dial to the RIGHT, now always works perfectly...  the bad news is, turning it to the LEFT, has about a 50% chance of going RIGHT instead.   Which means turning it to the left tends to pingpong back and forth between two channels most of the time.     From looking at the logic in the program, now I'm imagining that what's happening is, both values (channelUp and channelDown) are actually getting set to true on a SINGLE FRAME, which means there's no way to determine which way it was meant to go, without going deeper.

So at this point, part of me is tempted to say "tell me about the logic in the encoderPinChange function", but.....   given that no-one else is complaining about this, and this is starting to look like something that there might not *be* a software solution to...   most of me is tempted to just take you up on your offer to send me replacement hardware at this point, LOL.

Just following up to say, I'd still like instructions on how to make the upload button work for convenience's sake, but, I followed the instructions here: https://learn.adafruit.com/adafruit-feather-m0-express-designed-for-circuit-python-circuitpython/uf2-bootloader-details (which amounted to "drag any UF2 file onto the drive that mounted when you launched into bootloader mode") and going the "export compiled binary" route now appears to have worked!!

Thank you, bootloader mode worked!   Now, when I click 'upload', it builds with a number of warnings and notes but seemingly no errors, but then it says

Property 'upload.tool.' is undefined