• 1
  • 68
  • 69
  • 70(current)
  • 71
  • 72
  • 495
v18 LibreELEC Testbuilds for RaspberryPi (Kodi 18.0)
Milhouse, any chance of bringing the 3D tag back? It disappeared with version 2 of Estuary skin quite some time ago. I used to get 3D tag beside movie poster out of filename "... .3D.MVC.iso". The tag is gone and unless I play this movie the system will not update any tags from .iso file itself or filename.
(2017-02-21, 03:03)3DBuff Wrote: Milhouse, any chance of bringing the 3D tag back? It disappeared with version 2 of Estuary skin quite some time ago. I used to get 3D tag beside movie poster out of filename "... .3D.MVC.iso". The tag is gone and unless I play this movie the system will not update any tags from .iso file itself or filename.

I would suggest you open an issue here (as I know it's already been mentioned in the Estuary sub-forum feature request/bug threads),
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.
(2017-02-18, 23:49)Milhouse Wrote: Edit: I should add that's on an RPi3 with moderate overclock:
Code:
arm_freq=1300
core_freq=500
gpu_freq=500
over_voltage=4
force_turbo=1

sdram_freq=580
over_voltage_sdram=5
sdram_schmoo=0x02000020

Hi Popcornmix, Milhouse & John,
A question about overclocking for H.265.
Obviously I have made arm_freq and sdram_freq as high as reasonable, without becoming unreliable.
My undersanding is that core_freq influences memory access speed/bandwith, which is useful for H.265, however you are also using the GPU for decoding, so presumably that also needs to be as high as reasonable.
However core_freq and gpu_freq may be set differently, in the ratio 3 to 2 (usually because the gpu won't clock as fast as the core), however I have seen several people, like Milhouse above, using the same frequency for both, whereas I tend to use as high an overclock for core as is reliable (best memory bandwith), then set gpu at 2/3 of that ie 564 & 376 (I realise there are restrictions on the devisors allowed)
So my question is for H.265/HEVC is it better to get the core up as high as possible and so probably have to accept a slower gpu, as I currently do, or to set them both to the same, as high as reliable, as Milhouse example above, or is there basically nothing in it?

Thanks for your time.
Regards, Kevin.
Hi there,

one stupid question.
Would an option similar to audio-passthrough, but with HEVC/H.265-content make sense, so that -in my case- the TV could do the job?

Thanks for answers and THANKS Milhouse/popcornmix!!
(2017-02-21, 14:34)bleep42 Wrote: Obviously I have made arm_freq and sdram_freq as high as reasonable, without becoming unreliable.
My undersanding is that core_freq influences memory access speed/bandwith, which is useful for H.265, however you are also using the GPU for decoding, so presumably that also needs to be as high as reasonable.
However core_freq and gpu_freq may be set differently, in the ratio 3 to 2 (usually because the gpu won't clock as fast as the core), however I have seen several people, like Milhouse above, using the same frequency for both, whereas I tend to use as high an overclock for core as is reliable (best memory bandwith), then set gpu at 2/3 of that ie 564 & 376 (I realise there are restrictions on the devisors allowed)
So my question is for H.265/HEVC is it better to get the core up as high as possible and so probably have to accept a slower gpu, as I currently do, or to set them both to the same, as high as reliable, as Milhouse example above, or is there basically nothing in it?

gpu_freq isn't a specific clock but is a shorthand for setting core_freq, v3d_freq, h264_freq and isp_freq (if otherwise not set).
These days there are separate PLLs for core_freq and the other 3. So core_freq can be set arbitrarily compared to v3d_freq/h264_freq/isp_freq.
v3d_freq/h264_freq/isp_freq need to all be integer divisors of the PLL. The simplest option is to set them all the same.

For HEVC, the sdram, arm, core and v3d are the important clocks (roughly in that order, but they are all significant).

In Milhouse's config.txt the core_freq line is redundant (it defaults to gpu_freq if otherwise unspecified).
But it would work perfectly fine with, say core_freq=513, as core_freq has its own PLL.

However:
gpu_freq=500
v3d_freq=513

wouldn't be satisfied exactly as v3d shares a PLL with h264/isp. I think you would get 513 for all 3 clocks.
Hi, I'm new to fiddling with test builds, I guess this is a suitable place place to report (#0220, #0219, and probably earlier):
I can't delete entries from the Favourites menu (Estuary) because no context menu can be brought up for them.
(2017-02-21, 20:42)LeoD Wrote: I can't delete entries from the Favourites menu (Estuary) because no context menu can be brought up for them.

Known issue with Estuary - there's (currently) no context menu support for Favourites. Instead click on Favourites and a window will open - you should have a context menu for these items.
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.
(2017-02-21, 20:49)Milhouse Wrote: Known issue with Estuary - there's (currently) no context menu support for Favourites. Instead click on Favourites and a window will open - you should have a context menu for these items.
Thanks, man! Apparently I'm new to Estuary, too ...
(2017-02-21, 16:03)popcornmix Wrote: gpu_freq isn't a specific clock but is a shorthand for setting core_freq, v3d_freq, h264_freq and isp_freq (if otherwise not set).
These days there are separate PLLs for core_freq and the other 3. So core_freq can be set arbitrarily compared to v3d_freq/h264_freq/isp_freq.
v3d_freq/h264_freq/isp_freq need to all be integer divisors of the PLL. The simplest option is to set them all the same.

For HEVC, the sdram, arm, core and v3d are the important clocks (roughly in that order, but they are all significant).

In Milhouse's config.txt the core_freq line is redundant (it defaults to gpu_freq if otherwise unspecified).
But it would work perfectly fine with, say core_freq=513, as core_freq has its own PLL.

However:
gpu_freq=500
v3d_freq=513

wouldn't be satisfied exactly as v3d shares a PLL with h264/isp. I think you would get 513 for all 3 clocks.

Thanks Popcornmix, some very useful info there. I didn't know that it was now possible to set core & gpu independently :-( is that true for all pies, so a software change, or only pi2 or pi3? I've tried Google but couldn't find any definite answer.
Thanks again Kevin.
(2017-02-21, 23:45)bleep42 Wrote: Thanks Popcornmix, some very useful info there. I didn't know that it was now possible to set core & gpu independently :-( is that true for all pies, so a software change, or only pi2 or pi3? I've tried

True for all Pi's. Was a firmware change quite some time ago (over a year). We were able to free up the PLL used by analogue audio for the core.
New LibreELEC.tv Leia build #0221: RPi / RPi2
(Supercedes previous build)

Code:
# uname -a
Linux rpi512 4.10.0 #1 Tue Feb 21 21:18:21 GMT 2017 armv6l GNU/Linux

# vcgencmd version
Feb 17 2017 20:41:51
Copyright (c) 2012 Broadcom
version 88b8ca93c6eb22e38531075a6d7e4f25f900af43 (clean) (release)

# lsb_release
LibreELEC (Milhouse) - Version: devel-20170221211717-#0221-ga1d6251 [Build #0221]

# Kodi version
(18.0-ALPHA1 Git:4c792db). Platform: Linux ARM 32-bit

Based on tip of LibreELEC.tv master (a1d6251d, changelog) and tip of XBMC master (755d7db3, changelog) with the following modifications:
  • Includes newclock5 patches
  • Excludes the LibreELEC linux-01-RPi_support patch in favour of sourcing these and possibly more recent patches directly from kernel branch rpi-4.10.y
  • Includes latest bcm2835-driver next (1a717bb3, ahead +659)
  • Includes latest kodi-platform master (c8188d82)
  • Includes latest libcec master (0a97062d, ahead +22)
  • Includes latest libnfs master (2e0a67fc, ahead +49)
  • Includes latest p8-platform master (2d90f986, ahead +9)
  • Includes latest addons: inputstream.adaptive (a347296e), inputstream.rtmp (df64b9b2, +6), peripheral.joystick (69c9e5fe, +1), pvr.argustv (5a36c586), pvr.demo (8243935f), pvr.dvblink (0015079e), pvr.dvbviewer (9fb34b3c), pvr.filmon (315e5034), pvr.hdhomerun (98cb8d40), pvr.hts (1caa390d, +1), pvr.iptvsimple (53d63cce), pvr.mediaportal.tvserver (019c7e99), pvr.mythtv (18fe56e4, +11), pvr.nextpvr (cb1b5415), pvr.njoy (080cd321), pvr.octonet (8549a31c), pvr.pctv (e67e9695), pvr.stalker (a609149c), pvr.vbox (dea8335a), pvr.vdr.vnsi (7033621d), pvr.vuplus (6ff2eb28), pvr.wmc (5f1db43f)
  • Exclude [env] kodi-999.99-PR11662.patch: kodi: merged upstream
  • Include [env] afbd134f: linux: Enable Fair Queue packet scheduling (TEST)
  • Include [env] e533a8be: linux: Default to CONFIG_TCP_CONG_BBR (TEST)
  • Include [env] patch: ffmpeg: add extra RPi lib required when building ffmpeg command line with gpu service hevc patches
  • Include [env] patch: repository.retroplayer.libreelec.addons: add temp repo for testing
  • Include [env] patch: Don't build ADSP addons
  • Include [env] patch: iwlwifi-firmware: update to iwlwifi-firmware-ba301aa
  • Include [env] patch: Bump included addon versions to prevent online updates
  • Include [env] patch: linux: enable in-tree rtl8192cu for RPi/RPi2
  • Include [env] patch: Add kodi binary addons (pvr, adsp, other)
  • Include [env] patch: Add experimental splash video for RPi
  • Include [env] patch: HACK: Disable multiple PVR addons during migration. Always enable inputstream.* and os.*
  • Include [env] PR:1121: linux: update to linux-4.10.0
  • Include [env] PR:1287: virtio-gpu support (qemu/kvm)
  • Include [env] PR:1326: Build system scripts cleanup
  • Include [env] PR:1329: imagedecoder.raw: add add-on
  • Include [env] PR:1355: xorg-server: clean package when nvidia drivers are bumped
  • Include [env] PR:1365: build system: switch to absolute paths
  • Include [env] PR:1379: projectM: remove glew [LE9]
  • Include [pkg] patch: alsa-lib: conf: Add card config for Intel HDMI/DP LPE audio (alsa-lib)
  • Include [pkg] PR:56: bluetooth: add missing 'Connect' option when device is Trusted (service.libreelec.settings)
  • Include [pkg] PR:11668: FFmpegImage: Document and change alignment
  • Include [pkg] PR:11702: [Fix] Songs smart playlists 3 x slower than similar library node
Build Highlights:
  1. Search backwards for keyframe when resuming playback
Build Details:
  1. XBMC:
    • [addons] update Chorus (PR:11717, 1 commit, 16 files changed)
    • Search backwards for keyframe when resuming playback (PR:11713, 1 commit, 1 file changed)
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.
New LibreELEC.tv Leia build #0222: RPi / RPi2
(Supercedes previous build)

Code:
# uname -a
Linux rpi512 4.10.0 #1 Wed Feb 22 21:58:57 GMT 2017 armv6l GNU/Linux

# vcgencmd version
Feb 17 2017 20:41:51
Copyright (c) 2012 Broadcom
version 88b8ca93c6eb22e38531075a6d7e4f25f900af43 (clean) (release)

# lsb_release
LibreELEC (Milhouse) - Version: devel-20170222215751-#0222-ga1d6251 [Build #0222]

# Kodi version
(18.0-ALPHA1 Git:4c792db). Platform: Linux ARM 32-bit

Based on tip of LibreELEC.tv master (a1d6251d, changelog) and tip of XBMC master (e94a5d90, changelog) with the following modifications:
  • Includes newclock5 patches
  • Excludes the LibreELEC linux-01-RPi_support patch in favour of sourcing these and possibly more recent patches directly from kernel branch rpi-4.10.y
  • Includes latest bcm2835-driver next (1a717bb3, ahead +659)
  • Includes latest kodi-platform master (c8188d82)
  • Includes latest libcec master (0a97062d, ahead +22)
  • Includes latest libnfs master (2e0a67fc, ahead +49)
  • Includes latest p8-platform master (2d90f986, ahead +9)
  • Includes latest addons: inputstream.adaptive (a347296e), inputstream.rtmp (df64b9b2, +6), peripheral.joystick (69c9e5fe, +1), pvr.argustv (5a36c586), pvr.demo (8243935f), pvr.dvblink (0015079e), pvr.dvbviewer (9fb34b3c), pvr.filmon (315e5034), pvr.hdhomerun (98cb8d40), pvr.hts (1caa390d, +1), pvr.iptvsimple (53d63cce), pvr.mediaportal.tvserver (019c7e99), pvr.mythtv (18fe56e4, +11), pvr.nextpvr (cb1b5415), pvr.njoy (080cd321), pvr.octonet (8549a31c), pvr.pctv (e67e9695), pvr.stalker (a609149c), pvr.vbox (dea8335a), pvr.vdr.vnsi (7033621d), pvr.vuplus (6ff2eb28), pvr.wmc (5f1db43f)
  • Exclude [env] kodi-999.99-PR11662.patch: kodi: merged upstream
  • Include [env] afbd134f: linux: Enable Fair Queue packet scheduling (TEST)
  • Include [env] e533a8be: linux: Default to CONFIG_TCP_CONG_BBR (TEST)
  • Include [env] patch: ffmpeg: add extra RPi lib required when building ffmpeg command line with gpu service hevc patches
  • Include [env] patch: repository.retroplayer.libreelec.addons: add temp repo for testing
  • Include [env] patch: Don't build ADSP addons
  • Include [env] patch: iwlwifi-firmware: update to iwlwifi-firmware-ba301aa
  • Include [env] patch: Bump included addon versions to prevent online updates
  • Include [env] patch: linux: enable in-tree rtl8192cu for RPi/RPi2
  • Include [env] patch: Add kodi binary addons (pvr, adsp, other)
  • Include [env] patch: Add experimental splash video for RPi
  • Include [env] patch: HACK: Disable multiple PVR addons during migration. Always enable inputstream.* and os.*
  • Include [env] PR:1121: linux: update to linux-4.10.0
  • Include [env] PR:1287: virtio-gpu support (qemu/kvm)
  • Include [env] PR:1326: Build system scripts cleanup
  • Include [env] PR:1329: imagedecoder.raw: add add-on
  • Include [env] PR:1355: xorg-server: clean package when nvidia drivers are bumped
  • Include [env] PR:1365: build system: switch to absolute paths
  • Include [env] PR:1379: projectM: remove glew [LE9]
  • Include [pkg] patch: alsa-lib: conf: Add card config for Intel HDMI/DP LPE audio (alsa-lib)
  • Include [pkg] PR:56: bluetooth: add missing 'Connect' option when device is Trusted (service.libreelec.settings)
  • Include [pkg] PR:11668: FFmpegImage: Document and change alignment
Build Highlights:
  1. Temporarily drop media_build package (remote control issues)
Build Details:
  1. XBMC:
    • [Fix] Songs smart playlists 3 x slower than similar library node (PR:11702, 1 commit, 1 file changed)
    • [EPG] Trac 17323: Guide window fixes (PR:11705, 2 commits, 4 files changed)
    • [estouchy] player process info (PR:11718, 1 commit, 4 files changed)
    • [cleanup] remove some old xbox references (PR:11711, 1 commit, 3 files changed)
    • [Fix]REMIXER tag as alternative to MIXARTIST for FLAC and APE tags (PR:11725, 1 commit, 1 file changed)
    • [Darwin] Separate Apple Remote settings into new group (PR:11692, 1 commit, 4 files changed)
    • Input improvements (PR:11688, 6 commits, 11 files changed)
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.
LOG


Hello again. The Picture quality get worse.
Do you have a solution by now?

Please Help.

Thank you for your great work!
(2017-02-19, 14:15)tjost Wrote: OK, i have a Raspberry Pi3 with a TV Stick. Most of the Channels work fine but some channels, TS Streams, have distortions.
Example I recorded a Channel and instead 3 Hours it show 16 hours of recording.
A lot of distortions in the picture.
Try to play the recording on my Mac. The same, even worse. On VLC on Quicktime. Final Cut or Premiere.

BUT: after plug in the HDD on my Samsung TV the recording is PERFECT! 3 Hours of recording no hick ups in the Picture.
video

VLC, mplayer, Kodi on linux, Kodi on Pi all play the sample with distortions.
I find it hard to imagine how the Samsung TV can display it perfectly.
So,

it not far from perfect. but here is a better example I made with the build from yesterday.

Original From Kodi

Played from TV recordes with iPhone

You will recognize the dramatic improvement.

the fully LOG

And on LiveTV the AC3 Audio is not synchron with the Picture.

Thank you for your Help.
  • 1
  • 68
  • 69
  • 70(current)
  • 71
  • 72
  • 495

Logout Mark Read Team Forum Stats Members Help
LibreELEC Testbuilds for RaspberryPi (Kodi 18.0)24