Login at Kodi Home

**zaphod24** · 2015-07-06, 00:34

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.

evanspae · 2015-07-06, 12:36

+1

I understand the lack of ArgusTV support although not your problem, means I will have to revert to earlier version... Sad

Leopold · 2015-07-06, 20:10

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?

Milhouse · (This post was last modified: 2015-07-06, 20:53 by Milhouse.)

(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.

Heiko123 · 2015-07-06, 21:41

Thanks, I will be wait impatiently. Angel

Milhouse · 2015-07-06, 22:52

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:

Includes newclock4 patches
Excludes the OpenELEC fernetmenta patches due to conflicts with newclock4
Excludes the OpenELEC linux-01-RPi_support patch in favour of sourcing these and possibly more recent patches directly from kernel branch rpi-4.1.y
Default setting for "Show RSS Feed" changed to disabled (new installs only) [patch details]
Disabled "Total Duration" in Confluence (see build #0221 for details)
Includes latest dcadec master (2a9186e3, ahead +34)
Includes latest kodi-platform master (33b6390b, ahead +1)
Includes latest libcec master (7599a307, ahead +25)
Includes latest libnfs master (68941809, ahead +25)
Includes latest platform master (22e0f42b)
Includes latest addons: pvr.argustv (b9e2b289, +16), pvr.demo (40efb477, +7), pvr.dvblink (820a9383, +6), pvr.dvbviewer (1e1da026, +6), pvr.filmon (c4858f87, +6), pvr.hts (f5c5afb4, +15), pvr.iptvsimple (10626b4b, +6), pvr.mediaportal.tvserver (100d1dfe, +20), pvr.mythtv (db1d3cd0, +18), pvr.nextpvr (e4a2d794, +6), pvr.njoy (45c23808, +6), pvr.pctv (efa92a78, +6), pvr.stalker (506c16f3, +6), pvr.vbox (aba5a4af, +8), pvr.vdr.vnsi (7aace223, +6), pvr.vuplus (20edf9d9, +8), pvr.wmc (3907c8bd, +8)
Includes commits from shairplay/master, ahead +17 (juhovh)
Exclude ffmpeg-99.0011-mpeg4video-Signal-unsupported-GMC-with-more-than-one.patch: Ignore, as already in newclock4
Exclude kodi-999.20-PR7102.patch: Temporarily ignore dcadec settings and use newclock4 version
Exclude kodi-999.21-configure.ac-dont-break-if-dcadec-is-missing-dcadec-.patch: Temporarily ignore due to breakage
Include patch: Add experimental splash video
Include patch: Add ffmpeg dependency and includes for HEVC optimisations
Include patch: Enable Wolfson 8804 I2C module
Include patch: Enable pvr addons, disable PVR updates
Include PR:6919: added: also hide thumbs for unwatched episodes if option to show plot is off
Include PR:7093: [AirTunes] - features
Include PR:7384: [guilib] fixes and additions

Build Highlights:

PVR Add-ons are back, and should no longer update from online repositories (all other add-ons are unaffected)

Build Details:

OpenELEC:
- libinput: update to libinput-0.19.0 (e9b9e859)
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)
Additional commits/pull requests/changes not yet merged upstream:
- Added: patch: Enable pvr addons, disable PVR updates

**zaphod24** · 2015-07-07, 02:28

Hooray! MyPVR plugin is back and working well. Thanks Milhouse!!

Heiko123 · (This post was last modified: 2015-07-07, 21:23 by Heiko123.)

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.

Milhouse · 2015-07-07, 22:50

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:

Includes newclock4 patches
Excludes the OpenELEC fernetmenta patches due to conflicts with newclock4
Excludes the OpenELEC linux-01-RPi_support patch in favour of sourcing these and possibly more recent patches directly from kernel branch rpi-4.1.y
Default setting for "Show RSS Feed" changed to disabled (new installs only) [patch details]
Disabled "Total Duration" in Confluence (see build #0221 for details)
Includes latest dcadec master (2a9186e3, ahead +34)
Includes latest kodi-platform master (33b6390b, ahead +1)
Includes latest libcec master (7599a307, ahead +25)
Includes latest libnfs master (68941809, ahead +25)
Includes latest platform master (22e0f42b)
Includes latest addons: pvr.argustv (b9e2b289, +16), pvr.demo (40efb477, +7), pvr.dvblink (820a9383, +6), pvr.dvbviewer (1e1da026, +6), pvr.filmon (c4858f87, +6), pvr.hts (f5c5afb4, +15), pvr.iptvsimple (10626b4b, +6), pvr.mediaportal.tvserver (100d1dfe, +20), pvr.mythtv (db1d3cd0, +18), pvr.nextpvr (e4a2d794, +6), pvr.njoy (45c23808, +6), pvr.pctv (efa92a78, +6), pvr.stalker (506c16f3, +6), pvr.vbox (f7e02322, +14), pvr.vdr.vnsi (7aace223, +6), pvr.vuplus (20edf9d9, +8), pvr.wmc (3907c8bd, +8)
Exclude ffmpeg-99.0011-mpeg4video-Signal-unsupported-GMC-with-more-than-one.patch: Ignore, as already in newclock4
Exclude kodi-999.20-PR7102.patch: Temporarily ignore dcadec settings and use newclock4 version
Exclude kodi-999.21-configure.ac-dont-break-if-dcadec-is-missing-dcadec-.patch: Temporarily ignore due to breakage
Include patch: Add experimental splash video
Include patch: Add ffmpeg dependency and includes for HEVC optimisations
Include patch: Enable Wolfson 8804 I2C module
Include patch: Enable pvr addons, disable PVR updates
Include PR:6919: added: also hide thumbs for unwatched episodes if option to show plot is off
Include PR:7384: [guilib] fixes and additions

Build Highlights:

Bump libshairplay and AirTunes support

Build Details:

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)
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)
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)

mp1111 · 2015-07-08, 00:55

@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,

Milhouse · (This post was last modified: 2015-07-08, 01:35 by Milhouse.)

(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

   inet-router.local                                     0.733ms

   inet-router.local                                     0.563ms

   inet-router.local                                     0.499ms pmtu 1458

   no reply

   31.55.186.133                                        18.798ms asymm  5

   31.55.186.156                                        18.937ms

   195.99.127.38                                        18.968ms

   peer6-hu0-19-0-1.telehouse.ukcore.bt.net             18.485ms

   uk-lon01a-ri4-gi-3-0-2.aorta.net                     19.491ms

   nl-ams05a-rd2-xe-2-3-1.aorta.net                     40.450ms asymm 15

   uk-lon01a-ri4-ge-4-0-0.aorta.net                     38.746ms asymm 14

  84.116.134.65                                        37.250ms

  84.116.202.230                                       38.189ms

  62.179.20.18                                         40.744ms

  151.252.33.64                                        41.223ms asymm 11

  eq2zrh-bbr02.solnet.ch                               50.573ms asymm 13

  vtlzrh-bbr01.solnet.ch                               42.420ms asymm 14

  vtlolt-bbr01.solnet.ch                               43.362ms asymm 15

  vtlbrn-bbr01.solnet.ch                               43.881ms asymm 16

  d11sol-bbr01.solnet.ch                               43.526ms asymm 14

  d11sol-dgr01.solnet.ch                               42.838ms asymm 15

  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.

mp1111 · 2015-07-08, 01:32

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>

Milhouse · (This post was last modified: 2015-07-08, 02:23 by Milhouse.)

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...

mp1111 · 2015-07-08, 02:24

(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 test Smile

Keep up the good work, here man...

Cheers.

sunnyhero · 2015-07-08, 02:34

Hi Milhouse,
I am having same issues like mp1111 and i am located in Canada. This all started from last two days....not sure why Huh