@jahutchi thank you!
While we would still like a real solution (ideally upstream kernel devs acknowledging the issue introduced and finding a solution), identifying the commit that caused the regression makes this far more likely.
And it allows people affected to run a build much closer to the official one - running the 4.8 kernel was never going to be a solution that would work indefinitely.
Good work!
Can you reproduce issue using raspbian? e.g. using aplay or something simpler than kodi?
It may be the same issue as USB DAC dropouts/glitches · Issue #2215 · raspberrypi/linux · GitHub
Having a simple use case that shows the problem would be helpful, especially if it didn't occur with an older kernel (was OE 7.0.1 using 4.4 kernel?)
Posting output of "dmesg" when the drive goes may be helpful.
An insufficient power supply may be to blame.
Do you ever see warning symbols in top/right of screen (temperature/power symbols)?
Can you post output of dmsg after the failure?
Do you still see the failures when PVR is disabled?
the problem is between rev1 and rev2 are a huuuuuuuughe number of commits so its is pretty useless to to recompile if you can't do it by your self (maybe ~50 builds are needed to get close to the problem)
You are vastly over-estimating the number of tests needed in a bisect.
50 builds would allow for identifying a single commit in ~1000000000000000 commits (2^50).
Around 9 builds are actually needed for bisecting the ~343 commits in the "Here is the big USB, and PHY, and extcon, patchsets for 4.9-rc1" merge that is believed to contain the regression.
Bisecting the kernel will be a lot easier on x86 where the upstream kernel can be used untouched.
Bisecting kernel on Pi across the 4.8/4.9 boundary would need serious git skills due to the downstream patches changing.
I wonder if this issue is related:
Basically USB packets were getting dropped on 4.9 kernel and not on 4.4 kernel.
Interesting this bug has just been fixed upstream (this commit).
There was an overflow error in setting timer callbacks which may result in incoming packets not being serviced.
smp I wonder if you could try a recent 4.9 kernel that includes that commit.
Are you able to test a Milhouse nightly build?
That has a change to 3d subs that may help. Would be useful to know.
I don't believe so. If gui is duplicated for 3D then so will subs.
If i disable all 3D Funtions within Kodi the Subtitles are displayed like they should but this sucks very hard because of 2 issues.
That doesn't sound right. Have you produced subtitles with two copies of each subtitle (e.g. duplicated SBS or TAB).
You don't want to do that. When playing a 3D video kodi will automatically duplicate the subtitles in the correct manner
(may be Frame packed, SBS or TAB).
Always try to avoid using the calibration in Kodi.
Ideally when playing 1080p video on a 1080p display the pixels will be unscaled.
Using calibration will resize the video on the way out and then the TV will resize it back again resulting in a lower quality image.
Just disable overscan on your TV/monitor and calibration shouldn't be required resulting in a better quality image and no switching issues.
Check the menu options on TV (it may be called "just scan", "screen fit", "HD size", "full pixel", "unscaled", "dot by dot", "native" or "1:1").
metaron - any further news on tracking down the kernel commit responsible?
If those MKV files contain 10bit versions of the H264 format, your Raspberry Pi is not equipped to handle those.
I believe @leposcaille reported the same file played from USB so it won't be that.
If a file plays from USB and not from network then it is most likely file permissions of the server that contains the files.
Information on the protocol used (e.g. smb/nfs) and what the OS the server is running would be useful.
As would the log file.
sdcard has a big effect on gui performance. You want high random access 4K read/writes.
Samsung EVO/EVO+ are good choices.
You can always switch to 720p in system/video settings.
That will prove if the issue is purely resolution dependent, or if something else in the update has caused it.
Do you have "adjust refresh rate to match video" enabled in system/video settings?
That is recommended for smoothest video.
I notice you are using omxplayer. That isn't the default (or recommended) on PI2/Pi3.
Do you have the problem with omxplayer disabled (leaving MMAL enabled)?
I see you have omxplayer enabled, which isn't the default (or recommended) on Pi2/Pi3.
Do you still have the issue if you disable this?
