•   
  • 1
  • 77
  • 78
  • 79(current)
  • 80
  • 81
  • 218
  •   
  Thread Closed
v17 LibreELEC Testbuilds for RaspberryPi (Kodi 17.0)
(2016-07-03, 14:19)popcornmix Wrote:
(2016-07-03, 14:15)loggio Wrote: Ahh... Well there you go. So should I set PLL to 8 or lower?

8? I think the options are Off/Low/Medium/High/Max.
You should set it to the highest value that your TV/receiver is happy with. Too high and you may get audio/video dropouts. If you do lower it a notch and try again.

Yes sorry about that, you replied before I edited my post haha don't know what happened there. Thanks for that!
(2016-07-03, 14:03)MikeKL Wrote: Enabled "sync playback to display" via GUI Player Settings -> Videos Then ran 10 minute soak test with same BBC Catch-up item at same stream level of 3.1Mbps and lo and behold
  • start skip = 6, after 10 mins skip = 6 CoolCoolCool

In general "sync playback to display" is recommended to be enabled if you want perfect video.
It should be disabled (or you should use "PLL adjustment" on Pi) if you want perfect audio.

I suspect that these streams have an issue with audio/video timestamps.
Suppose video is 50Hz and audio is 48kHz, but due to separate processing of the audio and video streams, when they are combined,
you actually find in each second there are 50 video frames and 47952 audio samples.

"Sync playback to display" disabled means the audio drives the clock, but that is 0.1% slower than it should be (compared to video).
So, every 1000 video frames (20 seconds), there is an extra one which gets skipped.

With "sync playback to display" enabled, that means the video drives the clock and the audio is resampled (or PLL adjusted) to fit in
and you get no video skips.
Thanks fot that wonderfull builds.

My Problem with some missing DVD menue are solved.

If i set in "Player settings" under Video: play nexr automatically
and under Discs: "Attempt to skip introduction before DVD menue"

all my bitchy DVD are now playable.

Also Thanks for this tip ;-)
(2016-07-03, 14:34)popcornmix Wrote:
(2016-07-03, 14:03)MikeKL Wrote: Enabled "sync playback to display" via GUI Player Settings -> Videos Then ran 10 minute soak test with same BBC Catch-up item at same stream level of 3.1Mbps and lo and behold
  • start skip = 6, after 10 mins skip = 6 CoolCoolCool
In general "sync playback to display" is recommended to be enabled if you want perfect video.
It should be disabled (or you should use "PLL adjustment" on Pi) if you want perfect audio.
Thanks for help and explanation, so based on your overall experience would you suggest enabling option "sync playback to display" in majority of basic user/usage cases?

Note "sync playback to display" Disabled is default setting at standard+ user level, (not visible at basic) is it planned to be enabled as the future default?
(Note I have Audio set to 2 channels and passthrough enabled in System Audio settings to pass digital audio to DTS capable receiver)

Not first kodi user to confess to being rather confused with complexity of interaction between System and Player Video/Audio settings (Basic, Standard, Advanced and Expert) and unintended impact that the options may have on playback of material from various sources BlushBlush
rPi3B+, SanDisk Ultra 8Gb SD, Milhouse kernel_5.x LE ​Testbuild (Kodi 19 Matrix) -> Onkyo TX-SR608 AV Receiver -> Philips 42" LCD TV
KVIM2 Pro, SanDisk Ultra 8Gb SD, kernel_5.x LE Testbuild (Kodi 19 Matrix) -> LG 27UD69-W 4K Monitor -> AudioEngine A2+ Speakers
(2016-07-03, 18:21)MikeKL Wrote: Thanks for help and explanation, so based on your overall experience would you suggest enabling option "sync playback to display" in majority of basic user/usage cases?

It's what I use. If smooth video is important then enable that.
Is it good for everyone? That is harder to say. Many users don't even see frame skips.
But they might notice the audio warble (or suffer from audio/video dropouts from the PLL adjustment).

By default we don't enable "adjust display refresh to match video", which obviously lowers video quality.
But for users who don't see the stutter, they probably prefer not to have the ~2 seconds of blank screen as their TV locks on to new frequency.

Kodi tends to keep the default video/audio settings to be simple and trouble free, rather than maximising quality.
You are expected to enable "adjust display refresh", "sync playback to display", "mutichannel audio", "passthrough" etc if they are important to you.
(2016-07-03, 20:32)popcornmix Wrote: You are expected to enable "adjust display refresh", "sync playback to display", "mutichannel audio", "passthrough" etc if they are important to you.
Thanks for further explanation, checked my settings and enabled "adjust display refresh" all other settings were already enabled. Wink
Thanks very much for helping me understand/resolve my issue with BBC Catch-up streams; Live and catch-up TV working really really well atm with iplayerwww and itv add-ons CoolCoolCool
rPi3B+, SanDisk Ultra 8Gb SD, Milhouse kernel_5.x LE ​Testbuild (Kodi 19 Matrix) -> Onkyo TX-SR608 AV Receiver -> Philips 42" LCD TV
KVIM2 Pro, SanDisk Ultra 8Gb SD, kernel_5.x LE Testbuild (Kodi 19 Matrix) -> LG 27UD69-W 4K Monitor -> AudioEngine A2+ Speakers
New LibreELEC.tv Krypton build #0703: RPi / RPi2
(Supercedes previous build)

Code:
# uname -a
Linux rpi512 4.6.3 #1 Sun Jul 3 21:06:27 BST 2016 armv6l GNU/Linux

# vcgencmd version
Jun 27 2016 17:27:06
Copyright (c) 2012 Broadcom
version 1e7b8e2c9a7319f7b22869f1334c66e2cfc99f4a (clean) (release)

# lsb_release
LibreELEC (Milhouse) - Version: devel-20160703210521-#0703-g9fee5e3 [Build #0703]

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

# Kernel device tree status: Enabled

Based on tip of LibreELEC.tv master (9fee5e3f, changelog) and tip of XBMC master (34097875, changelog) with the following modifications: Build Highlights:
  1. ffmpeg 3.1.1
Build Details:
  1. LibreELEC.tv:
    • mono: rework (PR:508, 2 commits, 2 files changed)
    • hyperion: add xrandr dependency for X11 (Generic project) (PR:510, 1 commit, 1 file changed)
  2. XBMC:
    • omxvideo: Remove call to AutoInterlaceMethod. Treat auto as advanced (PR:10053, 1 commit, 2 files changed)
    • mmal_codec: Use EOS through codec to determine drain is complete (PR:10051, 1 commit, 2 files changed)
    • VideoPlayer: - fixed c&p - return the correct video processing info w… (PR:10065, 1 commit, 1 file changed)
  3. newclock5:
    • Commits no longer in build:
      • omxvideo: Remove call to AutoInterlaceMethod. Treat auto as advanced (a05eac75)
      • mmal_codec: Use EOS through codec to determine drain is complete (3676c884)
  4. Additional commits/pull requests/changes not yet merged upstream:
    • Added: [env] patch: ffmpeg: bump 3.1.1
    • Added: [pkg] PR:10066: [PeripheralCecAdapter] Fix: Slovak language code (slo) considered as Slovenian (slv)
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.
(2016-07-03, 14:34)popcornmix Wrote:
(2016-07-03, 14:03)MikeKL Wrote: Enabled "sync playback to display" via GUI Player Settings -> Videos Then ran 10 minute soak test with same BBC Catch-up item at same stream level of 3.1Mbps and lo and behold
  • start skip = 6, after 10 mins skip = 6 CoolCoolCool

In general "sync playback to display" is recommended to be enabled if you want perfect video.
It should be disabled (or you should use "PLL adjustment" on Pi) if you want perfect audio.

I suspect that these streams have an issue with audio/video timestamps.
Suppose video is 50Hz and audio is 48kHz, but due to separate processing of the audio and video streams, when they are combined,
you actually find in each second there are 50 video frames and 47952 audio samples.

"Sync playback to display" disabled means the audio drives the clock, but that is 0.1% slower than it should be (compared to video).
So, every 1000 video frames (20 seconds), there is an extra one which gets skipped.

With "sync playback to display" enabled, that means the video drives the clock and the audio is resampled (or PLL adjusted) to fit in
and you get no video skips.
Sorry to hijack but this is why I will never understand this setting. You told me that "sync playback to display" is not needed on the Pi because it can adjust the HDMI clock. Why would you recommend the setting for perfect video then?
(2016-07-03, 23:28)meccs Wrote: Sorry to hijack but this is why I will never understand this setting. You told me that "sync playback to display" is not needed on the Pi because it can adjust the HDMI clock. Why would you recommend the setting for perfect video then?

I don't believe I've ever said "sync playback to display" is not useful.
I may have said that some platforms must use "sync playback to display" to support 23.97Hz (if they only support 24Hz) and the Pi doesn't have that limitation.

For a correctly encoded file, where the stream is not live shouldn't require "sync playback to display", but if either of those aren't true then it is useful.

It is also may be useful when using an external (usb/i2s) audio device which may be clocked asynchronously to the display:
well yesterday i watched football and had sync to display turned on for a test. I turned it off again when i first heared the reporter yell at a goal while the ball wasn't visually even near the goal Wink - hard to notice when audio goes async on something like a football game Big Grin
AppleTV4/iPhone/iPod/iPad: HowTo find debug logs and everything else which the devs like so much: click here
HowTo setup NFS for Kodi: NFS (wiki)
HowTo configure avahi (zeroconf): Avahi_Zeroconf (wiki)
READ THE IOS FAQ!: iOS FAQ (wiki)
Hi guys,

I'm wondering if there has been a change that's causing images to take a lot longer to render in these nightlies?

I'll use the Titan skin as reference as it's my skin of choice, however this happens on all skins i've noticed.

There's a lot of skins that utilize the "color picker" in the Skin Helper Service to allow the user to customize the colors of their skin.
In the Jarvis stable release of Libreelec, the "Color Grid" that one is presented with when attempting to change colors loads relatively quickly... While slower on the RPi than other systems it still managed fairly well.

In the latest Libreelec nightlies and alpha release, loading the same color grid can take quite some time, sometimes up to around 50 seconds... Which can be pretty unbearable when trying to configure the colors for various skin items.

Now, before anyone suggests that the Skin Helper Service is the problem (which it could very well be), i have my doubts as i've noticed that loading images such as addon icons while browsing a repository can be painfully slow also.

Also the fact that i've installed a fresh copy of the latest Generic Libreelec alpha on my x86 theatre room HTPC which is now suffering from the same symptoms, is leading me to believe there may be something slowing down the rendering of images in either kodi/libreelec.

I haven't supplied a log, but i don't think i really need to as this is certainly not an isolated problem...
Anyone with a RPi and 10 minutes up their sleeve can try this and see for themselves.

Hoping someone can shed some light on this one.

Cheers,
Loggio.
(2016-07-04, 08:04)loggio Wrote: Also the fact that i've installed a fresh copy of the latest Generic Libreelec alpha on my x86 theatre room HTPC which is now suffering from the same symptoms, is leading me to believe there may be something slowing down the rendering of images in either kodi/libreelec.

If the problem affects multiple platforms you will get a better response posting a new thread in OS independent forum, or creating a trac ticket, where the right devs may see it.
This isn't something I know anything about, so it is not something I will be able to fix.
(2016-07-04, 07:17)Memphiz Wrote: well yesterday i watched football and had sync to display turned on for a test. I turned it off again when i first heared the reporter yell at a goal while the ball wasn't visually even near the goal Wink - hard to notice when audio goes async on something like a football game Big Grin

Do you have "PLL adjust" enabled? If that is enabled and isn't set high enough for the adjustment required it can provoke out-of-sync.
If you see it again check if disabling PLL adjust (so resampling is used) avoids the issue. If it does check also if setting "PLL adjust" to max avoids the issue.

Although if this is a live iplayer stream then they do sometimes have out of sync audio issues.
I've seen out-of-sync audio that also was occurring with the iPlayer app on iPad.
sorry to butt in.Smile I assume the switch tv refresh rate to video should be on too then, if for example the football match was in 50hz and the display 60hz, and only sync to display was on. wouldn't things go badly out of sync then?
(2016-07-04, 14:12)tuxen Wrote: sorry to butt in.Smile I assume the switch tv refresh rate should be on too then, if for example the football match was in 50hz and the display 60hz, and only sync to display was on. wouldn't things go badly out of sync then?

If you care about video quality more than the few seconds of HDMI resync time when switching then yes, "adjust display refresh rate to match video" should be enabled.
  •   
  • 1
  • 77
  • 78
  • 79(current)
  • 80
  • 81
  • 218
  •   
  Thread Closed
 
Thread Rating:
  • 19 Vote(s) - 4.63 Average



Logout Mark Read Team Forum Stats Members Help
LibreELEC Testbuilds for RaspberryPi (Kodi 17.0)4.6319