Hi, sorry about that! We may have talked via email, but if you are in the update mode with the RPI-RP2 storage available you can download the latest firmware UF2 file here and copy it to that drive: https://github.com/TinyCircuits/TinyCircuits-TinyTVs-Firmware/tree/master/binaries (click the correct UF2 file for your TV, then click 'Raw' to download the actual file).

Hi- thanks for supporting us and Supreme, sorry about the problem with your TinyTV. That means the filesystem has become corrupt somehow, obviously that should not be happening out of the box. Our first troubleshooting step would be to ask you to try the red format button at https://tinytv.us/Settings (you should be able to connect to it there even if the storage drive did not show up). Most people's TVs work fine after that. If you want to reload the videos or that doesn't work, please email info@tinycircuits.com and we'll try to get this corrected asap.

Thanks,
Ben

Hi- yes, it's counterintuitive but the file size can increase due to the encoding used within the AVI file. TinyTV uses a very low power microcontroller so the AVI contains a MJPEG video stream and uncompressed audio which is all it can handle. The compression ratio is low compared to H264 that might be in a MP4 file, but that's how we're able to achieve the video playback on a device this size/cost.

Thanks,
Ben

Yes, for the TinyTV DIY Kit you can replace the battery with a switched 3-5V supply connected to the JST SH connector. Note that 5V should absolutely not be exceeded on this input! It can damage the battery charging circuit. Less than 5V will not damage the battery charging circuit.

Thanks,
Ben

Ok- that sounded pretty reproducible, so I tested a few longer movies here and sometimes got the "always starts at the beginning", sometimes not. Started digging and it looks like we have issues properly handling any movie over 1GB! I'm pretty sure only the first 1-2 hours(1GB of the file) are playing back. We haven't heard about this at all! So maybe some large videos pop out of the converter(ffmpeg) differently and are compatible. But that lets me start working on FW changes to hopefully address this.

Thanks,
Ben

Thanks for all the feedback! Glad you like it overall but sorry about the SD card failure! We'd replace it if you like but sounds like you're past that.

We had one other post about some videos starting at the beginning but that user said 8 hour videos worked, but 10h+ did not, so I didn't put it too high up our list- if you have a shorter video that doesn't, any way you could send that our way? I'll test it here and see if I can reproduce the issue. We should be able to get it fixed up.

What I think you're seeing is the 'live' video playback where each channel is always 'playing' on loop- try updating to the latest firmware if you haven't already, and turn off the Live Video and Random Start Time settings on the settings page. Videos should start at the beginning every time then, let me know.

Hi, sorry about the issue! Honestly, that sounds like a firmware bug- there would be some finite limit that could be between 8 and 10 hours. If you can, please try making the videos a little shorter or split in half etc, and let me know if that works for you- hope that can fix it before Christmas!

Thanks,
Ben

Hi- sorry about the documentation issue, it's definitely old news and I think documentation was reverted a few times while we worked on different solutions. We've landed on the new app( https://tinytv.us/TinyTV-Converter-App/ ) supporting both TSV(in a menu option) and the AVI format we're using in the new cross platform firmware. I just submitted some website changes that should cover what you were seeing that's still pointing to the TSV converter. Let us know if the new app is working for you.

Thanks,
Ben

Yes, pullup resistors should be available and implemented on all pins for the TinyScreen+, let me know if you're seeing an issue with that.

Thanks,
Ben

Hi John, looks like the Color Sensor Wireling to me, at https://tinycircuits.com/products/color-sensor-wireling - it works by having two LEDs for illumination and a color sensor between them.

Thanks,
Ben

Some LCD initialization values seem to have changed back to some generic values instead of what was recommended by the LCD manufacturer(well, distributor)- I attached an adjusted file that you could throw in your TinySceen library within the firmware source folder. It definitely changes how some colors are displayed, other stuff, not so much- I'm not sure if the change is 'good' or not really. Let me know if you try it.

Hmm.. I think this is most likely an issue at the LCD initialization level or possibly in the JPEGDEC library. Also keep in mind some limitations of a lower cost LCD with 16 bit color, but I do think it can be better. I'll try to look at the initialization today.

Thanks! I should keep up with this thread with some things I've found recently. We've needed to add some additional audio filters to handle certain input streams, the audio filter portion we're testing looks like:

Code Select Expand

-ac 1 -acodec pcm_u8 -af "volume=0.0dB,aresample=10000,aresample=async=1000,aresample=osf=u8,asetnsamples=n=210:p=0"

The asetnsamples is the important part, 210 is a somewhat arbitrary value that results in about 2 chunks of samples per video frame, which the TV firmware can easily consume. Typically ffmpeg does something like that with the average mp4 input, but some inputs can result in huge chunks of audio spanning many frames, which the TV firmware can't handle.

Somewhat unexpectedly, the conversion to 8 bit seems to lower amplitude on some streams, so it seems like we need to run volumedetect on a resampled stream, for example:

Code Select Expand

ffmpeg -i input.mp4 -vn -ac 1 -af "aresample=10000,aresample=async=1000,asetnsamples=n=210:p=0,aresample=osf=u8,volumedetect" -f null /dev/null

The absolute value of the peak output value can replace the 0.0dB in the first snippet to normalize the way that https://github.com/slhck/ffmpeg-normalize does peak normalization. This seems to get things peak normalized without clipping in the testing we've done.

We do plan to get this integrated into the app but I'm not sure exactly when!

Well, very cool, sorry you had to put time in on this but I think that's a valid path to let the interrupt states variables run, but only 'keep' the latest change. Did you test this with decreasing timeouts? For example 10ms instead of 20ms? Just out of curiosity as to how much time is needed for your hardware with the more significant issue.

Otherwise, we'll test here and I'll let you know how it goes.

Thanks,
Ben