[etgecata]

There is no point in these tests:
https://github.com/xbmc/xbmc/pull/22664

Users had a different opinion ?
Only Nuklear92 has a different opinion...
Because of this, they won't come in and help...Since Nvidia Shield users are so few and of no interest to you, why were there all these test builds? Is it that hard to make an option in Kodi for the user to change the setting if stuttering occurs?

[fritsch]

Read the entire post, please. We make small steps ... to not cause regressions. Review will be finished over the weekend and then I will push the changes.
Then we continue. It's not good if too much changes are tested at once ...

[Nuklear92]

..

[Blackysb]

New to the party, Iv'e experienced the truehd drop outs and video stutter on the shield. 
Happy to do some testing this weekend. 
Just to be clear I'm testing the nightly vs fritsch that has advanced setting included to see which performs better? 

Which nightly and witch fritsch build should I be testing?

[Draconix]

Read the entire post, please. We make small steps ... to not cause regressions. Review will be finished over the weekend and then I will push the changes.
Then we continue. It's not good if too much changes are tested at once ...

This is the correct approach, @fritsch knows what he's doing.
After he rolled back most of the changes, it has become clear to me that the only thing needed to solve the Shield issue is: the advancedsetting "maxpassthroughoffsyncduration".

[fritsch]

New testing round starting.

As review is nearly done on github for this minimal set and it will get merged the very moment me and @jogal discussed all the nitpicks , we can continue something new.

During review I have seen that a workaround for other devices was dropped a year ago without me realizing. I don't like regressions I wanted to get that back in. Also breaking the single box that can do TrueHD / DTS-HD-MA besides the Shield as of one year ago, feels bad.

Sadly, this changes once more - the period / buffer size of TrueHD and DTS-HD-MA. Therefore here is the build for you guys for TrueHD / DTS-HDMA regression testing. It includes the minimal set, which is merged soon and the return of the other HD capable box.

Here we go:
https://jenkins.kodi.tv/view/Android/job...64-v8a.apk

[izprtxqkft]

@fritsch
may i please ask a single question (technically 3 including asking permission)
is this in any way to do with the ffmpeg core, is it overriding or changing behavior with it and if so will this be negated when going to ffmpeg 5.x?

[Draconix]

Sadly, this changes once more - the period / buffer size of TrueHD and DTS-HD-MA.

Uh oh.. . Will test in a few hours when I have free time. Should I make two logs again to test default vs advancedsetting?

[fritsch]

@fritsch
may i please ask a single question (technically 3 including asking permission)
is this in any way to do with the ffmpeg core, is it overriding or changing behavior with it and if so will this be negated when going to ffmpeg 5.x?

No, there is no relation to this at all. The Bitstream Parsers and Packers are kodi code. We have longterm plans to use the spdifenc from ffmpeg as through the years it can do that stuff even better than us. The issue that lead to the TrueHD issues has a longer history ... one key change was to support "high bitrate truehd files" which sometimes have more data for certain frames, while on average still being on 24 Mbit/s. This in combination with some nasty regressions, introduced as some side effect during development and - yeah - no one testing nightlies, when every Hinz and Kunz provides yet another super dooper build ... made that stuff a bit complicated. Other stuff like Dolby Transcoding was broken through to ffmpeg5, but this was our own beef. FFmpeg is one of the best libraries on this planet, one can learn a lot from those guys concering API governance, ABI / API compatiblity.

Current situation looks not so bad ... still we need to move forward a bit. The current stuff now "works okayish", but I personally still want to find a way to fixup the TrueHD packing ... to restore the datarate == payloadrate correlation.

[fritsch]

Sadly, this changes once more - the period / buffer size of TrueHD and DTS-HD-MA.

Uh oh.. . Will test in a few hours when I have free time. Should I make two logs again to test default vs advancedsetting?

Nope. Not needed for the advancedsettings. I would be happy if you tell me regressions and post two normal debug logs ... I am focussing on period time and period size again.

[izprtxqkft]

thank you very much for your answer and your time

[fritsch]

thank you very much for your answer and your time

Welcome. You asked very politely and I had some time :-)

[Draconix]

Here we go:
https://jenkins.kodi.tv/view/Android/job...64-v8a.apk

I tested this new build's default behavior (no advancedsettings.xml) and I saw a significant improvement over the previous build's default behavior. All files tested were TrueHD: https://paste.kodi.tv/ubomanizuy.kodi

I noticed far fewer stutters than before, and I think if you compare this log to my previous log (without advancedsetting), you'll probably find less ErrorAdjust. You'll obviously have to fully analyze this new log to check for regressions.

Next: I will test DTS-HD MA and DD+. After that, I'll put back the advancedsetting and see if I can once again get perfect playback.

[Input1963]

This android build works very good, but just a little question for the specialists. 
What are the best settings for the  advancedsettings.xml if you have 3Gb mem (Nvidea shield 2019) or is it better with no  advancedsettings.xml?

Thx
H.

[fritsch]

This android build works very good, but just a little question for the specialists. 
What are the best settings for the  advancedsettings.xml if you have 3Gb mem (Nvidea shield 2019) or is it better with no  advancedsettings.xml?

Thx
H.

None needed if there is nothing to fix.