So slowing down the display is the only fix then? ugh, ok. I would've thought for a display as expensive as this (I think I paid $250-280 2 years ago), they could've at least doubled the buffer size. I'm still fighting other display issues in my code. It would be nice if this one weren't in the mix.

Well, I've found that to send 40 chars/line, a usleep(90000) (90,000 microseconds) seems to be as fast as I can go after writing any line. The problem with this is that this creates a noticeable scroll as the screen wipes... it's not pretty. I had it at 45,000 microseconds, which wasn't too bad, but...

btw, just so it's clear that it's the serial port/LCD, I inserted a sleep(1) function (delays 1 second) after every line and all rows displayed properly.

This is a showstopper for me. I need a fix.

BTW, the exact contents of frame is this: row 1: Christian Rock.m3u row 2: Handel's Messiah - Soulful.m3u row 3: Life is good.m3u row 4: New Stuff.m3u row 5: Peaceful.m3u row 6: Praise and Worship.m3u row 7: The Very Best.m3u Were it a perfect world, those would all display with no problems. Oh, and...

The problem is that when I fprintf() a lot of characters to the LCD, it will act as though a clear screen command was issued somewhere in the middle of it (my guess is buffer overflow) and then continue printing the characters from that point on. The connection is set to 115200 bps. I haven't tested...