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 - popcornmix - 2014-02-19

(2014-02-19, 22:49)allan87 Wrote: 256M was the stock setting in the config.txt file of my first install, and I was not aware that it was not optimal. What are the disadvantages of 256? I have checked available CPU memory from time to time and always found plenty of free RAM. Would a setting somewhere in between 128 and 256 make sense (especially if one is running test builds)?

To be honest on a 512M Pi, it doesn't make a lot of difference if gpu_mem is set to 128M or 256M. For most uses memory is not an issue.
You might want more than 128M on GPU if playing level 5.1 1080p H.264 with 16 reference frame, or using heavy skins with the artwork resolution turned up.
You might want more than 256M on ARM if you are running lots of plugins, a torrent client and are streaming video with a big cache set up.

But for most users you'll be fine either way. (In fact I have gpu_mem=256 on my home setup).


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - MrNice - 2014-02-19

(2014-02-19, 20:26)popcornmix Wrote:
(2014-02-19, 18:46)MrNice Wrote: If I set-up 2.0, I have output 2.0 with PCM 6 Channels files and 5 Channels output with DTS/AC3 files (I have 5.0 speakers)
If I set-up 5.0, I have output 5.0 output with all files
AVR displays the right format: DTS, DD or MULTI IN

If changing the speaker layout has an effect then I don't believe you are using passthrough.
Post a debug log after playing a file that should use passthough to see what's happening.

Passthrough ON

Files are PCM MCH
Please find the first log here
You could notice;
- After switching on Pi I tried to play one file but I had no sound at all. I had to change the video resolution from 720 to 1050 and sound want back. This occur very often when I start the device. I didn't post about that so far. (if you can read why this issue could be good)
- First I played 1 file with 5.0 config
- Second I played 2 files with 2.0 config

File is AC3
The second log here
- I did a reboot and I had to change the resolution to 720 to get sound
- First I played 1 file with 5.0 config
- Second I played 1 file with 2.0 config

Don't hesitate to tell me any issue you could notice.
Hope this will help


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - popcornmix - 2014-02-19

(2014-02-19, 23:02)MrNice Wrote: Files are PCM MCH
Please find the first log here
You could notice;
- After switching on Pi I tried to play one file but I had no sound at all. I had to change the video resolution from 720 to 1050 and sound want back. This occur very often when I start the device. I didn't post about that so far. (if you can read why this issue could be good)
- First I played 1 file with 5.0 config
- Second I played 2 files with 2.0 config

File is AC3
The second log here
- I did a reboot and I had to change the resolution to 720 to get sound
- First I played 1 file with 5.0 config
- Second I played 1 file with 2.0 config

First log is a wav file with PCM. Only DTS and AC3 support passthough, so this doesn't use passthrough. Therefore speaker configuration does have an effect.
Second log is AC3 audio. Passthough is correctly being used. Therefore you will have multichannel audio whether speaker configuration is set to 2.0 or 5.0.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - MrNice - 2014-02-19

So to conclude, as I play PCM MCH, DTS and AC3 files I have to always set-up 5.0 to get full audio.
Do you agree?


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - popcornmix - 2014-02-19

(2014-02-19, 23:20)MrNice Wrote: So to conclude, as I play PCM MCH, DTS and AC3 files I have to always set-up 5.0 to get full audio.
Do you agree?

Yes. omxplayer and your equipment support mulitchannel PCM, so setting speaker configuration to 5.0 is correct.

dvdplayer/papalyer don't (yet) support multichannel PCM, so you may need to disable it for those. I'm hoping to support that soon.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Jönke - 2014-02-20

(2014-02-19, 20:54)popcornmix Wrote:
(2014-02-19, 20:51)Jönke Wrote: With deinterlace disabled
sdtv, less or none dropping frames & cpu 60-70%
hdtv, only black screen with sound

Any errors in log?
What is gpu_mem set to? Can you try increasing it?

Was on 128 and changed to 256 and sd tv seems to work better but 1080i livetv/recording still black screen (only sound)
Here is a sample that plays with omxplayer but not dvdplayer https://www.dropbox.com/s/lh15yu1zkbuzj9x/Steve%20Irwin%27s%20Wildlife%20Warriors.2014-02-19.E18.mkv


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - thomasthetomcat - 2014-02-20

I have the same problem using dvdplayer to watch .mkv files with high bitrates.
Lower bitrates work fine, but higher materials cause laggs (in picture and sound) and frame dropping. And at the beginning I see a black screen and only hear the sound. Then the picture appears and fast-forward until it reaches the position where the sound already is.

Omxplayer works without problems.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - delinend - 2014-02-20

Thanks Milhouse, for updating to lcdproc-0.5.7-cvs20140217, in your last build.

Now my HD44780 LCD/Display via Rpi/GPIO works out-of-the-box in Gotham, without driver change :-)


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - tfouto - 2014-02-20

(2014-02-19, 22:54)popcornmix Wrote:
(2014-02-19, 22:49)allan87 Wrote: 256M was the stock setting in the config.txt file of my first install, and I was not aware that it was not optimal. What are the disadvantages of 256? I have checked available CPU memory from time to time and always found plenty of free RAM. Would a setting somewhere in between 128 and 256 make sense (especially if one is running test builds)?

To be honest on a 512M Pi, it doesn't make a lot of difference if gpu_mem is set to 128M or 256M. For most uses memory is not an issue.
You might want more than 128M on GPU if playing level 5.1 1080p H.264 with 16 reference frame, or using heavy skins with the artwork resolution turned up.
You might want more than 256M on ARM if you are running lots of plugins, a torrent client and are streaming video with a big cache set up.

But for most users you'll be fine either way. (In fact I have gpu_mem=256 on my home setup).

popcornmix,

How safe can we increase memory gpu_mem? 300?


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - popcornmix - 2014-02-20

(2014-02-20, 10:55)tfouto Wrote: How safe can we increase memory gpu_mem? 300?

If you want, but unless you are seeing OMX errors in the log, it won't make any difference.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - doveman2 - 2014-02-20

As well as the avis I previously referred to, I find dvdplayer can't skip forward in streaming video either, so I'm having to use omxplayer for most things at the moment.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - dhead - 2014-02-20

(2014-02-12, 21:16)dhead Wrote:
(2014-02-12, 15:17)doveman2 Wrote: Regarding the issue where the remote volume keys don't repeat, which is apparently an OS-level bug as XBMC doesn't do the repeating itself but relies on the OS to handle this, I wonder if this workaround for Ubuntu can be used with OE?

Raspberry Pi builds doesn't include X.org so this is no go (and this solution only works for keyboards and not for keypress send by lirc).
From a quick googling I guess your remote recognized as keyboard.

Sadly the current state of keyboard support in XBMC is a bit of a mess, with the Raspberry Pi XBMC gets scancodes from the kernel, on OpenELEC x86_64 and i686 from X.Org and on regular Linux distribution from SDL, this is true for Frodo and Gotham.
I've already encountered with the issue you described and more but I didn't thought it worth reporting as the whole keyboard situation seems to me very funny and with Wayland soon on my desktop (Gnome 3.12 next month) I probably will have more issues.

I've been doing a little more testing and I think I know how to solve this.

If I understand correctly when you hold the VolumeUp button the remote send a button hold event and when released the remote sends a release event.
When you hold another button like a "K" the remote will send a press key event (hold and release ?) and repeat again (with some delay) and again until you release the button.

I think that maybe XBMC is relying on SDL and X11 to convert "hold" and "release" events when there is a large delay between them (the button is held) to continuously repeats.
On the Raspberry where no SDL and X11 are use, XBMC gets events from the kernel which doesn't do this conversion.

I'm not sure if it is a good idea to have this issue solved in XBMC, probably better to solve it in external app.
The best suiteable candidate is eventlircd but we will need to code in this feature.
My coding skills are lacking but this is surely my do-it list.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - doveman2 - 2014-02-20

(2014-02-20, 14:29)dhead Wrote: I've been doing a little more testing and I think I know how to solve this.

If I understand correctly when you hold the VolumeUp button the remote send a button hold event and when released the remote sends a release event.
When you hold another button like a "K" the remote will send a press key event (hold and release ?) and repeat again (with some delay) and again until you release the button.

I wouldn't have thought there's any difference with the remote as to what it sends when holding a button, so I imagine it sends the same sort of command whether I'm holding VolumeUp or the down button on the d-pad. The latter repeats in XBMC whilst the former doesn't though, so I guess the kernel must be doing something different when it sees that VolumeUp/Down is being pressed compared to the other keys and not sending repeats to XBMC.

If this is the case, perhaps a workaround would be to remap the VolumeUp/Down keys at/before the kernel level, so it sees them as normal keys/scancodes that it does send repeats for and then at the XBMC level, map these keys/scancodes to the Volume commands?


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - dhead - 2014-02-20

(2014-02-20, 16:32)doveman2 Wrote:
(2014-02-20, 14:29)dhead Wrote: I've been doing a little more testing and I think I know how to solve this.

If I understand correctly when you hold the VolumeUp button the remote send a button hold event and when released the remote sends a release event.
When you hold another button like a "K" the remote will send a press key event (hold and release ?) and repeat again (with some delay) and again until you release the button.

I wouldn't have thought there's any difference with the remote as to what it sends when holding a button, so I imagine it sends the same sort of command whether I'm holding VolumeUp or the down button on the d-pad. The latter repeats in XBMC whilst the former doesn't though, so I guess the kernel must be doing something different when it sees that VolumeUp/Down is being pressed compared to the other keys and not sending repeats to XBMC.

If this is the case, perhaps a workaround would be to remap the VolumeUp/Down keys at/before the kernel level, so it sees them as normal keys/scancodes that it does send repeats for and then at the XBMC level, map these keys/scancodes to the Volume commands?

The kernel is too "stupid" to do this distinction (I'm not a developer but this distinction should be do in userspace not in the kernel).
This can't be solved by remapping the scancodes to other keycodes in the kernel with hwdb.d, I already tried it, See https://wiki.archlinux.org/index.php/Map_scancodes_to_keycodes

I believe the repeats (and delays) are implemented by the mcu in the keyboard and got nothing to do with the OS.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - doveman2 - 2014-02-20

(2014-02-20, 16:49)dhead Wrote: [The kernel is too "stupid" to do this distinction (I'm not a developer but this distinction should be do in userspace not in the kernel).
This can't be solved by remapping the scancodes to other keycodes in the kernel with hwdb.d, I already tried it, See https://wiki.archlinux.org/index.php/Map_scancodes_to_keycodes

I believe the repeats (and delays) are implemented by the mcu in the keyboard and got nothing to do with the OS.

OK. I wish there was some way to check for sure if the remote is not sending the volume buttons repeated unlike all the other buttons but I think Windows has too many layers of software in the way to easily find out exactly what it's doing.

Maybe the remote doesn't send repeats for any keys though and it's the OS that decides what to do when a key is held down (i.e between the Press signal and the Release signal) and the OS signals to XBMC when the other keys are held down and thus XBMC repeats the commands but it's not doing this for the Volume keys?


This forum uses Lukasz Tkacz MyBB addons.