Kodi Community Forum
OpenELEC Testbuilds for RaspberryPi Part 2 - Printable Version

Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Support (https://forum.kodi.tv/forumdisplay.php?fid=33)
+--- Forum: General Support (https://forum.kodi.tv/forumdisplay.php?fid=111)
+---- Forum: Raspberry Pi (https://forum.kodi.tv/forumdisplay.php?fid=166)
---- Thread: OpenELEC Testbuilds for RaspberryPi Part 2 (/showthread.php?tid=184866)



RE: OpenELEC Testbuilds for RaspberryPi Part 2 - bhamail - 2014-01-13

(2014-01-13, 00:03)MilhouseVH Wrote:
(2014-01-12, 04:28)bhamail Wrote: With the latest Milhouse Gotham build, I'm seeing repeated popups (every 10 seconds) with: Windows Media Center Client - linux arm Edition, Connection lost

Turns out that WMC being enabled by default may be a bug in XBMC and not the addon or OpenELEC.

Cool. Thanks for following up on this!


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - allan87 - 2014-01-13

I have found that if you delete addons.db, all of the PVR addons are activated on reboot and you get a ton of error messages. If you reboot again without changing any settings, it sorts itself out, however.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - popcornmix - 2014-01-13

(2014-01-12, 20:29)doveman2 Wrote: Checking my files, it seems that most of it is indeed 23.976fps, with my own TV recordings and iPlayer downloads being 25fps and DVDs 29.976fps. What I could do with MediaPortal is speed up the 23.976fps to 25fps and sync it with the TV running at 50hz and likewise with the 29.967fps DVDs, speed them up to 30fps and sync them with the TV running at 60hz, with MediaPortal able to switch the display/TV to the appropriate refresh rate, so I wonder if XBMC/OE can do something similar yet?

The 29.976->30 fps and 23.976->24 fps happens automatically bu adjustments to hdmi clock.

24->25 fps is too great for changing hdmi clock, and needs to be done by resampling audio. This cannot be done when passthrough is enabled.
It could in theory be done on the Pi when passthrough is not used, but I've never tried it.


No sound on Gotham builds - URBANsUNITED - 2014-01-13

Hi!

First of all:
Many thanks for all these great test builds and mods you bravely offer for the raspberry pi!
Thanks!

My problem:
Every build I try on Gotham base, has no sound in certain situations.
Means mkv files which have sound on Frodo, on Gotham they don’t have it.
And I also don’t have system sounds.
No matter what I choose in system->audio (2.0 or 5.1) I don’t have sound.
When I delete my guisettings.xml all files play nice with sound and I also have system sounds. But only till the next update.
Then I’ll have to delete the xml again.
Frodo didn’t had these issues.

I played with the bootloader files also already without success.

What is it? Any tricks for updating my system?

Thanks URBANsUNITED


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - botribun - 2014-01-13

@rbej

Could you please rename

OpenELEC-RPi.arm-Rbej-Version-Frodo-Branch(08.01.2014).tar

to

OpenELEC-RPi.arm-Rbej-Version-Frodo-Branch(07.01.2014).tar?

Because the DEV update addon is nagging continuously to update, sine the system version date is 07.01.2014 but you named it 08.01.2014 and this ends in a update loop.

http://www.openelec.tv/forum/128-addons/49855-addon-to-install-development-builds?start=180#95161

Or just release a new build without date/name mismatch. Smile

Thanks in advanced!


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - popcornmix - 2014-01-13

(2014-01-12, 13:52)popcornmix Wrote:
(2014-01-10, 14:25)popcornmix Wrote: dvdplayer doesn't currently support passthrough (it will play, but audio will be screetchy), so you will need to disable that for correct audio.
It may be worth testing if video keeps up with passthrough enabled, as it frees up some CPU.
Getting passthough working with paplayer/dvdplayer is something I am planning.

Add hdmi_stream_channels=1 to config.txt and that should fix passthrough.
AC3 was working fine for me but DTS was very slow.

To get ac3 and dts passthrough working from paplayer/dvdplater you want these in config.txt:
Code:
hdmi_stream_channels=1
no_hdmi_resample=1

Report back if passthrough works with dvdplayer, and whether this causes any issues with omxplayer.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Milhouse - 2014-01-14

New OpenELEC Gotham build: #0114 (obsolete)

Code:
rpi512:~ # uname -a
Linux rpi512 3.12.6 #1 PREEMPT Tue Jan 14 15:01:09 GMT 2014 armv6l GNU/Linux
rpi512:~ # vcgencmd version
Jan 10 2014 16:54:51
Copyright (c) 2012 Broadcom
version efa116b5c8859c352322cb27e13baccbea583ef7 (clean) (release)
rpi512:~ # lsb_release
OpenELEC_Gotham (Milhouse) - Version: devel-20140114151240-r16977-g7ba8f3a

Based on tip of XBMC master (fa6d90b, changelog) and tip of OpenELEC master (7ba8f3a, changelog) with the following modifications:
  • Includes newclock3 commits (except for a5460c0 which I've replaced with a static spinner)
  • Excludes the OpenELEC fernetmenta patches (due to conflict with newclock3)
This build includes newclock3 fixes for a few problems when playing high samplerate/multichannel/passthrough using the Pi audio sink which should now be improved.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - doveman2 - 2014-01-14

(2014-01-13, 14:40)popcornmix Wrote:
(2014-01-12, 20:29)doveman2 Wrote: Checking my files, it seems that most of it is indeed 23.976fps, with my own TV recordings and iPlayer downloads being 25fps and DVDs 29.976fps. What I could do with MediaPortal is speed up the 23.976fps to 25fps and sync it with the TV running at 50hz and likewise with the 29.967fps DVDs, speed them up to 30fps and sync them with the TV running at 60hz, with MediaPortal able to switch the display/TV to the appropriate refresh rate, so I wonder if XBMC/OE can do something similar yet?

The 29.976->30 fps and 23.976->24 fps happens automatically bu adjustments to hdmi clock.

24->25 fps is too great for changing hdmi clock, and needs to be done by resampling audio. This cannot be done when passthrough is enabled.
It could in theory be done on the Pi when passthrough is not used, but I've never tried it.

OK, thanks, that's good about the 29.976 >30 fps thing. I'll have to check how 23.976 >25 fps with MediaPortal looks compared to playing it on the RPi but I imagine it will help a lot with the judder I'm seeing, so if it could be added as an option on the RPi, that would be nice. I'm not using passthrough myself, just HDMI audio to my TV (which has an analog output, so I'll probably hook that up to an amp at some point for better sound quality).

In fact, I've just checked the manual and it seems my TV does support 1920x1080p/24hz and if I set this in XBMC the TV reports it's using that, so in theory I might be able to play my 24fps content OK if XBMC will upscale it from 480p to 1920x1080p. However, XBMC isn't switching resolution/hz at all at the moment and whatever resolution I set, that's what it stays on whatever is being played, so if I set it to [email protected], it stays on that when playing the 480p/23.976fps content.

I've noticed that the RPi defaults to RGB limited (can clearly be seen with the Black Clipping test pattern as even with brightness on max, nothing below 16 flashes and likewise with the White Clipping pattern, increasing Contrast doesn't make the bars above 235 change) but can be set to RGB Full with config.txt using hdmi_pixel_encoding=2 but I'm not sure if I should do this.

At the moment, if I change from [email protected] to 60hz it also forces the resolution to 1366x768 with a greyed out 60hz and there is a change in brightness. The TV supports [email protected] so I don't know why XBMC isn't allowing me to select it. The black menu background is greyish at [email protected] and changes to more of a proper black when it switches to 1366x768 but this appears to only be noticeable when I have the TV set to RGB Full and not if I switch it to RGB Normal, so what might be happening is that for some reason, the RPI is changing it's RGB output mode when switching to 1366x768. Obviously I can calibrate the TV so that black is black at 1280x720 but then it will be too dark at 1366x768 so I can only calibrate to one or the other and it would be helpful to be able to test different resolutions without the output levels changing like this.

With it set to 1920x1080 I can set it to 50 or 60hz no problem.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - popcornmix - 2014-01-14

(2014-01-14, 18:41)doveman2 Wrote: In fact, I've just checked the manual and it seems my TV does support 1920x1080p/24hz and if I set this in XBMC the TV reports it's using that, so in theory I might be able to play my 24fps content OK if XBMC will upscale it from 480p to 1920x1080p. However, XBMC isn't switching resolution/hz at all at the moment and whatever resolution I set, that's what it stays on whatever is being played, so if I set it to [email protected], it stays on that when playing the 480p/23.976fps content.

Have you enabled "Adjust display refresh rate to match video" in http://wiki.xbmc.org/index.php?title=Settings/Videos?

Upscaling from 480p->1080p is no problem, that is handled in hardware.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - doveman2 - 2014-01-14

(2014-01-14, 19:06)popcornmix Wrote: Have you enabled "Adjust display refresh rate to match video" in http://wiki.xbmc.org/index.php?title=Settings/Videos?

Upscaling from 480p->1080p is no problem, that is handled in hardware.

Doh, now I feel stupid Blush

You'll have to forgive me, my old TV only did 60hz so I never had any reason to enable this option and I'm still adjusting to my new TV Smile

So with the GUI set to [email protected], it does autoswitch to [email protected] when playing the [email protected] videos Big GrinBig Grin

If the GUI is set to [email protected] though, it switches to [email protected] and if it's set to 1366x768 it stays on that (the TV doesn't report a refresh rate at this resolution but I assume it's 60hz as that's what XBMC shows but greyed out).

If necessary, I'll just leave the GUI on 1920x1080. I'm still not sure if it would be better to use 1366x768 though (if it auto-switched in that mode that is) as it seems to make the GUI look nicer using that. I'm not sure if it's just because the picture gets less bright and so makes the blacks look better or if perhaps that is the closest match to the TV's native resolution (1024x768) and so it makes everything look sharper and more crisp (I think I see a bit more aliasing on the fonts in this resolution but it could be that it's just more noticeable because it's sharper). I can actually set it to 1024x768 and that looks equally crisp but as it's not a proper 16:9 resolution it makes things look wrong.

I'm also not seeing any change in size of the GUI when switching between 720 and 1080. The "Limit GUI res" is set to 1080 and I tried deleting that in case there was an extra character in there that was stopping it working (it reset itself back to 1080 when I deleted it). I thought it might just be something about the xTV-SAF skin I use, so I switched to Confluence but that's the same.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - popcornmix - 2014-01-14

(2014-01-14, 19:38)doveman2 Wrote: If the GUI is set to [email protected] though, it switches to [email protected] and if it's set to 1366x768 it stays on that (the TV doesn't report a refresh rate at this resolution but I assume it's 60hz as that's what XBMC shows but greyed out).
You will only get 24Hz from 1080p. 24Hz is not a standard for DMT resolutions (computer monitor resolutons like 1366x768). See http://elinux.org/RPi_config.txt for what is possible.
DMT typically uses full range RGB, whereas CEA uses limited range. You can force it with hdmi_pixel_encoding, but no guarantee your display will support full range for CEA or limited range for DMT.
It's shouldn't make any noticable difference as long as both ends (the Pi and display) are using the same standard.
Any difference is colours may just be down to different display settings on the TV (brightness/contrast etc).

(2014-01-14, 19:38)doveman2 Wrote: I'm also not seeing any change in size of the GUI when switching between 720 and 1080. The "Limit GUI res" is set to 1080 and I tried deleting that in case there was an extra character in there that was stopping it working (it reset itself back to 1080 when I deleted it). I thought it might just be something about the xTV-SAF skin I use, so I switched to Confluence but that's the same.

Changing guires requires a restart.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - doveman2 - 2014-01-14

(2014-01-14, 19:49)popcornmix Wrote: You will only get 24Hz from 1080p. 24Hz is not a standard for DMT resolutions (computer monitor resolutons like 1366x768). See http://elinux.org/RPi_config.txt for what is possible.
DMT typically uses full range RGB, whereas CEA uses limited range. You can force it with hdmi_pixel_encoding, but no guarantee your display will support full range for CEA or limited range for DMT.
It's shouldn't make any noticable difference as long as both ends (the Pi and display) are using the same standard.
Any difference is colours may just be down to different display settings on the TV (brightness/contrast etc).

Ah OK. I thought it would switch resolution automatically to whatever was needed to match the frame rate but if not that's cool, I'll just run at 1080p so that I get 24hz.

The TV settings aren't changing at all when switching resolution but switching between CEA/limited range and DMT/full range would explain it. I used to notice a similar thing with my previous CRT TV, when switching from 1920x1080 to 1280x720 it looked much sharper and the colours/blacks were stronger. That TV only supported 1080i though, so it was interlaced when using 1920x1080 and 1280x720 was more like it's native resolution.

Quote:Changing guires requires a restart.

Hmm, just tried that (with xTV-SAF) with it set to 1080p before rebooting and it still looks the same as when it's set to 720p.

I've noticed something's up with the Calibration screen as well, as the first upper-left corner marker appears massive and then the next bottom-right corner marker appears tiny!

Image


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Reddog999 - 2014-01-14

I've noticed quite a few errors in the xbmc.log lately:
Code:
01:00:15  15.944086 T:3043491840   ERROR: Open - failed to open source </storage/.xbmc/addons/packages/addon.xml>
01:00:15  15.962241 T:2964321360  NOTICE: Thread FileCache start, auto delete: false
01:00:16  16.254414 T:3043491840  NOTICE: Previous line repeats 12 times.
01:00:16  16.254414 T:3043491840   ERROR: Open - failed to open source </usr/share/xbmc/addons/library.xbmc.addon/addon.xml>
01:00:16  16.268419 T:3043491840   ERROR: Open - failed to open source </usr/share/xbmc/addons/library.xbmc.codec/addon.xml>
01:00:16  16.282127 T:3043491840   ERROR: Open - failed to open source </usr/share/xbmc/addons/library.xbmc.gui/addon.xml>
01:00:16  16.297934 T:3043491840   ERROR: Open - failed to open source </usr/share/xbmc/addons/library.xbmc.pvr/addon.xml>
01:00:16  16.316048 T:2964321360  NOTICE: Thread FileCache start, auto delete: false
01:00:17  17.684740 T:3043491840  NOTICE: Previous line repeats 50 times.
01:00:17  17.684740 T:3043491840   ERROR: Open - failed to open source </usr/lib/xbmc/addons/library.xbmc.addon/addon.xml>
01:00:17  17.699493 T:3043491840   ERROR: Open - failed to open source </usr/lib/xbmc/addons/library.xbmc.codec/addon.xml>
01:00:17  17.713551 T:3043491840   ERROR: Open - failed to open source </usr/lib/xbmc/addons/library.xbmc.gui/addon.xml>
01:00:17  17.727491 T:3043491840   ERROR: Open - failed to open source </usr/lib/xbmc/addons/library.xbmc.pvr/addon.xml>
01:00:17  17.743193 T:3043491840   ERROR: Open - failed to open source </usr/lib/xbmc/addons/pvr.argustv/addon.xml>
01:00:17  17.757483 T:3043491840   ERROR: Open - failed to open source </usr/lib/xbmc/addons/pvr.demo/addon.xml>
01:00:17  17.771393 T:3043491840   ERROR: Open - failed to open source </usr/lib/xbmc/addons/pvr.dvblink/addon.xml>
01:00:17  17.787148 T:3043491840   ERROR: Open - failed to open source </usr/lib/xbmc/addons/pvr.dvbviewer/addon.xml>
01:00:17  17.801014 T:3043491840   ERROR: Open - failed to open source </usr/lib/xbmc/addons/pvr.hts/addon.xml>
01:00:17  17.814926 T:3043491840   ERROR: Open - failed to open source </usr/lib/xbmc/addons/pvr.iptvsimple/addon.xml>
01:00:17  17.828918 T:3043491840   ERROR: Open - failed to open source </usr/lib/xbmc/addons/pvr.mediaportal.tvserver/addon.xml>
01:00:17  17.844658 T:3043491840   ERROR: Open - failed to open source </usr/lib/xbmc/addons/pvr.mythtv.cmyth/addon.xml>
01:00:17  17.858374 T:3043491840   ERROR: Open - failed to open source </usr/lib/xbmc/addons/pvr.nextpvr/addon.xml>
01:00:17  17.872190 T:3043491840   ERROR: Open - failed to open source </usr/lib/xbmc/addons/pvr.njoy/addon.xml>
01:00:17  17.887955 T:3043491840   ERROR: Open - failed to open source </usr/lib/xbmc/addons/pvr.vdr.vnsi/addon.xml>
01:00:17  17.901918 T:3043491840   ERROR: Open - failed to open source </usr/lib/xbmc/addons/pvr.vuplus/addon.xml>
01:00:17  17.915970 T:3043491840   ERROR: Open - failed to open source </usr/lib/xbmc/addons/pvr.wmc/addon.xml>
01:00:17  17.929823 T:3043491840   ERROR: Open - failed to open source </usr/lib/xbmc/addons/visualization.glspectrum/addon.xml>
01:00:17  17.945547 T:3043491840   ERROR: Open - failed to open source </usr/lib/xbmc/addons/visualization.waveform/addon.xml>
01:00:17  17.956192 T:3043491840  NOTICE: ADDONS: Using repository repository.xbmc.org
01:00:17  17.956942 T:3043491840  NOTICE: ADDONS: Using repository repository.openelec.tv
01:00:17  17.976540 T:2964321360  NOTICE: Thread FileCache start, auto delete: false
01:00:18  18.007965 T:3043491840   ERROR: Open - failed to open source </storage/.xbmc/userdata/addon_data/xbmc.debug/settings.xml>
01:00:18  18.008413 T:3043491840   ERROR: Open - failed to open source <special://profile/addon_data/xbmc.debug/settings.xml>

To cut a long story short, I first thought these were being caused by an addon but as it turned out it was an entry in my advancedsettings.xml, namely <buffermode>1</buffermode> - I should have caught on earlier with the reference to FileCache.
Anyway, setting the buffermode to anything other than 1 gets rid of the errors.

I realise these errors are probably benign but should they be present when applying a valid value for buffermode?

p.s. this is using Milhouse's 110c build.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - arnova - 2014-01-14

(2014-01-14, 20:34)Reddog999 Wrote: I've noticed quite a few errors in the xbmc.log lately:
Code:
01:00:15  15.944086 T:3043491840   ERROR: Open - failed to open source </storage/.xbmc/addons/packages/addon.xml>
01:00:15  15.962241 T:2964321360  NOTICE: Thread FileCache start, auto delete: false
01:00:16  16.254414 T:3043491840  NOTICE: Previous line repeats 12 times.
01:00:16  16.254414 T:3043491840   ERROR: Open - failed to open source </usr/share/xbmc/addons/library.xbmc.addon/addon.xml>
01:00:16  16.268419 T:3043491840   ERROR: Open - failed to open source </usr/share/xbmc/addons/library.xbmc.codec/addon.xml>
01:00:16  16.282127 T:3043491840   ERROR: Open - failed to open source </usr/share/xbmc/addons/library.xbmc.gui/addon.xml>
01:00:16  16.297934 T:3043491840   ERROR: Open - failed to open source </usr/share/xbmc/addons/library.xbmc.pvr/addon.xml>
01:00:16  16.316048 T:2964321360  NOTICE: Thread FileCache start, auto delete: false
01:00:17  17.684740 T:3043491840  NOTICE: Previous line repeats 50 times.
01:00:17  17.684740 T:3043491840   ERROR: Open - failed to open source </usr/lib/xbmc/addons/library.xbmc.addon/addon.xml>
01:00:17  17.699493 T:3043491840   ERROR: Open - failed to open source </usr/lib/xbmc/addons/library.xbmc.codec/addon.xml>
01:00:17  17.713551 T:3043491840   ERROR: Open - failed to open source </usr/lib/xbmc/addons/library.xbmc.gui/addon.xml>
01:00:17  17.727491 T:3043491840   ERROR: Open - failed to open source </usr/lib/xbmc/addons/library.xbmc.pvr/addon.xml>
01:00:17  17.743193 T:3043491840   ERROR: Open - failed to open source </usr/lib/xbmc/addons/pvr.argustv/addon.xml>
01:00:17  17.757483 T:3043491840   ERROR: Open - failed to open source </usr/lib/xbmc/addons/pvr.demo/addon.xml>
01:00:17  17.771393 T:3043491840   ERROR: Open - failed to open source </usr/lib/xbmc/addons/pvr.dvblink/addon.xml>
01:00:17  17.787148 T:3043491840   ERROR: Open - failed to open source </usr/lib/xbmc/addons/pvr.dvbviewer/addon.xml>
01:00:17  17.801014 T:3043491840   ERROR: Open - failed to open source </usr/lib/xbmc/addons/pvr.hts/addon.xml>
01:00:17  17.814926 T:3043491840   ERROR: Open - failed to open source </usr/lib/xbmc/addons/pvr.iptvsimple/addon.xml>
01:00:17  17.828918 T:3043491840   ERROR: Open - failed to open source </usr/lib/xbmc/addons/pvr.mediaportal.tvserver/addon.xml>
01:00:17  17.844658 T:3043491840   ERROR: Open - failed to open source </usr/lib/xbmc/addons/pvr.mythtv.cmyth/addon.xml>
01:00:17  17.858374 T:3043491840   ERROR: Open - failed to open source </usr/lib/xbmc/addons/pvr.nextpvr/addon.xml>
01:00:17  17.872190 T:3043491840   ERROR: Open - failed to open source </usr/lib/xbmc/addons/pvr.njoy/addon.xml>
01:00:17  17.887955 T:3043491840   ERROR: Open - failed to open source </usr/lib/xbmc/addons/pvr.vdr.vnsi/addon.xml>
01:00:17  17.901918 T:3043491840   ERROR: Open - failed to open source </usr/lib/xbmc/addons/pvr.vuplus/addon.xml>
01:00:17  17.915970 T:3043491840   ERROR: Open - failed to open source </usr/lib/xbmc/addons/pvr.wmc/addon.xml>
01:00:17  17.929823 T:3043491840   ERROR: Open - failed to open source </usr/lib/xbmc/addons/visualization.glspectrum/addon.xml>
01:00:17  17.945547 T:3043491840   ERROR: Open - failed to open source </usr/lib/xbmc/addons/visualization.waveform/addon.xml>
01:00:17  17.956192 T:3043491840  NOTICE: ADDONS: Using repository repository.xbmc.org
01:00:17  17.956942 T:3043491840  NOTICE: ADDONS: Using repository repository.openelec.tv
01:00:17  17.976540 T:2964321360  NOTICE: Thread FileCache start, auto delete: false
01:00:18  18.007965 T:3043491840   ERROR: Open - failed to open source </storage/.xbmc/userdata/addon_data/xbmc.debug/settings.xml>
01:00:18  18.008413 T:3043491840   ERROR: Open - failed to open source <special://profile/addon_data/xbmc.debug/settings.xml>

To cut a long story short, I first thought these were being caused by an addon but as it turned out it was an entry in my advancedsettings.xml, namely <buffermode>1</buffermode> - I should have caught on earlier with the reference to FileCache.
Anyway, setting the buffermode to anything other than 1 gets rid of the errors.

I realise these errors are probably benign but should they be present when applying a valid value for buffermode?

p.s. this is using Milhouse's 110c build.

I think I know where that's coming from. Will fix asap.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Reddog999 - 2014-01-14

(2014-01-14, 21:10)arnova Wrote:
(2014-01-14, 20:34)Reddog999 Wrote: I've noticed quite a few errors in the xbmc.log lately:
.......

To cut a long story short, I first thought these were being caused by an addon but as it turned out it was an entry in my advancedsettings.xml, namely <buffermode>1</buffermode> - I should have caught on earlier with the reference to FileCache.
Anyway, setting the buffermode to anything other than 1 gets rid of the errors.

I realise these errors are probably benign but should they be present when applying a valid value for buffermode?

p.s. this is using Milhouse's 110c build.

I think I know where that's coming from. Will fix asap.

Thank you.


This forum uses Lukasz Tkacz MyBB addons.