[lharms]

I am seeing an issue with a particular bluray iso (Ratatouille). I first saw this issue when I upgraded to v15 from 14.2. I have continued to see this all the way thru 16 (building my own).

The issue I am seeing is about 1 min in I get a stutter with both audio and video.

I 'git bisected' the issue down to 2 commits that seem to be causing most of it.

The first one seems to causes the audio to desync. The video keeps playing but the audio drops out.

The second looks like it is causing a reset which causes a video skip of about 5-10 seconds.

First bisection
96872c33ae6f1385d20be845926d065a1b39913c is the first bad commit
commit 96872c33ae6f1385d20be845926d065a1b39913c
Author: Rainer Hochecker <fernetmenta@online.de>
Date: Sun Dec 28 18:32:07 2014 +0100

dvdplayer: simplify calculation of playing pts for audio

:040000 040000 3502dbfe1c330abe05b221fb639b2bafaa2f7394 66c14412952a3c692ca7155200ff0c8bc855a8cc M xbmc

Second bisection
c852d662f5034e746396f3855b583891b659909a is the first bad commit
commit c852d662f5034e746396f3855b583891b659909a
Author: Rainer Hochecker <fernetmenta@online.de>
Date: Tue Apr 7 19:22:28 2015 +0200

dvdplayer: trigger resync of players after audio stream stalled

:040000 040000 a5e4518542303991a70cea930d43bbd3ba48b6d4 8887ac7464c97172d3c3f5278806c8b52e30c8e4 M xbmc

I have also a copy of the kodi.log file from a run of master from today http://pastebin.com/ENBVvAi1

You can see at 21:58:23 T:17448 the stall out. I stopped the video a couple of seconds after and then closed the program.

On a side note I think I have seen enough of the first couple of mins of Ratatouille

[lharms]

Anyone else seeing the same sort of stutter on other blurays?

[Redwingsfansfc]

http://forum.kodi.tv/showthread.php?tid=231034

Check that out

[brazen1]

If you look in your bdmv folder you will see all the .m2ts files.
Do you notice the skips occur at timeframes when a m2ts file transitions to the next m2ts file?

Note the scene (frame) where the skip happens during Kodi playback.
Play one of the .m2ts files using a media player in windows. Play only a couple seconds of the beginning and end of the .m2ts.
You are looking for the scene you noted when it skipped.
You will probably notice the skip happens exactly at the end of one of the .m2ts and the beginning of another.
You will have to review the 1st and last seconds of each m2ts until you find the correct ones. Sort by size and selecting largest speeds up process.
I've only noticed this on some (not all) titles.

This only happens using Kodi upgrades above 14.2 and only with the Kodi player. External players and builds prior to 15 do not have this problem.

http://forum.kodi.tv/showthread.php?tid=229511

http://forum.kodi.tv/showthread.php?tid=239396

[lharms]

@Redwingsfansfc I set the system back to fresh install when doing this. So I dont think it is that. I have seen that with a few blurays where the file that runs the br is 'fake' and will jump around and skip. I have seen that on Dredd and 'now you see me' But that could be a different issue

@brazen1 good theory. I will give it a try. I may just re-rip a couple of different ones to a flat structure and see. It actually fits sort of what I am thinking the code is doing. I suspect the error has always been there. The first commit looks like it is more correct. However, it is more strict. The second commit causes the garbled screen because it detects audio desync that is happening and says 'just reset the whole stack both audio and video'. So you see and hear garbage. That seems like the right thing to do too but may be too much? I pulled out the reset code and it then acts like 15.0. Where it will desync but the video keeps going but the audio never catches up and the video seems to speed up. I dont understand it enough to fix it The only other title I have found that does this is watchmen. But that is from spot checking. I will try your way and see if I can find another one.

[lharms]

@brazen1 I think I am seeing the same bug as you (is there a trac on it?). I dug around to try a few others of my collection that do this. Not many. The ones where they try to mess with the table of contents were a good place to start. As they break the movie into a few pieces then play with the TOC for players to try to guess which of the hundred playlists is the 'real' one. So on Dredd I see the skip (around 40 mins in) but it is not as bad as on Ratatouille it actually happens to fit into the movie but is slightly noticeable. I also tried 'Up' another Pixar movie, I suspect cars2 would do it as well. With pixar bluray they like to use seamless branching to match up words on newspapers and books to match the language you pick. So if you pick french it will show french on all of the books and signs (kinda cool actually).

A random guess about the software is getting confused about the time where in the movie it is when switching the m2ts files around. So it thinks there is a stall and then gets out of sync which then causes a glitch because it decides to reset too. It could also be like you are thinking where it is seeking around thru the mpls files? You can see the lag when starting up a bluray if there are a lot of them and it is just taking to long to switch which would actually be a stall. Need to study it more.

[lharms]

Just some notes for my future self or anyone else interested

Another relevant thread http://forum.kodi.tv/showthread.php?tid=244856

My current theory it is grabbing a packet then thinks it is wildly in the past.
I added a debug statement to track it a bit.
Normal prints several thousand times over
Debug Print: CDVDPlayer::CheckContinuity:mydebug - wrapback :1, prev:66562666.666667, curr:66594666.666667, diff:32000.000000
About the time when a m2ts change happens
Debug Print: CDVDPlayer::CheckContinuity - wrapback :1, prev:66690666.666667, curr:11650666.666667, diff:-55040000.000000
The diff is rather large. Also the last 5 times I tried it the diff was always exactly the same.

Next up figure out how it decides where current.dts is filled in from. Suspect the real bug is near that code (bluray dll callback?). An assumption I am currently making is the dts is something relative to the start of the file?

Just before the diff debug output I get this in the debug output window. Suspect the bluray lib is trying to tell me something.
Debug Print: CDVDInputStreamBluray::Logger - register.c:420: bd_psr_write(): PSR7 (PLAYITEM) 0x0 -> 0x1
Debug Print: CDVDInputStreamBluray::Logger - register.c:418: bd_psr_write(8, 524280): no change in value
Debug Print: CDVDInputStreamBluray::Logger - bluray.c:301: Stream with preferred language not found
Debug Print: CDVDInputStreamBluray::Logger - bluray.c:322: Selected stream 0 (language eng)
Debug Print: CDVDInputStreamBluray::Logger - register.c:418: bd_psr_write(1, 1): no change in value
Debug Print: CDVDInputStreamBluray::Logger - bluray.c:301: Stream with preferred language not found
Debug Print: CDVDInputStreamBluray::Logger - bluray.c:313: Subtitles disabled (audio is in the same language)
Debug Print: CDVDInputStreamBluray::Logger - bluray.c:322: Selected stream 0 (language eng)
Debug Print: CDVDInputStreamBluray::Logger - register.c:418: bd_psr_write(2, 268369921): no change in value

[lharms]

hmm think I managed to bandaid it a bit.

In the method CDVDPlayer::CheckContinuity I added correction = pPacket->dts - current.dts; to the path that was detecting negative movement and it seemed to help. No more skipping. Anyone know if that path should be empty for any reason?

The other two paths seem to be detecting movement of the dts and changing it accordingly. This path did not do anything with that information other than log it.

What I did does not 'seem' right. But it works. Seems like it should be smarter somehow about how far away it is? I think what I did probably neuters the whole 'reset' logic?

[Martijn]

@FernetMenta or @Ace ping

[lharms]

@Martijn thank you! Could use a bit of help Do you happen to know if there is a bug on this already? I could not really tell from trac. I am kinda surprised it is not happening on other platforms.

[Chorca]

I've been noticing the exact same issue.

It appears to be related to when the player jumps to the next m2ts file, as that is when the problem occurs. The logfile will show it beginning to buffer the next file, and as soon as the player reaches that spot in the buffer, errors are dumped to the logfile and the video fast-forwards, then seems to jump before re-settling.

I've had this problem since 15, 14.x did not exhibit the issue. Currently running OpenElec 5.95.5, Kodi 15.1 Git:f4dda26

It affects many blu-ray movies that I play, either from ISO or from a folder on the drive. MKVs are not affected, which makes sense as this issue seems to come about only when seamlessly switching files in the blu-ray structure.

Here's a couple pastes from the relevant part of the logfile where the issue happens, this example is from Die Another Day:

http://pastebin.com/tmhYa95f
http://pastebin.com/yeP4qRcr

[lharms]

@Chorca ok yeah that is the same thing. I suspected it would happen on other platforms too and you are seeing it on a linux build.

You can see the 'gap' in the log with these two lines. That is the diff entry.
22:37:31 T:139953187059456 DEBUG: CDVDPlayer::CheckContinuity - wrapback :2, prev:111291866.666667, curr:11608955.555556, diff:-99682911.111111
22:37:31 T:139953187059456 DEBUG: CDVDPlayer::CheckContinuity - wrapback :1, prev:111373333.333333, curr:11650666.666667, diff:-99722666.666667

I also happen to have that same bluray it is shattered into many m2ts files. So the skipping would be rather bad on that one. I poked around at a few of the other bond movies they do not seem to do it as much. But I only looked at 3 of the 20 or so. You will tend to see it on movies where there are a bunch of m2ts files. Ones where there is a large block and you see a skip I think is a different issue.

The reason you are not seeing it with mkv is because usually they are many times re-encoded into one large stream. So the gap never happens as the stream continues and does not move around.

I traced the gap all the way back to the read method in DVDDemuxFFmpeg.cpp. So I suspect (have not traced any further back) the libbluray is handing the stream packet back this way. I have not quite figured out where time_bas.den and time_base.num come from yet.

[lharms]

@brazen1 or anyone else has a bug been submitted to trac for this?

So far with my testing. My fix seems to cause a slight 'pause' at the beginning of a movie or when a DVD menu loops back on itself. But nothing glitchy like it is now. I also suspect this may fix another quirk people see once and awhile. I have not heard it in the past few weeks. But every once and awhile there is a pop you can hear at a chapter boundary on DVDs. Basically the system is getting a bit confused and goes backwards in time a few ms at least that is what I am seeing in the logs people are posting. I suspect there is something in the ffmpeg layer causing times to get a bit confused. The bluray one we have is just a serious version of it.

Also the other bug people are seeing I think comes down to the fact that KODI is not caching ISO files *at all* no matter what the settings are. I have been picking at that one a bit. But there is no clear way to say this file should or should not be cached. At least I am not seeing it (got to be in there somewhere ). There is some code that seems to disable caching but that is on a different path and seems to do with physical discs. I hacked URIUtils:IsInternetStream to look for ISO files but that does not seem like the correct place for this. There is a chunk of code in CFile:Open which seems to be trying to force caching. But that seems wrong too as it is not respecting the settings?

[brazen1]

I haven't submitted anything.
Last I read, there was a reach out to a Windows dev to take a look.
I also read nothing would be attempted until 16 is released and perhaps once 17 starts development.
I'm just using an external player as a work around but a whole slew of other folks are dependent on the internal so I'm confident someone will address it at some point.
If you want to submit, providing it hasn't been already, might ensure it at least gets looked at.
Thanks for continuing your pursuit with this.....

[lharms]

There is now a pull request to fix the original issue in this thread. https://github.com/xbmc/xbmc/pull/8426