•   
  • 1
  • 2(current)
  • 3
  • 4
  • 5
  • 168
  •   
  Thread Closed
OpenELEC Testbuilds for RaspberryPi (Kodi 16.0)
#16
Thanks for all of the hard work Milhouse! For now I can't move beyond 0703 because the MythTV plugin is one of my main use cases. I understand not wanting to keep building the pvr plugins and the hassle of doing so. Hopefully there will be a solution soon so that we can download a Kodi 16 compatible version of them from the repositories at some point.
#17
+1

I understand the lack of ArgusTV support although not your problem, means I will have to revert to earlier version...SadSad
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
#18
Same for me as a tvheadend user.

I'm not crystal clear on the details but could this problem be solved by setting up an additional add-on repository for the test builds?
Will the problem go away anyway once Isengard is released?
Leopold's Repository: Home of LibreELEC Dev Updater ...
#19
(2015-07-06, 20:10)Leopold Wrote: Same for me as a tvheadend user.

I'm not crystal clear on the details but could this problem be solved by setting up an additional add-on repository for the test builds?

I'm not entirely sure it would, because if my repo contains v1.10.5 but the Isengard repo contains v1.10.6 then the add-on may still update from the Isengard repo, which is not what I want (nor do I want the additional build/upload/maintenance step of my own repository).

I could stop using all upstream OpenELEC repos and only provide my own repo, but then what about all the other non-PVR addons in the Isengard repo, should I provide these add-ons too? I really don't want to get into this game of reproducing the entire OE infra just because of PVR addons.

However I think I've found a simple solution that should prevent PVR add-ons (and only PVR add-ons) from updating no matter what PVR versions are available in online repositories, so they should be back in the next build. Other non-PVR addo-ons can still be installed and will update normally.
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.
#20
Thanks, I will be wait impatiently. Angel
#21
New OpenELEC Isengard build #0706: RPi / RPi2
(Supercedes previous build)

Code:
# uname -a
Linux rpi512 4.1.1 #1 Mon Jul 6 21:03:24 BST 2015 armv6l GNU/Linux

# vcgencmd version
Jun 30 2015 15:05:35
Copyright (c) 2012 Broadcom
version 15192535e0c684b620b6a925315c8dd7c4c13097 (clean) (release)

# lsb_release
OpenELEC (Milhouse) - Version: devel-20150706210238-#0706-ge9b9e85 [Build #0706]

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

# Kernel device tree status: Enabled

Based on tip of OpenELEC master (e9b9e859, changelog) and tip of XBMC master (092818af, changelog) with the following modifications: Build Highlights:
  1. PVR Add-ons are back, and should no longer update from online repositories (all other add-ons are unaffected)
Build Details:
  1. OpenELEC:
    • libinput: update to libinput-0.19.0 (e9b9e859)
  2. XBMC:
    • [guilib] add $ESCVAR[] infoformat to allow escaping of variables (PR:7219, 1 commit, 1 file changed)
    • [PVR] Bump PVR addon API to version 2.0.0, bump addons (PR:7408, 2 commits, 20 files changed)
    • [guilib] DialogKeyboard: Do not register input for buttons with id >= 500 (PR:7409, 1 commit, 1 file changed)
    • [infomanager] Move Sysinfo out of infomanager (PR:7003, 3 commits, 34 files changed)
    • CPeripherals: update CGUIDialogPeripheralManager asynchronously to avoid deadlocks (PR:7422, 1 commit, 3 files changed)
  3. Additional commits/pull requests/changes not yet merged upstream:
    • Added: patch: Enable pvr addons, disable PVR updates
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.
#22
Hooray! MyPVR plugin is back and working well. Thanks Milhouse!!
#23
Big thanks, wmcpvr works fine.

But a small problem I've.
When the screensaver dim is working and i press a button,
It will not change to bright, but the courser is moving.
#24
New OpenELEC Isengard build #0707: RPi / RPi2
(Supercedes previous build)

Code:
# uname -a
Linux rpi512 4.1.1 #1 Tue Jul 7 21:02:30 BST 2015 armv6l GNU/Linux

# vcgencmd version
Jun 30 2015 15:05:35
Copyright (c) 2012 Broadcom
version 15192535e0c684b620b6a925315c8dd7c4c13097 (clean) (release)

# lsb_release
OpenELEC (Milhouse) - Version: devel-20150707210143-#0707-g59a3db3 [Build #0707]

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

# Kernel device tree status: Enabled

Based on tip of OpenELEC master (59a3db3c, changelog) and tip of XBMC master (73bfc950, changelog) with the following modifications: Build Highlights:
  1. Bump libshairplay and AirTunes support
Build Details:
  1. OpenELEC:
    • Bump libshairplay in anticipation of Kodi PR7093 (PR:4226, 1 commit, 3 files changed)
    • libevdev: update to libevdev-1.4.3 (461be6da)
    • nano: update to nano-2.4.2 (59a3db3c)
  2. XBMC:
    • [smartplaylist] fix musicvideo grouping by artist (PR:7419, 2 commits, 2 files changed)
    • [ios/docs] - mention support for xcode6.4 and ios sdk 8.4 (verified w… (PR:7433, 1 commit, 1 file changed)
    • [smartplaylist] fix broken genre after PR7347 (closes #16104) (PR:7437, 1 commit, 1 file changed)
    • [ios/gl/gles] - Fix glstring possible bad access (PR:7430, 2 commits, 3 files changed)
    • [AirTunes] - features (PR:7093, 8 commits, 19 files changed)
    • Recent merge broke project files, missing closing xml tag (PR:7444, 1 commit, 1 file changed)
    • [swig] Use std::type_index instead of a homegrown implementation. (PR:7033, 1 commit, 3 files changed)
    • [win32][fixed] Proper 24.0/60.0 Hz refresh rate in fake fullscreen mode (PR:7228, 1 commit, 1 file changed)
    • cosmetic: misplaced parenthesis (PR:7447, 1 commit, 1 file changed)
    • [PVR] Series Recordings - Coverity / Code Cleanup (PR:7439, 5 commits, 11 files changed)
  3. pvr.vbox:
    • tell tinyxml2 to collapse whitespace, you never know what you get with external (d426c9d6)
    • use ReadFile() instead of ReadFileString(), the latter doesn't seem to work (6c827105)
    • parse and include event icons (fixes #78) (4c054319)
    • change version to 2.0.0 on the master branch (17892976)
    • bump version to 2.0.1 (39e84c60)
    • added versioning guidelines to README (closes #87) (f7e02322)
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.
#25
@Milhouse

Hi,

I don't know if it's just my ISP but I am unable to download any of these new builds faster than 32Kb/s

When I run a ping, I am getting this:

C:\WINDOWS\system32>ping milhouse.openelec.tv

Pinging milhouse.openelec.tv [82.220.2.33] with 32 bytes of data:
Reply from 82.220.2.33: bytes=32 time=107ms TTL=51
Reply from 82.220.2.33: bytes=32 time=113ms TTL=51
Reply from 82.220.2.33: bytes=32 time=107ms TTL=51
Reply from 82.220.2.33: bytes=32 time=107ms TTL=51

Ping statistics for 82.220.2.33:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 107ms, Maximum = 113ms, Average = 108ms

If I ping Google, I have reasonable replies:

C:\WINDOWS\system32>ping 8.8.8.8

Pinging 8.8.8.8 with 32 bytes of data:
Reply from 8.8.8.8: bytes=32 time=12ms TTL=57
Reply from 8.8.8.8: bytes=32 time=12ms TTL=57
Reply from 8.8.8.8: bytes=32 time=12ms TTL=57
Reply from 8.8.8.8: bytes=32 time=12ms TTL=57

Ping statistics for 8.8.8.8:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 12ms, Maximum = 12ms, Average = 12ms

C:\WINDOWS\system32>


Can you please have a look? It was working with 6.9 Mb/s before.

Thanks,
#26
(2015-07-08, 00:55)mp1111 Wrote: I don't know if it's just my ISP but I am unable to download any of these new builds faster than 32Kb/s

Code:
$ wget http://milhouse.openelec.tv/builds/master/RPi/OpenELEC-RPi.arm-6.0-Milhouse-20150707210143-%230707-g59a3db3.tar
--2015-07-07 23:57:20--  http://milhouse.openelec.tv/builds/master/RPi/OpenELEC-RPi.arm-6.0-Milhouse-20150707210143-%230707-g59a3db3.tar
Resolving milhouse.openelec.tv (milhouse.openelec.tv)... 82.220.2.33
Connecting to milhouse.openelec.tv (milhouse.openelec.tv)|82.220.2.33|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 120156160 (115M) [application/x-tar]
Saving to: ‘OpenELEC-RPi.arm-6.0-Milhouse-20150707210143-#0707-g59a3db3.tar’

100%[==================================================================>] 120,156,160 2.27MB/s   in 52s

2015-07-07 23:58:12 (2.20 MB/s) - ‘OpenELEC-RPi.arm-6.0-Milhouse-20150707210143-#0707-g59a3db3.tar’ saved [120156160/120156160]

2.2MB/s, which is the upper limit of my 22Mb/s downstream connection here in the UK (London).

Code:
$ ping milhouse.openelec.tv
PING milhouse.openelec.tv (82.220.2.33) 56(84) bytes of data.
64 bytes from ds1789932.dedicated.solnet.ch (82.220.2.33): icmp_seq=1 ttl=49 time=31.8 ms
64 bytes from ds1789932.dedicated.solnet.ch (82.220.2.33): icmp_seq=2 ttl=49 time=32.3 ms
64 bytes from ds1789932.dedicated.solnet.ch (82.220.2.33): icmp_seq=3 ttl=49 time=32.1 ms
64 bytes from ds1789932.dedicated.solnet.ch (82.220.2.33): icmp_seq=4 ttl=49 time=32.7 ms
^C
--- milhouse.openelec.tv ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 31.869/32.283/32.748/0.389 ms

$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=53 time=9.83 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=53 time=9.48 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=53 time=9.16 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=53 time=9.70 ms
^C
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 9.167/9.547/9.837/0.280 ms

When you ping Google 8.8.8.8 you're unlikely to be connecting to a Google server in the same geographical location as the OpenELEC server (which appears to be located just outside Bern, in Switzerland), and instead you'll be pinging a Google server very close to your ISP.

Try running a tracepath (Ubuntu/Debian), traceroute (OpenELEC) or tracert (Windows) between you and the OpenELEC server:
Code:
$ tracepath 82.220.2.33
1?:  [LOCALHOST]                                         pmtu 1500
1:   inet-router.local                                     0.733ms
1:   inet-router.local                                     0.563ms
2:   inet-router.local                                     0.499ms pmtu 1458
2:   no reply
3:   31.55.186.133                                        18.798ms asymm  5
4:   31.55.186.156                                        18.937ms
5:   195.99.127.38                                        18.968ms
6:   peer6-hu0-19-0-1.telehouse.ukcore.bt.net             18.485ms
7:   uk-lon01a-ri4-gi-3-0-2.aorta.net                     19.491ms
8:   nl-ams05a-rd2-xe-2-3-1.aorta.net                     40.450ms asymm 15
9:   uk-lon01a-ri4-ge-4-0-0.aorta.net                     38.746ms asymm 14
10:  84.116.134.65                                        37.250ms
11:  84.116.202.230                                       38.189ms
12:  62.179.20.18                                         40.744ms
13:  151.252.33.64                                        41.223ms asymm 11
14:  eq2zrh-bbr02.solnet.ch                               50.573ms asymm 13
15:  vtlzrh-bbr01.solnet.ch                               42.420ms asymm 14
16:  vtlolt-bbr01.solnet.ch                               43.362ms asymm 15
17:  vtlbrn-bbr01.solnet.ch                               43.881ms asymm 16
18:  d11sol-bbr01.solnet.ch                               43.526ms asymm 14
19:  d11sol-dgr01.solnet.ch                               42.838ms asymm 15
20:  ds1789932.dedicated.solnet.ch                        44.173ms reached
     Resume: pmtu 1458 hops 20 back 16

Windows:
Code:
C:\>tracert 82.220.2.33

Tracing route to ds1789932.dedicated.solnet.ch [82.220.2.33]
over a maximum of 30 hops:

1     <1 ms    <1 ms    <1 ms  inet-router.local [192.168.0.1]
2      *        *        *     Request timed out.
3      9 ms     8 ms     8 ms  31.55.186.133
4      9 ms     8 ms     9 ms  31.55.186.156
5      9 ms     9 ms     9 ms  195.99.127.58
6      9 ms     8 ms     9 ms  peer6-hu0-19-0-1.telehouse.ukcore.bt.net [213.121.193.181]
7      9 ms     9 ms     9 ms  uk-lon01a-ri4-gi-3-0-2.aorta.net [213.46.174.97]
8     28 ms    28 ms    28 ms  nl-ams05a-rd2-xe-4-1-0.aorta.net [84.116.130.9]
9     52 ms    32 ms    27 ms  uk-lon01a-ri4-ge-4-0-0.aorta.net [84.116.132.18]
10    27 ms    26 ms    27 ms  uk-lon01b-rd1-xe-7-1-2.aorta.net [84.116.134.229]
11    28 ms    28 ms    27 ms  84.116.202.230
12    29 ms    38 ms    29 ms  62.179.20.18
13    37 ms    29 ms    29 ms  151.252.33.64
14    31 ms    42 ms    30 ms  eq2zrh-bbr02.solnet.ch [82.220.32.113]
15    31 ms    31 ms    31 ms  vtlzrh-bbr01.solnet.ch [212.101.0.63]
16    31 ms    31 ms    31 ms  vtlolt-bbr01.solnet.ch [212.101.0.48]
17    32 ms    32 ms    32 ms  vtlbrn-bbr01.solnet.ch [212.101.0.69]
18    43 ms    33 ms    40 ms  d11sol-bbr01.solnet.ch [212.101.0.70]
19    32 ms    32 ms    32 ms  d11sol-dgr01.solnet.ch [212.101.0.169]
20    32 ms    32 ms    31 ms  ds1789932.dedicated.solnet.ch [82.220.2.33]
Trace complete.

As you appear to be located on the US West Coast, you're connection is probably trundling along through the Southern states, popping out at New York or maybe Stamford before a swim across the Atlantic and then on to Switzerland. Or worse, you could be being routed via APAC to Europe...

You may find there's a bad or slow connection somewhere between you and the OpenELEC server, in which case you'll probably need to contact your ISP if the problem doesn't resolve itself.
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.
#27
Hi,

Doesn't look good...

C:\WINDOWS\system32>tracert 82.220.2.33

Tracing route to ds1789932.dedicated.solnet.ch [82.220.2.33]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms router.local [192.168.1.1]
2 7 ms 8 ms 9 ms 7.229.106.129
3 13 ms 13 ms 15 ms 69.63.242.5
4 15 ms 12 ms 9 ms 64.71.241.97
5 22 ms 22 ms 22 ms v635.core1.tor1.he.net [209.51.163.213]
6 31 ms 24 ms 21 ms 100ge1-2.core1.nyc4.he.net [184.105.80.9]
7 98 ms 91 ms 100 ms 100ge13-1.core1.par2.he.net [184.105.81.78]
8 105 ms 110 ms 106 ms 10ge3-2.core1.zrh1.he.net [184.105.222.50]
9 104 ms 113 ms 104 ms swissix-1.solnet.ch [91.206.52.14]
10 115 ms 105 ms 115 ms iwbbas-bbr01.solnet.ch [212.101.0.73]
11 106 ms 106 ms 114 ms d11sol-bbr02.solnet.ch [212.101.0.89]
12 106 ms 107 ms 107 ms d11sol-dgr01.solnet.ch [212.101.0.169]
13 107 ms 107 ms 108 ms ds1789932.dedicated.solnet.ch [82.220.2.33]

Trace complete.

C:\WINDOWS\system32>
#28
To be honest 110ms from the west coast USA via the Atlantic to Switzerland isn't at all shabby, are you sure you're not simply seeing packet loss?

Although other than discussing this, there's really nothing I can do as I have no control over the server infrastructure, and as far as I can tell it's working fine - has this problem started only recently? Maybe others can chime in if they're also having slow download problems, or if any other US-based users are *not* having download problems.

Maybe it's something to do with whoever is taking a pair of shears to telecommunications fibre in your locale...
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.
#29
(2015-07-08, 02:13)Milhouse Wrote: To be honest 110ms from the west coast USA via the Atlantic to Switzerland isn't at all shabby, are you sure you're not simply seeing packet loss?

Although other than discussing this, there's really nothing I can do as I have no control over the server infrastructure, and as far as I can tell it's working fine - has this problem started only recently? Maybe others can chime in if they're also having slow download problems, or if any other US-based users are *not* having download problems.

Maybe it's something to do with whoever is taking a pair of shears to telecommunications fibre in your local...

Hi,

This started to happen 2 days ago. Until then, I had very good download speed while downloading from your host.

Right when you dropped support to PVR. When I tried to download "the fix" yesterday I realized my new speed.

If I am the only one with this issue- sorry....

I still will download your builds and testSmile

Keep up the good work, here man...

Cheers.
#30
Hi Milhouse,
I am having same issues like mp1111 and i am located in Canada. This all started from last two days....not sure whyHuh
  •   
  • 1
  • 2(current)
  • 3
  • 4
  • 5
  • 168
  •   
  Thread Closed
 
Thread Rating:
  • 10 Vote(s) - 5 Average



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