• 1
  • 105
  • 106
  • 107(current)
  • 108
  • 109
  • 277
OpenELEC Testbuilds for RaspberryPi Part 2
I can add these builds to my buildbot / create a folder on the CDN that i used for xbmcnightlybuilds.com if it helps?

i.e could do similar to what i'm doing for the RetroPlayer builds and make a folder similar to: http://cdn.us.serverst.at/xbmcnightlybui...troPlayer/
Sorry if this a stupid question but I did search and couldn't find it...
How can I change the subtitle download language in the latest MilhouseVH build?
It only shows [eng] subs available for download in opensubtitles.

FOUND IT!

Settings > Videos > Subtitles

facepalm
 
  • Intel NUC Kit DN2820FYKH ~ Crucial DDR3L SO-DIMM 4GB ~ SanDisk ReadyCache 32GB SSD ~ Microsoft MCE model 1039 RC6 remote
(2013-11-28, 18:41)popcornmix Wrote:
(2013-11-28, 18:37)evanspae Wrote: As previously mentioned the time to start playing an HD Television recording is showing a tremendous improvement, but alas I am now getting a drift of lipsync of approx 500ms over a 2hr period?

Live TV or from a file?
Are there errors in the file (e.g. from a poor antenna?)
Is this a new problem? When did it last work?

As mentioned above this is playback of pre recorded .ts file on a well established system. This and other files plays fine on other xbmc clients (mainly 12.2 Frodo builds) both on PCs and stable raspberrypi openelec 3.2.3. There are not reception or file errors and it is a new problem on latest build.

I
Location UK; Media server Windows 7 with ArgusTV 2.3 with TBS6981 DVB-S2 x4 and DVB-T x 2:All network connections cabled on 1Gb router Raspberry Pi2 1GB x 2; RPI 3 x1; PiB+512MB x 3; TV Samsung 55" C8000; AV Denon AVR X2200W
(2013-11-29, 13:24)evanspae Wrote: As mentioned above this is playback of pre recorded .ts file on a well established system. This and other files plays fine on other xbmc clients (mainly 12.2 Frodo builds) both on PCs and stable raspberrypi openelec 3.2.3. There are not reception or file errors and it is a new problem on latest build.

If you seek to the end, is the sync off by the same amount as if you'd played from the beginning, or does seeking fix the sync?
Can you upload a file that has this problem and send me a link? The smaller the better, although in this case the drift may only be visible in a large file.
(Google drive is a good way of hosting a large file).
@MilhouseVH
I know this is a big ask but how difficult/time consuming would it be for you to recompile your last build based on Linux 3.10.xx - I will understand your reluctance if this is not practical.

My reason for asking this is that with all the latest dev builds (except for Rbej's builds), the GPIO ir receiver does not work and I believe I have found that the culprit may be the Linux version.

I have tried at least a dozen different builds and my results are:

All official Openelec builds (e.g. 3.1.6, 3.1.7, 3.2.3) work - they use Linux version 3.10.xx
All Rbej Frodo and Gotham builds work - he uses version 3.10.xx
Chris Swan builds: all builds up to 13/9/13 (build version r15595) work - uses Linux version 3.10.xx
all builds from 14/9/13 (build version r15889) do not work - uses Linux version 3.11.xx
Your builds using Linux version 3.12.xx do not work

Of course it could be a Frodo/Gotham thing but since Rbej's Gotham releases use Linux version 3.10.xx that work, I believe it is more likely to be a driver problem that is packaged with the Linux kernel.

My other post gives some more information.

If I was a more able person I would make my own build but sadly I don't have the knowledge or the tools to do this.
Hi,

sorry about this dumb question, but google din't helped me mutch.

What are, is any, the main differences from the different builds of MilhouseVH and Rbej?
Can someone give some highlights about how this process works?

Thanks!
I'll take a crack at providing some basic info (relevent as of November 29, 2013) in response to your question.
- rbej does frodo and gotham builds. You can search for info about the differences between gotham (xbmc pre-alpha 13) and frodo (xbmc 12).
- rbej bases his builds (frodo and gotham) on openelec 3.x
- the release versions of openelec 3.x use frodo
- the recent gotham builds by others (mostly Milhouse) have been based on openelec 4.x
- rbej has not done a new gotham build for over a month. He indicated that there is an issue with 3.2.x that has prevented him from making newer builds.
- Rbej indicated (and it makes sense) that builds based on stable openelec (3.x) will be more stable and have fewer issues than builds based on openelec 4.x (which is very much in development.
- Rbej's latest gotham build, since it is over a month old, will not have the newest refinements/commits/PRs/enhancements/bug fixes AND new bugs.

Another way of looking at it: The most notable improvements made over the past month relate to speed/efficiency/performance. So, I would say:
- Rbej gotham: very stable, fewer bugs;
- Newer builds: faster, more bugs, but working very well for many people.
Hi allan87,

As you are very aware of builds and I don't want to disturb the package builders, I have a question:
I'd like to have CECAnyway in a build, as I don't have a CEC TV but a monitor (DVI).

Is it possible that a package builder include CECAnyway in a near futur build?
How they choose the next feature to add?

I am ready to help to test for debug.
Thanks
Config, video/audio player:
3T HDD <USB> Odroid N2+ / CoreElec <HDMI> Denon AVR-2313 <HDMI> LG TV 55UF860V
                                          <nfs wired> Linksys WRT32X router <USB> 4T HDD
Sorry, I don't really know that much. My information is largely from following this thread.
Dear allan87,
thanks for your great answer!
(2013-11-28, 02:24)MilhouseVH Wrote: New OpenELEC Gotham build on dropbox.

Code:
rpi512:~ # vcgencmd version
Nov 27 2013 22:47:13
Copyright (c) 2012 Broadcom
version 95b18c7513b1cdd8ab76f541338f749285898fb7 (tainted) (release)
rpi512:~ # uname -a
Linux rpi512 3.12.1 #1 PREEMPT Wed Nov 27 23:09:45 GMT 2013 armv6l GNU/Linux
rpi512:~ # lsb_release
OpenELEC_Gotham (unofficial) - Version: devel-20131127234643-r16442

Based on tip of XBMC master (81a9c0c) and OpenELEC master (d1125a0) with the following modifications:
  • Includes latest firmware (7400b45) from master - initial testing confirms it's chirp-free!
  • Includes these newclock3 commits (except for 09445f5 which I've replaced with a static spinner)
  • Includes fix for consistent webserver/GUI artwork caching (PR:3671)
  • Excludes the fernetmenta patch as this conflicts with the newclock3 ffmpeg (ad5987e) patch
This build includes even more newclock3 performance improvements, and also the EDL fix for anyone that is able to test that.

Many thanks to popcornmix for squashing these bugs with such dedication, and Ben for eking out even more performance! Smile

is it possible to run this off of NFS file Share?
Bug? I have not been able to install add-ons with the recent build. It says "working", the text by the add-on says "downloading 0%", but both indicators soon disappear and then its back to square 1.
(2013-11-28, 23:36)goRt Wrote: Hi,
Any chance of getting your builds supported with the devbuild update addon:
http://openelec.tv/forum/128-addons/49855

Thanks in advance

(2013-11-29, 06:55)Leopold Wrote: @MilhouseVH If you could put your builds into the same Dropbox folder and share the url to the folder then I can add it to the add-on. I've found your builds to be a big improvement over the latest OpenELEC release so it would be great if you could do that.

delinend has kindly set me up on his server at the following url:

http://netlir.dk/rbej/builds/index.php?dir=MilhouseVH/

and I'll be pushing my infrequent releases to that folder rather than continue with dropbox.

If you want to update the addon to reference this folder, fine with me.

(2013-11-30, 03:41)unclejoe01 Wrote: is it possible to run this off of NFS file Share?

Don't see why not.

(2013-11-30, 04:32)allan87 Wrote: Bug? I have not been able to install add-ons with the recent build. It says "working", the text by the add-on says "downloading 0%", but both indicators soon disappear and then its back to square 1.

Anything in your debug log?
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.
(2013-11-29, 16:57)Reddog999 Wrote: @MilhouseVH
I know this is a big ask but how difficult/time consuming would it be for you to recompile your last build based on Linux 3.10.xx - I will understand your reluctance if this is not practical.

My reason for asking this is that with all the latest dev builds (except for Rbej's builds), the GPIO ir receiver does not work and I believe I have found that the culprit may be the Linux version.

I have tried at least a dozen different builds and my results are:

All official Openelec builds (e.g. 3.1.6, 3.1.7, 3.2.3) work - they use Linux version 3.10.xx
All Rbej Frodo and Gotham builds work - he uses version 3.10.xx
Chris Swan builds: all builds up to 13/9/13 (build version r15595) work - uses Linux version 3.10.xx
all builds from 14/9/13 (build version r15889) do not work - uses Linux version 3.11.xx
Your builds using Linux version 3.12.xx do not work

Of course it could be a Frodo/Gotham thing but since Rbej's Gotham releases use Linux version 3.10.xx that work, I believe it is more likely to be a driver problem that is packaged with the Linux kernel.

My other post gives some more information.

If I was a more able person I would make my own build but sadly I don't have the knowledge or the tools to do this.

Not likely, no - I'm more interested in publishing and testing upcoming fixes and new features rather than create custom builds that resolve specific issues like this. You should really work with the OpenELEC developers to try and resolve the issues that remain with the current 3.12.x kernel - if/when a patch becomes available I'll include it in my build.

Have you tried copying a 3.10.x kernel to the latest Gotham build - does it work?
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.
Unfortunately I don't have any non-Pi Gotham system to compare this with, but the height/width properties of cached artwork are not always being written to Textures13.db. I've compared this with an OE Frodo x86 system and the height/width is consistently stored in the cache (whether cached via the GUI or http).

However on the Pi, the height/width for local artwork is not being stored, but it is being stored for remote artwork (not sure why - maybe part of the daily re-hashing process?)

It isn't a problem (as far as I can tell), but presumably these height/width fields serve some sort of purpose and it's strange that the Pi* doesn't appear to be populating them consistently, is there maybe a problem or omission in the OMX thumbnail creation pipeline?

For instance on Gotham/Pi:
Code:
rpi512:~ # ./texturecache.py s zombieland
031634|8/8e0f745e.jpg|0000|0000|0009|2013-11-18 11:08:15|2013-11-30 07:40:22|nfs://192.168.0.3/mnt/sha...ombieland (2009)[BDRip]-fanart.jpg
031635|e/ea859e8c.png|0281|0500|0001|2013-11-10 03:15:29|                   |http://assets.fanart.tv/f...rt/zombieland-4fd8c70fd673c.png
031636|0/061c901f.png|0310|0800|0001|2013-11-10 03:15:31|                   |http://assets.fanart.tv/f...elogo/zombieland-5145e97ed73a4.png
032248|9/9993f35a.jpg|0000|0000|0001|2013-11-30 07:39:56|2013-11-30 07:39:56|nfs://192.168.0.3/mnt/sha...ombieland (2009)[BDRip]-poster.jpg

And on Frodo/x86:
Code:
OpenELEC:~ # ./texturecache.py s zombieland
016531|9/99b657eb.png|0310|0800|0005|2013-05-28 15:49:43|                   |http://assets.fanart.tv/f...elogo/zombieland-50e895a25e7ed.png
019434|c/c947f7eb.jpg|1080|1920|0002|2013-11-30 07:53:32|2013-11-30 07:53:32|/storage/freenas/media/Vi...2009)[BDRip]-fanart.jpg
019703|d/dedb70ef.jpg|0720|0486|0001|2013-11-30 07:54:18|2013-11-30 07:54:18|/storage/freenas/media/Vi...2009)[BDRip]-poster.jpg
016028|e/ea859e8c.png|0281|0500|0003|2013-05-05 01:36:31|                   |http://assets.fanart.tv/f...rt/zombieland-4fd8c70fd673c.png

The third and fourth fields are the height and width - on Gotham they're both 0000 for the local artwork.

Can anyone confirm what height/width properties you get for freshly cached artwork on Gotham/x86?

* It could be a Gotham problem and not Pi specific, I simply can't tell right now.
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.
  • 1
  • 105
  • 106
  • 107(current)
  • 108
  • 109
  • 277

Logout Mark Read Team Forum Stats Members Help
OpenELEC Testbuilds for RaspberryPi Part 223