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?
You can customise the filename tags used for 3d: Advancedsettings.xml#video
See:
<stereoscopicregex3d>[-. _]3d[-. _]</stereoscopicregex3d>
<stereoscopicregexsbs>[-. _]h?sbs[-. _]</stereoscopicregexsbs>
<stereoscopicregextab>[-. _]h?tab[-. _]</stereoscopicregextab>Is there a log somewhere I might be able to resurrect? (git bisect log obviously only shows the most recent bisect)
I think only the current git bisect log is saved.
You can run "git bisect log" to see what commits you reported as good/bad.
You might want to double check if you reported bad to 54a2ec67f1db62a763f57b7f8f2e82874f5f358b or an older commit.
54a2ec67f1db62a763f57b7f8f2e82874f5f358b is not going to be the commit that caused the problem (it only affects the
SOC_OMAP5 platform which isn't the Pi or PC).
If you ever report the wrong answer to git bisect good/bad then it will identify the wrong commit.
The occasional quick compiles are expected. Especially after a few iterations the number of commits jumped will be small and if these don't affect header files the amount of rebuilding may be small.
How are you naming the file?
You should add tags like: 3D#Video_filenames_flags
Only shows 31 individual commits. Might it be because I cloned with --depth=1 then ran --deepen=100?
Yes, I don't think a shallow clone will have the required history.
I think you should clone the complete repo for this to work.
metaron good work!
That provides evidence that it is an upstream linux kernel bug that affects multiple platforms.
Reporting upstream may be useful: Reporting bugs for the Linux kernel
You have identified a merge commit that seems responsible which is helpful, but it is a huge merge of 343 commits.
You can view these commits with:
git log e6445f52d9c8b0e6557a45fa7d0e8e088d430a8c^..e6445f52d9c8b0e6557a45fa7d0e8e088d430a8cI think you can narrow it down to a single commit with:
dc4@dc4-XPS13-9333:~/projects/linux$ git bisect start
dc4@dc4-XPS13-9333:~/projects/linux$ git bisect good e6dce825fba05f447bd22c865e27233182ab3d79
dc4@dc4-XPS13-9333:~/projects/linux$ git bisect bad e6445f52d9c8b0e6557a45fa7d0e8e088d430a8c
Bisecting: 184 revisions left to test after this (roughly 8 steps)Build this kernel and check if it is good/bad. Then run either "git bisect good" or "git bisect bad" and it will provide you with a new commit to build from. After 8 builds you should have the answer what the specific commit was.
I am fairly certain I just did apt-get update && apt-get upgrade (or maybe: apt-get dist-upgrade)
That gets you the 4.9 kernel. The next raspbian sdcard image will use this kernel.
(rpi-update currently gets a slightly newer 4.9 kernel and is the easiest way to downgrade to a previous kernel).
OK, so now I'm really confused. I've blown a jesse-lite image to a spare SD card, logged in and run:
sudo apt-get install --reinstall raspberrypi-bootloader raspberrypi-kernel
but ls /lib/modules shows me 4.4.50+ 4.4.50-v7+ (which isn't the 4.9.24 version maroi says he has on his box)
Typing sudo apt-get dist-upgrade tells me 0 upgraded, 0 newly installed, o to remove and 0 not upgraded. - so that doesn't work either.
Try running "apt-get update" beforehand to get the indexes up to date.
Edit: Maybe kernel: Bump to 4.3.24 · Hexxeh/rpi-firmware@bbd611a · GitHub is it?
(It's a bit late now - will try again another day!)
Yes - 4.3.24 was a typo (for 4.9.24) but there is no safe way of fixing a git commit message.
The RPi2 has worked flawlessly for about 2 years, until it suddenly began to produce Continuity Counter Errors.
If you want to narrow this down, can you back up your sdcard and try reverting the kernel.
sudo rpi-update 7a47836821b92efa569500b3382b1812082e42d3will get you the last 4.8 kernel (4.8.13) which from my understanding should be good.
sudo rpi-update bcc6146e102d85b1aa214855ad7aae278d3bd269will get you the first 4.9 kernel (4.9.0) which should have the problems.
It would be useful if you (or others) can prove or disprove this is correct.
Anyone know how to track down #993?
sudo rpi-update e253b1dcaa3aa774444f6c0224f04237f60ba2d1