Well this is damn pleasing to hear
Sounds like that nasty bug is gone.
Out of >20,000 lines of code the fix was already pointed out by Anssi a few weeks ago, and included in the last build, just mis-converted from ffmpeg code:
- packet->m_length = ((size + 0x9) &~ 0x9) - 0x8;
+ packet->m_length = ((size + 0x17) &~ 0x0f) - 0x08;
A simple hex conversion error was causing the grief, but very hard to spot in a huge list of parsing and re-packing code, and ofc it was working okay on some equipment including ours so even harder to track.
Aemstel, another diligent tester for us, has reported back that it's fixed on his setup too. Also reported perfect sync compared to all the non-AE builds out there including Daniela's, which is based on stock XBMC and ofc has the same 24p sync issues as stock XBMC. This is a pretty huge step on it's own - that issue has been a major one here in the forums. Still trying to tighten up further - the Win sync is a little laxer than Linux right now, I believe due to background Windows processing but I'm working on that.
ix400 - Aemstel's not seeing the buffering - still looking at what may be the cause there. One thing I note is that ffmpeg has a tough time with that ZZ-Top rip (and I have a rip of that without issues). There are many ffmpeg errors opening/reading it at loglevel 2. Do you have any other test material to try?