• 1
  • 126
  • 127
  • 128(current)
  • 129
  • 130
  • 168
OpenELEC Testbuilds for RaspberryPi (Kodi 16.0)
I'm using latest oe build and latest tvheadend addon as well. There are still artefacts when watching hd livetv channels.
tvcard is connected directly to pi

any logs required?
(2015-11-03, 19:57)polo_joe Wrote: I'm using latest oe build and latest tvheadend addon as well. There are still artefacts when watching hd livetv channels.
tvcard is connected directly to pi

any logs required?

More details certainly. Do the artefacts occur with official OE 6 build? Does an earlier Milhouse build not have artefacts?
Do you get artefacts in recordings as well as live tv? Does it help if you disable deinterlace? Does it help if omxplayer is enabled/disabled?
we were in contact some weeks ago, artefacts only occur when watching servustv channel with mmal advanced, mmal half is working ok.
we tried some hvs priority tweaking, but this doesn't solve the problem though there was an improvement.

didn't try official builds because mmal advanced isn't included right?
(2015-11-03, 18:47)popcornmix Wrote: Is sync playback to display enabled? I have a suspicion there is a leak when that is disabled.
If not, then it would be useful to find out the first build that had this issue?
htop may give a further clue as to the thread that is taking the cpu (I think htop is in the unofficial OE add-ons repo)

PLAYBACK
Adjust display refresh rate Off
Sync playback to display On
-A/V sync method Resample audio (this works best with my setup so far)
Accelerated plaback speed Disabled
Minimise black bars Off
Display 4:3 videos as Normal

ACCELERATION
Allow hardware acceleration OMXPLayer not checked
Allow hardware acceleration MMAL checked
Limit GUI updates during playback 10 fps
Support MVC video (full frame 3D) checked
User Full HD HDMI modes for 3D not checked

VIDEO SETTINGS
Deinterlace video is set to Auto
I also have MMAL - Advanced for the deinterlacer set as default for all "media"
View mode is Normal

All I can tell you is that I believe it started during October near the beginning. I have missed many many nightly builds and only updated on occasion.

I got htop installed now, how do I tell which thread is using the CPU?
Experience: It's what you get when you were expecting something else.
(2015-11-03, 20:51)polo_joe Wrote: didn't try official builds because mmal advanced isn't included right?

MMAL advanced is in OE 6.
@afremont try "bcmstat.sh XDA" to monitor memory leakage - an increasingly negative figure in the "Accum" (accumulated) column would be a strong sign of leakage.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
(2015-11-03, 21:38)popcornmix Wrote:
(2015-11-03, 20:51)polo_joe Wrote: didn't try official builds because mmal advanced isn't included right?

MMAL advanced is in OE 6.

tried now oe 6 +vdr
same problems with artefacts on 1080i50 channels, 720p channels are ok with mmal advanced
so mmal advanced seems to be the problem
(2015-11-03, 22:42)polo_joe Wrote: tried now oe 6 +vdr
same problems with artefacts on 1080i50 channels, 720p channels are ok with mmal advanced
so mmal advanced seems to be the problem

Is the TV backend also running on the Pi?
(2015-11-03, 23:01)popcornmix Wrote:
(2015-11-03, 22:42)polo_joe Wrote: tried now oe 6 +vdr
same problems with artefacts on 1080i50 channels, 720p channels are ok with mmal advanced
so mmal advanced seems to be the problem

Is the TV backend also running on the Pi?

yes on the same machine
(2015-11-03, 23:35)polo_joe Wrote:
(2015-11-03, 23:01)popcornmix Wrote:
(2015-11-03, 22:42)polo_joe Wrote: tried now oe 6 +vdr
same problems with artefacts on 1080i50 channels, 720p channels are ok with mmal advanced
so mmal advanced seems to be the problem

Is the TV backend also running on the Pi?

yes on the same machine
Sounds very much like an issue I'd had previously.
works fine if you move the backend to an x86 box.
My second pi went meltdown last week so I can't test much. (Won't even show any signs of life)
With both on same pi you get artefacts with any interlace mode, mmal or OMX. It just happens much less often with anything other than advanced deinterlace.
I'll try hooking my tuner back up to the pi tomorrow and pointing my odroid to the pi backend.
Pretty sure I'll start seeing artefacts on that as well.
I'd like to try the other way round to eliminate the arm builds of tvh server but the odroid is still on kernel 3.10 and my tuner isn't supported under that.

[Edit]
Pretty sure when popcornmix looked into it before, the blame ended up on the pi usb
https://youtu.be/d33pn9GX6mw

Is this the kind of corruption you are seeing?
exactly
(2015-11-03, 23:48)bagofcrap24 Wrote: Pretty sure when popcornmix looked into it before, the blame ended up on the pi usb

The Advanced deinterlace at 1080i60 is expensive. It generates a lot of sdram traffic.
DVB USB dongles generate a lot of data, and depending on the driver, it may need to read prompty to avoid losing data.

The suspicion is that the heavy sdram traffic delays the USB driver occasionally and it loses a packet, causing corruption in the video.

Now there may be ways of working around this. Forcing the deinterlace to spread out its sdram accesses the right amount may solve this.
E.g. currently deinterlace might take 13ms every 16ms. If I were to make the deinterlace pause for 10us every 100us, it would still likely get it's job done,
and hopefully the USB driver won't be held up during the pauses.

Unfortunately it's not something I can test (I have encrypted cable at home, and too weak a terrestrial signal at both work and home).
I may be able to produce a test build that attempts this (perhaps with a config setting to tweak how frequent/long the pauses are).
New OpenELEC Jarvis build #1103: RPi / RPi2
(Supercedes previous build)

Code:
# uname -a
Linux rpi512 4.3.0 #1 Tue Nov 3 21:31:54 GMT 2015 armv6l GNU/Linux

# vcgencmd version
Nov  1 2015 14:49:52
Copyright (c) 2012 Broadcom
version 8f1c8e72174c0415fd479c1c7be66b880fab3d79 (clean) (release)

# lsb_release
OpenELEC (Milhouse) - Version: devel-20151103213102-#1103-ge1c98c8 [Build #1103]

# vcdbg log msg 2>&1 | grep DTOK
001708.837: Kernel trailer DTOK property says yes

# Kernel device tree status: Enabled

Based on tip of OpenELEC master (e1c98c83, changelog) and tip of XBMC master (b010ce97, changelog) with the following modifications: Build Highlights:
  1. Various tweaks
Build Details:
  1. OpenELEC:
    • various pulseaudio fixes (PR:4411, 4 commits, 8 files changed)
    • kodi: disable pvermanager.syncchannelgroups (fixup) (PR:4414, 1 commit, 1 file changed)
    • libinput bump to 1.1.0 (PR:4415, 2 commits, 2 files changed)
    • RTL8192CU: add gcc-5 support patch (4265a123)
    • RTL8812AU: add gcc-5 support patch (e1c98c83)
  2. XBMC:
    • [strings] fix incorrect kai message string on dvd mount and generalise it instead (PR:8335, 1 commit, 1 file changed)
    • paplayer: wait for eof if no crossfading or cue sheet (PR:8332, 1 commit, 1 file changed)
    • udevprovider fixes (PR:8334, 3 commits, 1 file changed)
  3. pvr.hts:
    • class Subscription: Fix member init order. (PR:130, 1 commit, 2 files changed)
  4. newclock5:
    • New commits in this build:
      • ffmpeg: bump version (f1b49d49)
      • vtb: rename after merge (c5dc1d3c)
      • omxplayer: squash: ignore rectangles from right eye (b3b05771)
    • Commits no longer in build:
      • pthreads: use mutex protocol PTHREAD_PRIO_INHERIT (241670de)
  5. Additional commits/pull requests/changes not yet merged upstream:
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
My experience with mmal advanced the artfacts are there when the OSD or the video codec info screen is visible when playing live tv 1080i50 channels.

i have this with deinterlace mode mmal advanced and auto select.

I'm running oscam, tvheadend server and client on the same pi.

I noticed this issue with previous builds i began to use this builds from 1015.

I have a debug.log
  • 1
  • 126
  • 127
  • 128(current)
  • 129
  • 130
  • 168

Logout Mark Read Team Forum Stats Members Help
OpenELEC Testbuilds for RaspberryPi (Kodi 16.0)10