(2015-08-31, 20:52)polo_joe Wrote:(2015-08-31, 20:39)popcornmix Wrote: If either of these fail, then it would suggest a problem with the 3D hardware on the Pi (which is used by both of these tests).
screensaver and video are working perfectly fine.
config.txt http://sprunge.us/FRBR
(2015-09-02, 04:43)zaphod24 Wrote: Using only mmal on an rpi2 with a Mythtv backend. My tv streams are 1080i60 mpeg2 and play back great. Obvious question, have you licensed hardware mpeg2?Yeah, I don't think it would use MMAL at all if I hadn't and would default to ffmpeg. Only trying to use SD Freeview channels here (tvheadend back-end and front-end on RPi), so if it can cope with 1080i60 it should be a breeze but the only way I can get rid of the the stutter is to use OMX.
(2015-09-02, 09:58)Forage Wrote: Is there a way to safely trigger an update from an earlier db again?
Is deleting files like MyVideos95.db and MyVideos94.db sufficient?
(2015-09-02, 10:08)polo_joe Wrote: @popcornmix
Anything else I could try?
(2015-09-02, 10:08)polo_joe Wrote: Anything else I could try?
(2015-09-02, 13:46)MarkT Wrote:(2015-09-02, 10:08)polo_joe Wrote: Anything else I could try?
Are you using a USB device for DVB-C/DVB-S? If so, try the stick on a normal PC using DVBViewer or similar. I also have these decoding dropouts on DVB-C plus total freeze after 3-4 hours of watching a channel. No problem on PC, might as well be a bug in the USB-driver.
(2015-09-02, 14:11)polo_joe Wrote: But why should be the tv card the issue, mmal half works with all livetv channels.
(2015-08-31, 18:42)popcornmix Wrote:(2015-08-31, 17:44)polo_joe Wrote: I tried both settings together and each alone.
No change.
mmal half works.
mmal advanced at HD triggers a boost to 300MHz (of v3d clock).
The half version doesn't need the boost, nor does automatic (which uses bob for hd).
So my guess is that 300MHz v3d is not working on your Pi.
However with default config.txt settings (i.e. no v3d_freq or gpu_freq specified) and with disable_auto_turbo=1 you should still be running at 250MHz.
When running with default config.txt settings + disable_auto_turbo=1 and when getting the artefacts can you run:
If it is zero then run a few times until you see a non-zero value and report what it is.Code:vcgencmd measure_clock v3d
# uname -a
Linux rpi512 4.1.6 #1 Wed Sep 2 23:18:26 BST 2015 armv6l GNU/Linux
# vcgencmd version
Sep 2 2015 15:06:26
Copyright (c) 2012 Broadcom
version 65d10bdd7b509391aaf143b30b66246461909f94 (clean) (release)
# lsb_release
OpenELEC (Milhouse) - Version: devel-20150902231737-#0902-g4aff2c2 [Build #0902]
# vcdbg log msg 2>&1 | grep DTOK
001713.596: Kernel trailer DTOK property says yes
# Kernel device tree status: Enabled
(2015-09-03, 01:14)Milhouse Wrote: [*]Include RPi 2 overlock mode preset (PR:4298, 1 commit, 1 file changed)
(2015-09-01, 23:07)popcornmix Wrote:(2015-08-31, 21:02)metaron Wrote: I'm having problems seeking / with 4:3 to 16:9 transitions on RPi with the latest build (New OpenELEC Jarvis build #0830: RPi) using both the OMXPlayer and MMAL acceleration options. This seems to affect channels when they use different formats/bitrates for ads and shows.
Thanks for detailed bug report. I can see the cause of the MMAL issue. If you disable deinterlace it should work correctly again (would be useful if you can confirm that).
Basically the video_decode component can generate notification messages. One of these is aspect ratio has changed.
However when deinterlace is enabled we tunnel video_decode to image_fx (which does the deinterlace) and that's where the notification goes, and kodi doesn't see it.
I suspect I'll need to plumb in similar notifications from image_fx to fix this problem.
