• 1
  • 51
  • 52
  • 53(current)
  • 54
  • 55
  • 156
OpenELEC Testbuilds for RaspberryPi Part 3 (Kodi 14.0)
(2014-07-24, 13:38)Milhouse Wrote: [*]firmware: deinterlace: process yuvuv directly. See: link

Can any 1080i deinterlace users check deinterlace looks okay as this has been rewritten.
The deinterlace now does fewer memory accesses which may improve audio/video dropout issues which previously have required hvs_priority to work around.

The config.txt option:
Code:
force_fast_deinterlace=1

will force the simpler deinterlace for SD content, which may behave better for some users.
I checked new firmware because of -> firmware: gpioman: Add default pulling to output pins

Lightberry/Hyperion still broken. Last non broken version is Jul 05, 2014.
@Milhouse

(2014-07-24, 13:38)Milhouse Wrote: New OpenELEC Helix build: #0724


Build Highlights:

  1. Firmware:
  2. OpenELEC:
    • tvheadend: update to tvheadend-3.9.1083

Hi Milhouse,

does tvheadend: update to tvheadend-3.9.1083 mean
  1. the frontend (PVR plugin) or
  2. the backend (tvh service)?

And if (2), then how do I install that?
(Yes, I've seen your TVH .zip - and am running it just now.)

Would it be possible to include the pvr.tvh plugin instead of prv.hts (or is it just that)?

Thanks for your great work!

Best
--
Mathias
(2014-07-24, 18:31)gummibaum Wrote: Hi Milhouse,

does tvheadend: update to tvheadend-3.9.1083 mean
  1. the frontend (PVR plugin) or
  2. the backend (tvh service)?

It's #2, the backend and should be included in the build

(2014-07-24, 18:31)gummibaum Wrote: And if (2), then how do I install that?
(Yes, I've seen your TVH .zip - and am running it just now.)

About that.. the plugins should be included by default - uploading ZIPs might have been a mistake on my part, so just use the built-in versions for now (delete the addons from /storage/.xbmc/addons if you've installed any from my download links). I get very confused about addons... it doesn't take much unfortunately. Sad

(2014-07-24, 18:31)gummibaum Wrote: Would it be possible to include the pvr.tvh plugin instead of prv.hts (or is it just that)?

From what I can find out, pvr.tvh is a rewrite of pvr.hts. It has some improvements, but is not yet completed and unless you know why you need it, it's probably best to continue with pvr.hts. You can install pvr.tvh from xbmc.tvheadend.org (I think).

I won't be including pvr.tvh in my builds - if you want it, you should request it upstream (OpenELEC).
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.
(2014-07-24, 13:59)popcornmix Wrote:
(2014-07-24, 13:38)Milhouse Wrote: [*]firmware: deinterlace: process yuvuv directly. See: link

Can any 1080i deinterlace users check deinterlace looks okay as this has been rewritten.
The deinterlace now does fewer memory accesses which may improve audio/video dropout issues which previously have required hvs_priority to work around.

The config.txt option:
Code:
force_fast_deinterlace=1

will force the simpler deinterlace for SD content, which may behave better for some users.

Wow, you're fast :-)

Unfortunatly, it doenst seems to help much.

I also did a openelec build to force fast deinterlace in omxplayer, also without succes.
Code:
if(m_deinterlace)
   {
+    bool advanced_deinterlace = false; /*port_image.format.video.nFrameWidth * port_image.format.video.nFrameHeight <= 576 * 720; glenn*/
+    CLog::Log(LOGERROR, "--------Force fast deinterlacing--------");
+    if (!advanced_deinterlace)
+    {
(2014-07-25, 14:58)glenn 1990 Wrote: Unfortunatly, it doenst seems to help much.

What resolution video are you playing? It will have no effect on HD, only SD.
(2014-07-25, 15:12)popcornmix Wrote:
(2014-07-25, 14:58)glenn 1990 Wrote: Unfortunatly, it doenst seems to help much.

What resolution video are you playing? It will have no effect on HD, only SD.

video is SD h264, 704x576
display is set to 1080p50Hz

Like the sample I gave you:
https://dl.dropboxusercontent.com/u/1813...-07-22.mkv
Hmm. Got a small problem, if I use the FTP connector..

I have a Blu-ray ISO, that I try to playback via FTP on my local network (FTP server in house).
The video is stopping on eath 30-60 sec. to buffer up, and then starts again. The CPU load is 98-100% on my RPI (last Milhouse build).
If I connect via SMB to the same local server, playback works fine, and the CPU load is about 50%.

Is ther a setting, that I have overlooked, when using FTP ??
I have tryed many settings for the video buffering, but no one works for me.
The problem is only when I playback Blu-ray via FTP.

Best regards
Hi,
i have a live tv channel which used to work (always worked fine except that auto de-interlace did not seem to work on this channel) but stopped working with the last few milhouse builds. I uploaded a sample here

https://dl.dropboxusercontent.com/u/5174353/Sample.zip

What happens is that i click on channel it starts buffering and stays at 0% - happens on both 128mb and 256mb splits.
Same channel works fine on windows xbmc.
(2014-07-03, 15:55)doveman2 Wrote: My brother's been running the 0611 build and tells me he's had three problems:

1) Not being able to wake it from dimmed screen state

2) Videos stopping suddenly and the RPi rebooting. Apparently this happens randomly, sometimes after a few seconds and other times half-way through the video and on the next try, they can play from the problem point OK.

3) Videos suddenly becoming choppy and the sound breaking up, before stopping. This sounds like a buffering issue (these are local videos on the PC, not streamed though).

I've updated him to the 0703 build but has there been any changes since the 0611 one that might fix these problems? I've told him to try the alternate player if he still has problems (Default is set to dvdplayer).

I haven't had a chance to try disabling FIQ FSM on my brother's system yet but I spoke to him today and he says he hasn't had these problems since I updated him to the 0703 build, so I guess something in that must have fixed them. I had advised him to try the other player to see if it only happened with the default one but he says he hasn't even needed to do that Smile
(2014-07-27, 17:10)delinend Wrote: Hmm. Got a small problem, if I use the FTP connector..

I have a Blu-ray ISO, that I try to playback via FTP on my local network (FTP server in house).
The video is stopping on eath 30-60 sec. to buffer up, and then starts again. The CPU load is 98-100% on my RPI (last Milhouse build).
If I connect via SMB to the same local server, playback works fine, and the CPU load is about 50%.

Is ther a setting, that I have overlooked, when using FTP ??
I have tryed many settings for the video buffering, but no one works for me.
The problem is only when I playback Blu-ray via FTP.

Best regards

Is this a 256MB or 512MB Pi? The default <cachemembuffersize> is now 2MB on 256MB Pis, and 20MB on 512MB Pis.

Is the FTP-buffering behaviour the same with omxplayer and dvdplayer?

Can you go back through older builds until you find a version which doesn't buffer over FTP? Do you get the same behaviour with stock builds?
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.
(2014-07-27, 20:01)Milhouse Wrote:
(2014-07-27, 17:10)delinend Wrote: Hmm. Got a small problem, if I use the FTP connector..

I have a Blu-ray ISO, that I try to playback via FTP on my local network (FTP server in house).
The video is stopping on eath 30-60 sec. to buffer up, and then starts again. The CPU load is 98-100% on my RPI (last Milhouse build).
If I connect via SMB to the same local server, playback works fine, and the CPU load is about 50%.

Is ther a setting, that I have overlooked, when using FTP ??
I have tryed many settings for the video buffering, but no one works for me.
The problem is only when I playback Blu-ray via FTP.

Best regards

Is this a 256MB or 512MB Pi? The default <cachemembuffersize> is now 2MB on 256MB Pis, and 20MB on 512MB Pis.

Is the FTP-buffering behaviour the same with omxplayer and dvdplayer?

Can you go back through older builds until you find a version which doesn't buffer over FTP? Do you get the same behaviour with stock builds?

It's a 512MB Pi running 1GHz.
I only use omplayer, as it only runs for all my contet.
I'll try older versions tomorow, but it's a new thing, that I was trying to play Blu-ray via FTP. Have not tryed it before. Only used FTP to playback SD, until yet.
But it look strange that the FTP protocol use 50% more CPU than the SMB.
I have allso tryed to test my FTP server localy, at I can pull 10 times more bandwith from it, than the Pi playback via FTP use. So it's not my FTP server that have a problem.

I have allso tryed to set cachemembuffering to 50MB, but no luck. Still 98-100% CPU load on Blu-ray playback.
New OpenELEC Helix build: #0727
(Supercedes previous build)

Code:
# uname -a
Linux rpi512 3.15.6 #1 PREEMPT Sun Jul 27 21:00:45 BST 2014 armv6l GNU/Linux

# vcgencmd version
Jul 23 2014 21:08:37
Copyright (c) 2012 Broadcom
version 174cdd77563b98023955a94cb8d072d9c7095d6f (clean) (release)

# lsb_release
OpenELEC (Milhouse) - Version: devel-20140727205930-r18859-gee8a220

Based on tip of OpenELEC master (ee8a220, changelog) and tip of XBMC master (d365123, changelog) with the following modifications:
  • Includes newclock3 patches
  • Excludes the OpenELEC fernetmenta patches due to conflicts with newclock3
  • Excludes the OpenELEC linux-01-RPi_support patch in favour of sourcing these and possibly more recent patches directly from kernel branch rpi-3.15.y
  • Excludes the OpenELEC xbmc-001-newclock3 patch in favour of sourcing these and possibly more recent patches directly from newclock3 branch
  • Default setting for "Show RSS Feed" changed to disabled
  • Disabled "Total Duration" in Confluence (see build #0221 for details)
  • Includes zram with LZ4 compression as a kernel module. See guide. See build #0706 for config patch.
  • Includes latest libnfs master
  • Includes latest libcec master
  • Includes libcec double-key suppression.
  • Includes libcec CEC Standby Fix.
  • Increase scan interval of PeripBusCEC from 5000 to 60000, reducing CPU loading by about 2% (1GHz Pi) every 5 seconds (even when CEC is "disabled")
  • Includes CONFIG_COREDUMP=y to allow creation of coredumps
  • Includes PR4990: Allow larger font size
Build Highlights:
  1. First build of what will be OpenELEC 5.0.
  2. zram support will be dropped in the next build due to lack of interest (OpenELEC PR has not been raised).
  3. SYSTEM-to-RAM removal has been reverted, but is now disabled for R-Pi.
Build Details:
  1. OpenELEC:
    • util-linux: update to util-linux-2.25
    • libXext: update to libXext-1.3.3
    • Revert "busybox: remove SYSTEM-to-RAM support, it dont improves much"
    • busybox: remove support for initramfs.conf, disable SYSTEM-to-RAM support for RPi
    • util-linux: build without python
    • util-linux: build without libsmartcols
    • libdrm: update to libdrm-2.4.55
    • config/functions: clean up optimize leftover
    • libgpg-error: build static
    • libressl: update to libressl-2.0.3
    • taglib: build static
    • util-linux: build with libsmartcols if SWAP supported is enabled, dont build with libsmartcols in initramfs
    • util-linux: remove old config options
    • gcc: add patch to fix GCC-61801 (and GCC-61904)
    • ffmpeg: add patch to support free builds with libressl support, disable nonfree build
    • xbmc-pvr-addons: update to xbmc-pvr-addons-9d33717
    • remove package 'gnutls'
    • remove package 'nettle'
    • config/version: set OS_VERSION to 5.0
    • - libnfs: update to 1.9.5 (PR:3383, 1 commit, 1 file changed)
  2. XBMC:
    • fixed: some issues pointed out by valgrind (PR:5051, 1 commit, 5 files changed)
    • fix: pebkac with gradient banding (PR:5078, 1 commit, 2 files changed)
    • [pi] Fix for logged resolutions (PR:5087, 1 commit, 1 file changed)
    • [omx] Remove logging for texture jobs (PR:5088, 1 commit, 1 file changed)
    • [rbp] Add config.txt settings to log file (PR:5086, 1 commit, 1 file changed)
    • Bump audio encoder addons to latest master (PR:5069, 1 commit, 4 files changed)
    • WASAPI: fix empty audio device in settings dialog after c401513a2994c09c... (PR:5103, 1 commit, 1 file changed)
    • [win32] automatic versioning of XBMC_PC.rc (PR:5104, 3 commits, 3 files changed)
    • [addons] sync with repo
    • ignore addons/audioencoder.* directories
    • [win32] fix skipping copying userdata to roaming on clean install. fixes #15302
  3. kernel 3.15.y:
    • BCM2708: DT: change 'axi' nodename to 'soc'
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.
I have tried the force fast deinterlace and it is a huge improvement to all my sd channels now they are all watchable. Thank you


Code:
force_fast_deinterlace=1
(2014-07-27, 21:14)delinend Wrote:
(2014-07-27, 20:01)Milhouse Wrote:
(2014-07-27, 17:10)delinend Wrote: Hmm. Got a small problem, if I use the FTP connector..

I have a Blu-ray ISO, that I try to playback via FTP on my local network (FTP server in house).
The video is stopping on eath 30-60 sec. to buffer up, and then starts again. The CPU load is 98-100% on my RPI (last Milhouse build).
If I connect via SMB to the same local server, playback works fine, and the CPU load is about 50%.

Is ther a setting, that I have overlooked, when using FTP ??
I have tryed many settings for the video buffering, but no one works for me.
The problem is only when I playback Blu-ray via FTP.

Best regards

Is this a 256MB or 512MB Pi? The default <cachemembuffersize> is now 2MB on 256MB Pis, and 20MB on 512MB Pis.

Is the FTP-buffering behaviour the same with omxplayer and dvdplayer?

Can you go back through older builds until you find a version which doesn't buffer over FTP? Do you get the same behaviour with stock builds?

It's a 512MB Pi running 1GHz.
I only use omplayer, as it only runs for all my contet.
I'll try older versions tomorow, but it's a new thing, that I was trying to play Blu-ray via FTP. Have not tryed it before. Only used FTP to playback SD, until yet.
But it look strange that the FTP protocol use 50% more CPU than the SMB.
I have allso tryed to test my FTP server localy, at I can pull 10 times more bandwith from it, than the Pi playback via FTP use. So it's not my FTP server that have a problem.

I have allso tryed to set cachemembuffering to 50MB, but no luck. Still 98-100% CPU load on Blu-ray playback.

I have just tryed Gotham (openELEC 4.0.7) and last build #0727, and both have the same issue when using the FTP protocol connector.

When I Playback Blu-ray via FTP the CPU load is 98-100% and the video stop/start each 50-60 sec.
When i Playback Blu-ray via SMB the CPU load is 50-70% and playback works fine.

It's the same CPU load with dvdplayer and omxplayer. But I see, that dvdplayer use much more memory, when I playback.

It look like there is some issue whith the FTP protocol, that takes too much CPU time.

Here my Overclock:
arm_freq=1000
core_freq=500
sdram_freq=500
over_voltage=6

Here my advancedsettings.xml :
<advancedsettings>
<video>
<defaultplayer>omxplayer</defaultplayer>
<defaultdvdplayer>omxplayer</defaultdvdplayer>
</video>

<ftp>
<remotethumbs>true</remotethumbs>
</ftp>
</advancedsettings>

Best regards
  • 1
  • 51
  • 52
  • 53(current)
  • 54
  • 55
  • 156

Logout Mark Read Team Forum Stats Members Help
OpenELEC Testbuilds for RaspberryPi Part 3 (Kodi 14.0)8