[SOLVED] KODI Krypton - 17.x MediaPlayer - Optimized for Raspberry Pi1/Pi2/Pi3 on Slackware ARM 14.2 SF & Slackware ARM - current HF

abga · 03-09-2018, 01:36 AM

I don't know yet if my suggestions from the previous post resolved your "looks kind of washed out" issue regarding the Desktop and Kodi, but I'd like to update this thread with some info about the color depth on the Raspberry Pi boards.

Some years ago, by the time I started using the Raspberry Pi boards, the 16bit color depth (high color ~ 65k) was the default/recommended value and the 24bit color depth (true color ~ 16 million) was broken due to some firmware issues. Using the 32bit color depth was not recommended because of the higher memory usage and the performance impact. A more recent thread where the 32bit color depth is not encouraged by the Raspberry Foundation:
https://www.raspberrypi.org/forums/v...c.php?t=108033
16 bit color depth looks indeed washed out and the 24bit (~ 16 million) is a little over the biological color perception limit of the eyes, which is a little over 10 million. Pushing the 32bit color depth doesn't really make sense for watching media content, 24 bit should suffice.

Meanwhile I got used with the limited 16bit color depth and forgot to check if the 24bit color depth is fixed or still broken. Now that stormtracknole reported his poor image quality, I just considered to check it again and I was successful in enabling this 24bit color depth on a Raspberry Pi Zero, running Slackware ARM 14.2, with the official Raspberry Pi kernel 4.4.50+ (and the firmware that comes with it) and only allocating 128MB for the GPU. I haven't noticed any apparent performance impact and I'm able to play full HD streams even at 50fps without frame drops and not using more than 75% of the GPU RAM.

- these are the /boot/config.txt options I'm using now for Kodi 17.4 on the Pi0:

Code:

gpu_mem=128
framebuffer_depth=24
#disabled the ignore_alpha option as it is only needed for the 32bit color depth
#framebuffer_ignore_alpha=1

stormtracknole · 03-09-2018, 06:35 AM

Yes, I was able to figure out shortly after I made my post. I figured that it had something to do with config.txt. Since this is a raspberry pi 3, I went ahead with using framebuffer_depth=32 and framebuffer_ignore_alpha=1 with no issues. I figure that framebuffer_depth=24 should be at least the default setting. Felt like it was Windows 95 for a while there.

abga · 03-10-2018, 04:09 AM

There is a FAQ page on Kodi dedicated solely for the Raspberry Pi boards, that was updated recently and contains a lot of very useful information. Since I cannot edit my original guide anymore, I'll use this post to update the thread:
https://kodi.wiki/view/Raspberry_Pi_FAQ

I found these recommended GPU Memory setting really important:
https://kodi.wiki/view/Raspberry_Pi_...ith_256M_Pi.29
"320M on a Pi2 may be appropriate if using higher resolution imageres/fanartres and also higher colour."

To check the health/load/memory usage (including GPU) on the Raspberry Pi boards while running Kodi (general usage too), the following script is very useful:
https://github.com/MilhouseVH/bcmstat

Code:

wget https://raw.githubusercontent.com/MilhouseVH/bcmstat/master/bcmstat.sh
chmod +x bcmstat.sh
./bcmstat.sh A

In order to protect the SDCard from some intensive storage operations Kodi is doing, I'd suggest to create a RAM filesystem and use it to store the files Kodi is hammering the Card with. I don't know where Kodi is storing the artwork/fanart, since I'm not using this feature, but I've noticed that the database files in .kodi/userdata/Database are really busy. I took them from there and archived them, leaving only a symlink to the Database folder pointing to a tmpfs drive /attic , where I unpack them on system boot - rc.local and archive them back and store on system down/restart - rc.6
Here's my fstab related entry - just for inspiration:

Code:

tmpfs            /attic        tmpfs       nodev,nosuid,noatime,nodiratime,size=100M 0 0

stormtracknole · 08-28-2018, 10:21 AM

abga,

I've been meaning to post this for a while, wanted to pass along that I was able to get tinyxml to build. There is a slight change in the SBo that needs to be made. I'm using the SlackBuild from slackbuilds.org.

Here's the portion of the code in question:

Code:

if [ "$ARCH" = "i486" ]; then
  SLKCFLAGS="-O2 -march=i486 -mtune=i686"
  LIBDIRSUFFIX=""
elif [ "$ARCH" = "i686" ]; then
  SLKCFLAGS="-O2 -march=i686 -mtune=i686"
  LIBDIRSUFFIX=""
elif [ "$ARCH" = "x86_64" ]; then
  SLKCFLAGS="-O2 -fPIC"
  LIBDIRSUFFIX="64"
else
  SLKCFLAGS="-O2"
  LIBDIRSUFFIX=""
fi

Because it's arm, it will default to the last option which does not include -fPIC in the SLKCFLAGS section. I modified mine to look like this:

Code:

if [ "$ARCH" = "i486" ]; then
  SLKCFLAGS="-O2 -march=i486 -mtune=i686"
  LIBDIRSUFFIX=""
elif [ "$ARCH" = "i686" ]; then
  SLKCFLAGS="-O2 -march=i686 -mtune=i686"
  LIBDIRSUFFIX=""
elif [ "$ARCH" = "x86_64" ]; then
  SLKCFLAGS="-O2 -fPIC"
  LIBDIRSUFFIX="64"
else
  SLKCFLAGS="-O2 -fPIC"
  LIBDIRSUFFIX=""
fi

That made the code happy and tinyxml compiled without issues.

abga · 08-28-2018, 01:48 PM

Thanks for the update stormtracknole!

You're right, the compilation fails on Slackware ARM -current without -fPIC and I guess it's because of the new gcc-8.2.0.

Code:

/usr/bin/ld: tinyxml.o: relocation R_ARM_MOVW_ABS_NC against `a local symbol' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: tinyxmlerror.o: relocation R_ARM_MOVW_ABS_NC against `a local symbol' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: tinyxmlparser.o: relocation R_ARM_MOVW_ABS_NC against `a local symbol' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: tinyxml.o(.text+0x198): unresolvable R_ARM_CALL relocation against symbol `fwrite@@GLIBC_2.4'
/usr/bin/ld: final link failed: nonrepresentable section on output
collect2: error: ld returned 1 exit status

It still works on Slackware ARM 14.2 stable gcc-5.5.0 with or without -fPIC, however, it's safer to always modify the SlackBuild and add the -fPIC as you suggested.

I cannot edit my post #9 anymore, sorry.

stormtracknole · 08-28-2018, 04:54 PM

Quote:

Originally Posted by abga

Thanks for the update stormtracknole!

You're right, the compilation fails on Slackware ARM -current without -fPIC and I guess it's because of the new gcc-8.2.0.

Code:

/usr/bin/ld: tinyxml.o: relocation R_ARM_MOVW_ABS_NC against `a local symbol' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: tinyxmlerror.o: relocation R_ARM_MOVW_ABS_NC against `a local symbol' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: tinyxmlparser.o: relocation R_ARM_MOVW_ABS_NC against `a local symbol' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: tinyxml.o(.text+0x198): unresolvable R_ARM_CALL relocation against symbol `fwrite@@GLIBC_2.4'
/usr/bin/ld: final link failed: nonrepresentable section on output
collect2: error: ld returned 1 exit status

It still works on Slackware ARM 14.2 stable gcc-5.5.0 with or without -fPIC, however, it's safer to always modify the SlackBuild and add the -fPIC as you suggested.

I cannot edit my post #9 anymore, sorry.

Yes, this was on -current but good to know that it works fine on 14.2. Also wrote a SlackBuild based on your suggestions for the hardware accelerated version of ffmpeg and kodi too. Makes creating a package easier.

abga · 08-28-2018, 05:41 PM

Quote:

Originally Posted by stormtracknole

Yes, this was on -current but good to know that it works fine on 14.2. Also wrote a SlackBuild based on your suggestions for the hardware accelerated version of ffmpeg and kodi too. Makes creating a package easier.

I was also considering writing a generic Raspberry-focused SlackBuild for Kodi, but I needed to cover 3 platforms (Pi1/0,Pi2B,Pi3B), the dependencies for these platforms, two Slackware versions (Slackware ARM 14.2 armv6 SF and Slackware ARM -current armv7 HF), the FFMpeg compilation - that should actually be the subject of the Kodi build scripts (had no time to read and understand those quite complex internal Kodi build scripts and why are they failing on Slackware) and then there is an issue with the JDK7 for armv6 (Pi1/0), there's nowhere I could find it online anymore. OpenJDK might work too, never tried it, I just fear that it'll take ages to get it compiled on a Pi1/0.
Covering the different platforms and the dependencies could be achieved with some conditional checking in the script, but it'll get pretty complex and the guide from post #1, together with the updates from this thread, are maybe the more appropriate solution. TBH with you I'm also using the stuff I posted here for my own needs, always knowing where to find what I need when building FFMpeg+Kodi for Raspberry under Slackware ARM

stormtracknole · 08-28-2018, 06:15 PM

Quote:

Originally Posted by abga

I was also considering writing a generic Raspberry-focused SlackBuild for Kodi, but I needed to cover 3 platforms (Pi1/0,Pi2B,Pi3B), the dependencies for these platforms, two Slackware versions (Slackware ARM 14.2 armv6 SF and Slackware ARM -current armv7 HF), the FFMpeg compilation - that should actually be the subject of the Kodi build scripts (had no time to read and understand those quite complex internal Kodi build scripts and why are they failing on Slackware) and then there is an issue with the JDK7 for armv6 (Pi1/0), there's nowhere I could find it online anymore. OpenJDK might work too, never tried it, I just fear that it'll take ages to get it compiled on a Pi1/0.
Covering the different platforms and the dependencies could be achieved with some conditional checking in the script, but it'll get pretty complex and the guide from post #1, together with the updates from this thread, are maybe the more appropriate solution. TBH with you I'm also using the stuff I posted here for my own needs, always knowing where to find what I need when building FFMpeg+Kodi for Raspberry under Slackware ARM

I think I would just support -current and rpi3.

That IS a lot of work. I don't see why it wouldn't work on rpi2. I wouldn't try to compile software on the other platforms as I don't think they have the horse power for that.

abga · 08-28-2018, 07:41 PM

Quote:

Originally Posted by stormtracknole

I wouldn't try to compile software on the other platforms as I don't think they have the horse power for that.

Oh, they do! The Pi Zero for instance is a wonderful little toy for Kodi, well, without the fancy artwork that you like so much.
For 5EUR (plus 5EUR the case and 5EUR the Ethernet adapter), that's 15EUR, I have a multimedia system under my desk, providing me with "ambient" music, satellite radio, news, DVB playback (1080p 50Hz) + whatever I imagine as multimedia needs. Security-wise it's isolated from my work network, so I don't mind if anyone is hacking it (Kodi). It has an uptime for some months now and Kodi is always running.
Installing Slackware ARM, compiling FFMpeg + deps + Kodi takes around 4 hours on a Pi Zero.
https://www10.zippyshare.com/v/LH9W58P1/file.html
(the audio+ir is built upon a PATA 40 pin female connector that I just attach to the Pi0 board, the whole system sits on the top of the woofer - a perfect place to put electronics, especially connectors, the high intensity low band vibrations are definitely beneficial - Don't Do It At Home!

)

P.S.
And, I don't need a dust sucker under my desk. If they don't consider doing something with the SoC on the upcoming Raspberry Pi 4, maybe using some lower frequency octa-core that doesn't need active cooling, then it's game over for me...
https://www.raspberrypi.org/blog/int...ernet-poe-hat/

stormtracknole · 08-28-2018, 08:20 PM

Quote:

Originally Posted by abga

Oh, they do! The Pi Zero for instance is a wonderful little toy for Kodi, well, without the fancy artwork that you like so much.
For 5EUR (plus 5EUR the case and 5EUR the Ethernet adapter), that's 15EUR, I have a multimedia system under my desk, providing me with "ambient" music, satellite radio, news, DVB playback (1080p 50Hz) + whatever I imagine as multimedia needs. Security-wise it's isolated from my work network, so I don't mind if anyone is hacking it (Kodi). It has an uptime for some months now and Kodi is always running.
Installing Slackware ARM, compiling FFMpeg + deps + Kodi takes around 4 hours on a Pi Zero.
https://www10.zippyshare.com/v/LH9W58P1/file.html
(the audio+ir is built upon a PATA 40 pin female connector that I just attach to the Pi0 board, the whole system sits on the top of the woofer - a perfect place to put electronics, especially connectors, the high intensity low band vibrations are definitely beneficial - Don't Do It At Home!

)

P.S.
And, I don't need a dust sucker under my desk. If they don't consider doing something with the SoC on the upcoming Raspberry Pi 4, maybe using some lower frequency octa-core that doesn't need active cooling, then it's game over for me...
https://www.raspberrypi.org/blog/int...ernet-poe-hat/

Well how about that? I didn't know they were that powerful. I may have to grab one to play around with. I already have like 6 raspberry pi's and one orange pi.

abga · 08-28-2018, 08:50 PM

Have a look here:
https://www.youtube.com/watch?v=Q8GZr2fyUY0
It's showing Kodi 16 on Pi Zero and I can confirm that Kodi 17 is working fine on it too. He has some good points in the video, telling that it's usable if you know what you want and don't play around too much back and forth through the menus. I'm keeping the UI lightweight, no artwork, no fancy visualization add-ons, just the basics/defaults. You'll need the Oracle JDK7 for armv6 SF (the links from post #1 expired) if you want to go through the Kodi compilation&installation and I'll be able to upload it for you if you need it, just let me know.
I did provide some wrong info about the performance of the Pi Zero in my first post and I'm sorry for that, at that time I was not sure if the Pi Zero is powerful enough to play DVB streams in FullHD at 50fps (they're the most demanding) by also outputting analogue audio over the audio schematics that I cloned from the Raspberry Pi3B by using the OMX acceleration/player. It works well, but you'll need to build that sound adapter on your own and connect it to the GPIO (get/reroute the PWM streams from the SoC). Getting the digital audio out on HDMI has no performance impact, it should work with both OMX/MMAL, OMX being way more efficient. It's definitely not powerful enough for playing DVB streams in FullHD at 50fps by using and external USB sound card and the MMAL acceleration, it drops frames and finally freezes.
I'm also not very pleased by the quality/performance of the onboard WiFi adapter that comes with the Raspberry Pi0 W, therefore I opted for the simple Pi0 and bought external USB Ethernet adapters (5-6EUR/USD).