[scronkey]

@scronkey could you try to compile Kodi yourself? https://github.com/xbmc/xbmc/blob/master....Ubuntu.md

 I'll have a go at compiling myself and report back.

[scronkey]

@scronkey could you try to compile Kodi yourself? https://github.com/xbmc/xbmc/blob/master....Ubuntu.md

 OK. Now compiled locally from a fresh git pull (18.2-RC1 Git:20190311-ac9206b2c5) - same symptoms which is not a surprise.

Debug log:  https://paste.kodi.tv/izirigidop.kodi
bt+continue+bt: https://paste.kodi.tv/zitacihoba

Suggested next steps, now that I have the source compiled locally?

• Compile with debug symbols (what is required to enable, configure options I assume?)
  
• Investigate yasij's train of thought on the potential wraparound bug - suggesting a simple patch to try?
  

Yours in the struggle.

[FernetMenta]

Now that you are able to compile, I can provide a little patch that logs out required infos. Apply the patch, then rebuild and rerun. You know how to apply a patch, don't you?
In most cases it is: patch -p1 < mypatch.patch

[scronkey]

Now that you are able to compile, I can provide a little patch that logs out required infos. Apply the patch, then rebuild and rerun. You know how to apply a patch, don't you?
In most cases it is: patch -p1 < mypatch.patch

Great, thanks FernetMenta

It’s been a while but I’m sure I’ll figure out applying the patch.

[FernetMenta]

@scronkey please apply this patch and post a new log
 
http://paste.ubuntu.com/p/YXccfcfgfS/

[scronkey]

@scronkey please apply this patch and post a new log

 @FernetMenta patch applied, run and debug log captured.

Debug log: https://paste.kodi.tv/ewajikuroj.kodi

Note that after 5-10 seconds of kodi freezing, the log file is well over a gigabyte. I've truncated the file to highlight the variable ret is the only one changing, and does appear to be wrapping with no break in the while (ret > interval) condition even though this should return false and break the loop (if indeed that is where the "hang" is).

[FernetMenta]

Could you please change the format specifiers of the patch from %ld to %llu.
Sorry, my mistake.

[scronkey]

yasij - can I request a build with debug symbols? Not sure where I can access the checkboxes for ppa

Not for the team-xbmc PPAs. The checkboxes are only available for PPA administrators. You can create your own PPA, and turn those flags on for it. Set the team-xbmc PPA as a dependency. Then copy the package to your PPA from the web interface and tell it to rebuild.

In any case, there is definitely a wraparound bug on 32-bit systems in the code here. C/C++ will not promote the type when all of the intermediates in the r-value are 32-bit. It's also being added in a way which would push overflow by multiplying and storing to get nanoseconds, and then dividing by 1000 to get microseconds. If you can build yourself, the patch to fix the numerics is pretty simple.      

Sounds reasonable on first glance but does not explain why 18.0 did work and 18.1 doesn't. The code you blame did not change. The only change in this area between 18.0 and 18.1 is:
https://github.com/xbmc/xbmc/commit/79d9...cd6c98dcc3   

I rolled back the changes above from 18.1 to 18.0 and playback is now restored.

Further isolated to the single line change in xbmc/windowing/X11/GLContextEGL.cpp

from
interval = (m_sync.cont >= 5) ? m_sync.interval : m_sync.ust2 - m_sync.ust1; 
back to
interval = (m_sync.cont > 5) ? m_sync.interval : m_sync.ust2 - m_sync.ust1;

Restores playback.   

As cont in my logs is 5, it's clear the changed test above returns a different result impacting my system.

What is the intent for the changed test condition above, as it would appear to be the cause of the freeze?

[FernetMenta]

I know that this change is the reason but I wasn't sure how it triggered the new behaviour. Using m_sync.interval is desired, 16.6ms instead of m_sync.ust2 - m_sync.ust1. The latter must result being zero and early exit of the function without hitting the issue already there in 18.0.

fix:
now = static_cast<uint64_t>(nowTs.tv_sec) * 1000000000 + nowTs.tv_nsec;

[fritsch]

Thanks much! Yes, that makes sense and was very hard to find, e.g. easy to overlook - I sent a PR for that: https://github.com/xbmc/xbmc/pull/15743

[yasij]

You probably want to pull the division by 1000 up into the original calculation of now to about losing another 10 bits of precision from scaling up and then back down.

[fritsch]

I sent a PR to extend kodi's uptime by this 2^10 bits.

[Vawenus]

Anyone know how long it takes to add this kind of PR to the official ppa?

Just wondering if I should just wait a few days or start using the nighly build ppa.

[fritsch]

I pushed it. Will be built tonight, you have it tomorrow.

[Vawenus]

I pushed it. Will be built tonight, you have it tomorrow.

*hug*