To be clear, it's definitely not something in the video conversion, because it still happens when the TV's volume is set to zero (and it *doesn't* happen for the same video file on the original card, too).   I guess it's just something that some brands of SD card do, oh well.

I'm not sure what you mean by "unzip the libraries [...] but what about the 3 zip files?".   The 3 zip files *are* the libraries that you're unzipping.

Actually, I am having one strange phenomenon after having upgraded the microSD card: even with the volume turned all the way off, there's now a noticeable sound whenever the TinyTV reads from the disk; buzzes when changing channels, and regular ticks during video playback.  (I can tell it's disk access, because it buzzes for longer when switching to a longer channel, and it ticks more frequently when playing higher-bitrate video....)   It's only noticeable when holding the TinyTV close to my face, though.   I tested switching back to the original microSD and that indeed made the noise stop.

I haven't reproduced it on my end yet, but if anyone is curious to experiment, here's two four-hour timestamped test files, with different bitrates to rule out whether it's about timestamps or bytes:  http://img.ravenworks.ca/download/TinyTV-Test-4h.zip

I can say, with it set to start at a random point, I've absolutely seen it play video past the 2-hour mark, so maybe it's more about the TinyTV having been *on* four two hours, than about it reaching the 2-hour mark in the file?

Got it, thank you!  I've gotten it open and gotten the card swapped safely.  The only part that tripped me up a little was that the battery was glued to the original card, but I got it loose with some gentle prying.

The good news is, I can confirm that you can raise the limit, at least somewhat -- I've turned it up to 200 and haven't had any problems yet.   (I never added that change as a pull request on the official firmware though, because no-one ever answered me about if there was some downside I'm not aware of -- although they seem to have stopped merging pull requests anyway...)

Can you be more specific about the errors you're getting?  Arduino IDE is working for me, although I don't remember what steps it took to reach this point any more...

Can you figure out exactly what timestamp it restarts at?  2 hours doesn't seem to correspond to anything in particular, in terms of seconds or frames or audio samples, other than maybe a 1 GB filesize....

The longest file I've tried is 1.5 hours and I haven't noticed any trouble, but I was planning to add something longer myself soon so I would like to know where this stands.

I've had some pull requests sitting on the github since May; is development still ongoing?

Does anyone know where to find advice from these "brave users"?  I'm interested in trying to expand my storage, and would like some advice about where to start disassembling the TinyTV2, even if it isn't "supported"...

well, fwiw, I just bumped it to 200 and everything still runs, and I was able to view 101 files just fine; I didn't even have to change the channel-number-drawing routine?

The source code to TinyTV2.h says that the maximum number of video files is defined as 100...  Would it be as simple as increasing that number if I wanted to raise the limit, or is there a technical reason that it can't go any higher?   (If it's about the number displayed in the corner when you change channels, I could fix that to match...)

I just did a fresh build of the latest firmware on the github and immediately noticed how much paler everything was, because until just now I'd been using the modified SetXY file from your last post, which I guess has never actually made it into the official builds?  Should I propose it as a pull request at this point, or do you want to add it yourself?

Yeah, that addresses the problem I was having!  (To be more specific, values that were negligibly close to zero on a normal screen, were flickeringly apparent on the TinyTV as the video compression rounded them up and down from frame to frame -- with this source tweak, that no longer happens, and effectively-black areas now all look basically uniformly black like they should.)   Anecdotally, I have a hunch that colors are slightly more vibrant now too, though I might be imagining that?   Anyway, I definitely approve this change -- that's one less ffmpeg script that I'll need to keep lying around to adapt things for the TV

out of curiosity, while we're talking about things that don't quite behave normally -- has anyone looked into whether it's handling gamma properly?   I've put some dim videos on there that looked far far too bright/pale and banded, and I had to tweak the levels manually in ffmpeg to get them to look even remotely like they do on my desktop....   but I haven't sat down and investigated it properly yet.

I definitely greatly prefer the random value personally, although I could see someone preferring the resuming feature?   What's the reason for not wanting to give people the option?