[fritsch]

Thanks - I am an i**t ;-) - increased the wrong timeout - here, what happens here: https://jenkins.kodi.tv/job/android-arm6...64-v8a.apk - curious.

[Draconix]

Thanks - I am an i**t ;-) - increased the wrong timeout

Haha, no worries!

Here's the debug log: https://paste.kodi.tv/ihutewisep.kodi
Video was perfect again, but I heard 3 dropouts in the exact same spots as usual.

EDIT: I noticed 3 ErrorAdjusts in between the CPackerMAT stuff, could those indicate the dropouts? In the past, ErrorAdjusts usually ended up causing a video stutter, but I don't see any stutters at all here.
           I don't have anywhere near the knowledge that you guys have, but my guess is that instead of adjusting the video (creating a stutter), it's adjusting the audio (causing a dropout).

[fritsch]

I told AE to ignore error thresholds up to 200ms in this build. And as you see the "type of error" changed. Now Audioclock is unhappy with the timestamps it gets from Packer.
Still: Why your setup causes such things has nothing to do with that - as you see from others that is specific to your Shield, it is not caused by kodi, but by something else outside.

Though - what I think to see here is - that when kodi detects YOUR issue it does not too nicely cope with it. From my look it seems that AE is trying to adjust, which causes the Packer to think that "something" is missing, which AE WANTS to be gone to get its audio clock back into sync. And this combination causes those two to fight against each other. Kodi uses "two clocks": one for audio, one for video and tries to get them in sync by adjusting them both towards audio and video PTS. This has multiple advantages as they can run in different speed. This syncing happens on the start or whenever discontinuities happen.

Still: Why your setup causes these effects in the first place is entirely open and has nothing to do with kodi code.

You might want to capture adb logcat - maybe you see something in the combination that is responsible for the root-cause, f*cking up those things outside of kodi.

[Draconix]

You might want to capture adb logcat - maybe you see something in the combination that is responsible for the root-cause, f*cking up those things outside of kodi.

How do I do that, and would it provide useful information? Also is the current theory that I have a defective Shield unit?

[Hitcher]

Can you plugin the Shield directly into the TV and test it? Assuming your TV can play TrueHD Atmos that is.

[fritsch]

You might want to capture adb logcat - maybe you see something in the combination that is responsible for the root-cause, f*cking up those things outside of kodi.

How do I do that, and would it provide useful information? Also is the current theory that I have a defective Shield unit?

Current knowledge is: your specific system as a whole behaves completely different than everyone else's. Even we have several additional Shield testers here and testers with other devices that don't l.

In theory: AVR, TV, some processes in the shield can be the cause.

[Draconix]

Can you plugin the Shield directly into the TV and test it? Assuming your TV can play TrueHD Atmos that is.

My TV is the LG G4, so I'm pretty sure it can play TrueHD Atmos. It's really difficult to get to the wiring behind the TV stand... it can be done but it's not easy. I'm assuming you're trying to rule out the AVR being the problem?
 

In theory: AVR, TV, some processes in the shield can be the cause.

Can it really be the AVR even though the dropouts show up as errors in the debug log? I'd assume that if it's only the AVR's fault, I'd hear dropouts even if there are no errors in the log.

Anyways, it's starting to feel like there's probably no way to fix it. It only happens in Blu-rays with that seamless branching stuff, so it shouldn't be too common. Even though it's not ideal, I'll just have to use the AC3 compatibility tracks for these kinds of movies.

[RedTwenty50]

Glad to see that mkvmerge may be a tool to use for these titles. I have some logs from the kodi-20240513 build linked in the first post, and used the samples that you provided.

Avatar did not have any issues I could detect for it's duration (log here). Cars is still troublesome, but I think the way it occurs now on mine is very interesting, in that I think now it may actually be reproducible, as the issue happens at fixed points and when I did the below steps twice, the same thing happens both times. The logs are here for the second run through I did and I did happen to note some timestamps for the Cars log as it happened, which should hopefully help:
17:45:59 - Complete cut out, had to restart file
17:48:35 - The little quick drops that seem more like a skip
17:50:12 - Complete cut out, had to restart file

I ensured Kodi was no longer running in the background and then launched Kodi and Cars, and while watching it the first time, I completely lose audio around the Cars logo at 2:12 - 2:22 minutes in, which rewinding doesn't solve. I then stop and restart the file, and once it again reaches that point, instead I get some very quick drops within a second (almost sounds like a skip, it's very quick now) and then it keeps going normally, up until the point we see the 3 cars with the commentators at 3:50 minutes in, and it again cuts out where rewind doesn't fix it.

Note: The first time was with my normal Kodi settings, and the second time was a clean install (wanted to make sure the problem still occurred on a clean install to remove that variable)

[RedTwenty50]

Anyways, it's starting to feel like there's probably no way to fix it. It only happens in Blu-rays with that seamless branching stuff, so it shouldn't be too common. Even though it's not ideal, I'll just have to use the AC3 compatibility tracks for these kinds of movies.

May I suggest if going this route, to instead try one of the two workarounds I have found to work in the meantime? (from my original thread)

This way either way you get lossless 7.1, rather then lossy 5.1, but it basically boils down to:

1. Disable audio passthrough on Kodi and get Kodi to decode the audio (Lose Atmos Channels/Data, but retain everything else)
   
2. Use VLC with passthrough (You will retain TrueHD Atmos, but lose the Kodi player interface and Dolby Vision)
   

[fritsch]

Can you plugin the Shield directly into the TV and test it? Assuming your TV can play TrueHD Atmos that is.

My TV is the LG G4, so I'm pretty sure it can play TrueHD Atmos. It's really difficult to get to the wiring behind the TV stand... it can be done but it's not easy. I'm assuming you're trying to rule out the AVR being the problem?
 

In theory: AVR, TV, some processes in the shield can be the cause.

Can it really be the AVR even though the dropouts show up as errors in the debug log? I'd assume that if it's only the AVR's fault, I'd hear dropouts even if there are no errors in the log.

Anyways, it's starting to feel like there's probably no way to fix it. It only happens in Blu-rays with that seamless branching stuff, so it shouldn't be too common. Even though it's not ideal, I'll just have to use the AC3 compatibility tracks for these kinds of movies.

Why speculating? In every thread about TrueHD, we discuss issues that only affect you - this is not the scope of those threads. Therefore: Open now your own thread, enable adb logging in the shield and provide the adb logcat and the kodi Debug Log together. Maybe your logcat of Android shows something that correlates.

[fritsch]

Anyways, it's starting to feel like there's probably no way to fix it. It only happens in Blu-rays with that seamless branching stuff, so it shouldn't be too common. Even though it's not ideal, I'll just have to use the AC3 compatibility tracks for these kinds of movies.

May I suggest if going this route, to instead try one of the two workarounds I have found to work in the meantime? (from my original thread)

This way either way you get lossless 7.1, rather then lossy 5.1, but it basically boils down to:

1. Disable audio passthrough on Kodi and get Kodi to decode the audio (Lose Atmos Channels/Data, but retain everything else)
   
2. Use VLC with passthrough (You will retain TrueHD Atmos, but lose the Kodi player interface and Dolby Vision)
   

Nice advice - but - to my knowledge VLC's packer cannot cope with the blurays this new packer was implemented. So - would not help at all for Cars and such.

[Draconix]

This way either way you get lossless 7.1, rather then lossy 5.1, but it basically boils down to:

1. Disable audio passthrough on Kodi and get Kodi to decode the audio (Lose Atmos Channels/Data, but retain everything else)
   
   
2. Use VLC with passthrough (You will retain TrueHD Atmos, but lose the Kodi player interface and Dolby Vision)
   

Both of those workarounds aren't worth it for me. I think Kodi is way better than VLC and I don't want to lose Atmos or Dolby Vision.

@fritsch, the build you made me with the 200ms threshold is the best one so far, with only 3 dropouts instead of 4-5.
It completely eliminates the random dropouts and the remaining 3 always happen at the exact same spots.

Looking at the log, I believe the dropouts happen at these 3 ErrorAdjusts:
2024-05-14 17:23:38.949 T:10898   debug <general>: CDVDClock::ErrorAdjust - CVideoPlayerAudio::OutputPacket - error:-186674.909266, adjusted:-186674.909266
2024-05-14 17:23:38.955 T:10897 warning <general>: OutputPicture - timeout waiting for buffer
2024-05-14 17:23:43.213 T:10897    info <general>: Skipped 14 duplicate messages..
2024-05-14 17:23:43.212 T:10897   debug <general>: CPtsTracker: detected pattern of length 1: 41708.33, frameduration: 41708.333333
2024-05-14 17:24:06.598 T:10898   debug <general>: CDVDClock::ErrorAdjust - CVideoPlayerAudio::OutputPacket - error:113257.050750, adjusted:41708.333333
2024-05-14 17:24:08.074 T:10834   debug <general>: Thread JobWorker 213952588992 terminating (autodelete)
2024-05-14 17:24:08.074 T:10846   debug <general>: Thread JobWorker 214194076864 terminating (autodelete)
2024-05-14 17:24:08.074 T:10837   debug <general>: Thread JobWorker 213998709952 terminating (autodelete)
2024-05-14 17:24:08.075 T:10836   debug <general>: Thread JobWorker 213980892352 terminating (autodelete)
2024-05-14 17:24:51.572 T:10793 warning <general>: CPackerMAT::PackTrueHD: detected a stream discontinuity -> output timing expected: 63336, found: 63296
2024-05-14 17:24:51.572 T:10793 warning <general>: CPackerMAT::WritePadding: a large padding block of 96262 bytes is required due to unusual timestamps
2024-05-14 17:25:08.294 T:10793 warning <general>: CPackerMAT::PackTrueHD: detected a stream discontinuity -> output timing expected: 12168, found: 12128
2024-05-14 17:25:08.294 T:10793 warning <general>: CPackerMAT::WritePadding: a large padding block of 111414 bytes is required due to unusual timestamps
2024-05-14 17:25:44.390 T:10793 warning <general>: CPackerMAT::PackTrueHD: detected a stream discontinuity -> output timing expected: 43952, found: 43912
2024-05-14 17:25:44.392 T:10793 warning <general>: CPackerMAT::WritePadding: a large padding block of 110856 bytes is required due to unusual timestamps
2024-05-14 17:25:52.070 T:10898   debug <general>: CDVDClock::ErrorAdjust - CVideoPlayerAudio::OutputPacket - error:109623.829405, adjusted:41708.333333
2024-05-14 17:25:58.811 T:10793 warning <general>: CPackerMAT::PackTrueHD: detected a stream discontinuity -> output timing expected: 15736, found: 15696
2024-05-14 17:25:58.811 T:10793 warning <general>: CPackerMAT::WritePadding: a large padding block of 111132 bytes is required due to unusual timestamps
2024-05-14 17:26:38.149 T:10898   debug <general>: CDVDClock::ErrorAdjust - CVideoPlayerAudio::OutputPacket - error:110033.441018, adjusted:41708.333333
2024-05-14 17:26:49.242 T:10793 warning <general>: CPackerMAT::PackTrueHD: detected a stream discontinuity -> output timing expected: 11344, found: 11304
2024-05-14 17:27:02.383 T:10793 warning <general>: CPackerMAT::WritePadding: a large padding block of 113656 bytes is required due to unusual timestamps
2024-05-14 17:27:29.439 T:10793 warning <general>: CPackerMAT::PackTrueHD: detected a stream discontinuity -> output timing expected: 42720, found: 42680
2024-05-14 17:27:29.439 T:10793 warning <general>: CPackerMAT::WritePadding: a large padding block of 112904 bytes is required due to unusual timestamps
2024-05-14 17:28:12.869 T:10793 warning <general>: CPackerMAT::PackTrueHD: detected a stream discontinuity -> output timing expected: 29648, found: 29608
2024-05-14 17:28:12.870 T:10793 warning <general>: CPackerMAT::WritePadding: a large padding block of 113312 bytes is required due to unusual timestamps
2024-05-14 17:28:18.501 T:10898   debug <general>: CDVDClock::ErrorAdjust - CVideoPlayerAudio::OutputPacket - error:127843.651969, adjusted:41708.333333

Would it be possible to make me a 200ms build that has a less sensitive CDVDClock? If we can stop those bottom 3 ErrorAdjusts from happening then maybe there wouldn't be dropouts. Though I'm not sure if that could cause other issues like bad AV Sync or something, but I think it's worth a try. If you do end up making me a build that works well with my specific Shield, I'd be fine sacrificing updates to stay on that build. Kodi is already perfect for me in every way except for these dropouts in seamless branching Blu-Rays.
 

Open now your own thread, enable adb logging in the shield and provide the adb logcat and the kodi Debug Log together. Maybe your logcat of Android shows something that correlates.

Ok, thank you for the suggestion! I will first need to look up how to make a logcat.

[Koder123]

My two cents for Cars mkv sample, sorry for no logs:

Shield Pro 2019 8.x firmware, WebDAV / WiFi source (fast), Omega, cache adaptive / 64MB / 256k

1) sync setting 62 - I get 2-3 very visible "frame drops", no clear audio drops, a/v corrections 5
2) sync setting 96 - no visible frame drops, single clear audio drop at the end, a/v corrections 0

With MAT Packer rework:

1) sync setting 62 - no visible frame drops, single clear audio drop around 3 min, a/v corrections 5
...but then running another round I get frame drop but no audio drop...

[BenMcLean]

I installed this and not only did it fix the DVD ISO issue, it also fixed an issue I've been having with newer versions of Kodi that had the right and left shoulder buttons on my SHIELD controller reversed. Great job.

But Kodi 21 shouldn't have been released with a known issue this bad. It wasn't ready.

[RedTwenty50]

Nice advice - but - to my knowledge VLC's packer cannot cope with the blurays this new packer was implemented. So - would not help at all for Cars and such.

I can't speak for the entire length of Cars or other movies, but I do know that for the segment I tested of Cars in VLC, there wasn't any issues, but that's as much as I tested it.