[Milhouse]

Hi milhouse,

thank you very much for guiding me in the right direction.

Crashlog uploaded: http://ix.io/1iO9

Savemode started after renaming the userdata folder to userdata.old.
Several autom. restarts (>15) did not trigger savemode before.

Chris

Check that you haven't run out of disk space - it looks like Kodi may be having trouble reading from, or writing to, /storage.

It looks like Safe Mode is starting, and writing out a fresh guisettings.xml, then crashing because it can't read the guisettings.xml file it has just created (possibly because the /storage file system is out of space).

[smp1]

@Milhouse
Did you have any trouble building with flatbuffers package? My build fails unless I remove flatbuffers.

Code:

[i][i][i][i][i]../include/flatbuffers/flatbuffers.h:1200:24: error: 'i' was not declared in this scope
../include/flatbuffers/flatbuffers.h:1200:52: error: there are no arguments to 'PushElement' that depend on a template parameter, so a declaration of 'PushElement' must be available [-fpermissive]
     for (auto i = len; i > 0;) { PushElement(v[--i]); }
                                                    ^
../include/flatbuffers/flatbuffers.h:1201:34: error: '>>' should be '> >' within a nested template argument list
     return Offset<Vector<Offset<T>>>(EndVector(len));
                                  ^
../include/flatbuffers/flatbuffers.h:1201:51: error: there are no arguments to 'EndVector' that depend on a template parameter, so a declaration of 'EndVector' must be available [-fpermissive]
     return Offset<Vector<Offset<T>>>(EndVector(len));
                                                   ^
../include/flatbuffers/flatbuffers.h: At global scope:
../include/flatbuffers/flatbuffers.h:1212:3: error: expected unqualified-id at end of input
   }
   ^
../include/flatbuffers/flatbuffers.h:1212:3: error: expected '}' at end of input
ninja: build stopped: subcommand failed.
Makefile:9: recipe for target 'release' failed
make: *** [release] Error 1
## BUILD FINISHED: Tue Jul 31 09:08:12 MSK 2018
## BUILD DURATION: 6663 seconds[/i][/i][/i][/i][/i]

[ktfzone]

@ktfzone is you pi3 a pi3b or pi3b+?
If its "+" enable "flow control" on the port your pi3 is connected to.

 I tried that, it appeared to make things worse. Plus the buffering happened on a RPI2 that worked flawlessly with the exact same movie a couple of months ago, I don't remember on what version I was back then. I will try to install 17.3 on a different card  and see how it goes. I never saw the buffering stuff in the past , nor should I, all my stuff is on local LAN.

[Milhouse]

@Milhouse
Did you have any trouble building with flatbuffers package? My build fails unless I remove flatbuffers.

No build issues right now - I just did 6 clean builds (RPi/RPi2/Generic, current kernel and 4.18-rc7) that included the flatbuffers package and no build issues. Note that I haven't been including https://github.com/xbmc/xbmc/pull/14209 since #0727 due to rebase issues (which might be resolved now, will try building it again later). I'll try building in a plain VM too.

[popcornmix]

 I tried that, it appeared to make things worse. Plus the buffering happened on a RPI2 that worked flawlessly with the exact same movie a couple of months ago, I don't remember on what version I was back then. I will try to install 17.3 on a different card  and see how it goes. I never saw the buffering stuff in the past , nor should I, all my stuff is on local LAN. 

See if you can identify an older build that works correctly. If you can't it will be something on your network.
I once had terrible network performance. I found I'd configured a device with a static IP address that collided with the DHCP one of the device with the problem.
A dodgy ethernet lead could also be causing this.

Try disconnecting other devices from network and swap ethernet cables.

Another possibility is it's a problem on the server hosting the files.

[Milhouse]

@Milhouse
Did you have any trouble building with flatbuffers package? My build fails unless I remove flatbuffers.

No build issues right now - I just did 6 clean builds (RPi/RPi2/Generic, current kernel and 4.18-rc7) that included the flatbuffers package and no build issues. Note that I haven't been including https://github.com/xbmc/xbmc/pull/14209 since #0727 due to rebase issues (which might be resolved now, will try building it again later). I'll try building in a plain VM too.

@smp1 I get this build failure when building the flatbuffers package in a minimalist Ubuntu 16.04 VM: http://ix.io/1iQt, but no problems with my normal Ubuntu 17.10 build machine. Hmmm.

Edit: this is the initial error http://ix.io/1iQy - after that it just logs thousands upon thousands of errors from the flatbuffer package. Not sure what would cause this difference between the two build systems I have available to me, and I'm not currently able to look into this right now.

[asavah]

CXXFLAGS += -std=c++11 should help
if memory serves g++ 5.3 in ubuntu 16.04 defaults to std=gnu++98, which lacks lots of stuff,
however this should be checked and set properly by cmake, if it's not than it's a bug in the package itself and should be reported to package maintainers.

[Milhouse]

CXXFLAGS += -std=c++11 should help

I'll try it a bit later (or if you have a patch!) I added the start of the log which includes the initial (and relevant) error.

[asavah]

> I'll try it a bit later (or if you have a patch!) 
Nope, sorry, I build using gcc 7.3 (host) and 8.2 (cross), builds fine here.
I'll take a look at cmake stuff on a 16.04 VM I have handy.
https://github.com/google/flatbuffers/bl...s.txt#L123 <- that's what they do, it should be enough ...

Heh found it - https://github.com/google/flatbuffers/bl...s.txt#L111 if CMAKE_TOOLCHAIN_FILE exists it won't add std= flag thus the build will fail on older gcc,
just force add -std=c++0x -faligned-new to CXXFLAGS when cross compiling.

[Milhouse]

CXXFLAGS += -std=c++11 should help
if memory serves g++ 5.3 in ubuntu 16.04 defaults to std=gnu++98, which lacks lots of stuff,
however this should be checked and set properly by cmake, if it's not than it's a bug in the package itself and should be reported to package maintainers.

Yeah... from 16.04 VM (which fails):

text:
-- The C compiler identification is GNU 5.4.0

-- The CXX compiler identification is GNU 5.4.0

-- Check for working C compiler: /home/ubuntu/projects/LibreELEC.tv/build.LibreELEC-RPi.arm-9.0-devel/toolchain/bin/host-gcc

-- Check for working C compiler: /home/ubuntu/projects/LibreELEC.tv/build.LibreELEC-RPi.arm-9.0-devel/toolchain/bin/host-gcc -- works

-- Detecting C compiler ABI info

-- Detecting C compiler ABI info - done

-- Detecting C compile features

-- Detecting C compile features - done

-- Check for working CXX compiler: /home/ubuntu/projects/LibreELEC.tv/build.LibreELEC-RPi.arm-9.0-devel/toolchain/bin/host-g++

-- Check for working CXX compiler: /home/ubuntu/projects/LibreELEC.tv/build.LibreELEC-RPi.arm-9.0-devel/toolchain/bin/host-g++ -- works

and from 17.10 (which works):

text:
-- The C compiler identification is GNU 7.2.0

-- The CXX compiler identification is GNU 7.2.0

-- Check for working C compiler: /home/neil/projects/scratch/alternates/LibreELEC.tv/build.LibreELEC-Generic.x86_64-9.0-devel-gcc/toolchain/bin/host-gcc

-- Check for working C compiler: /home/neil/projects/scratch/alternates/LibreELEC.tv/build.LibreELEC-Generic.x86_64-9.0-devel-gcc/toolchain/bin/host-gcc -- works

-- Detecting C compiler ABI info

-- Detecting C compiler ABI info - done

-- Detecting C compile features

-- Detecting C compile features - done

-- Check for working CXX compiler: /home/neil/projects/scratch/alternates/LibreELEC.tv/build.LibreELEC-Generic.x86_64-9.0-devel-gcc/toolchain/bin/host-g++

-- Check for working CXX compiler: /home/neil/projects/scratch/alternates/LibreELEC.tv/build.LibreELEC-Generic.x86_64-9.0-devel-gcc/toolchain/bin/host-g++ -- works

Both are wrong, of course, as in both cases it's building with gcc-8.1.0 - what the package is doing is detecting the build host gcc version not the $TOOLCHAIN version (even though that is what it claims to be using). So it's possibly a little more involved than setting CXXFLAGS.

[asavah]

I edited my post, check the remark about the CMAKE_TOOLCHAIN_FILE

Edit:
Hmm in my buildsystem it detects both compilers right

host:

bash:
flatbuffers: configuring ...

[21:29:58] [DEBUG]: kbs.console.kbsConsole.configure(): logging disabled via config file

-- The C compiler identification is GNU 7.3.0

-- The CXX compiler identification is GNU 7.3.0

-- Check for working C compiler: /usr/bin/gcc

-- Check for working C compiler: /usr/bin/gcc -- works

-- Detecting C compiler ABI info

-- Detecting C compiler ABI info - done

-- Detecting C compile features

-- Detecting C compile features - done

-- Check for working CXX compiler: /usr/bin/g++

-- Check for working CXX compiler: /usr/bin/g++ -- works

-- Detecting CXX compiler ABI info

-- Detecting CXX compiler ABI info - done

-- Detecting CXX compile features

-- Detecting CXX compile features - done

-- Configuring done

-- Generating done

-- Build files have been written to: /home/asavah/kross/tmp/rock64/flatbuffers

bash:
target:

​​​​​​​flatbuffers: configuring ...

[21:30:26] [DEBUG]: kbs.console.kbsConsole.configure(): logging disabled via config file

-- The C compiler identification is GNU 8.2.0

-- The CXX compiler identification is GNU 8.2.0

-- Check for working C compiler: /home/asavah/kross/host/rock64/bin/aarch64-rock64-linux-gnu-gcc

-- Check for working C compiler: /home/asavah/kross/host/rock64/bin/aarch64-rock64-linux-gnu-gcc -- works

-- Detecting C compiler ABI info

-- Detecting C compiler ABI info - done

-- Detecting C compile features

-- Detecting C compile features - done

-- Check for working CXX compiler: /home/asavah/kross/host/rock64/bin/aarch64-rock64-linux-gnu-g++

-- Check for working CXX compiler: /home/asavah/kross/host/rock64/bin/aarch64-rock64-linux-gnu-g++ -- works

-- Detecting CXX compiler ABI info

-- Detecting CXX compiler ABI info - done

-- Detecting CXX compile features

-- Detecting CXX compile features - done

-- Configuring done

-- Generating done

-- Build files have been written to: /home/asavah/kross/tmp/rock64/flatbuffers

[Milhouse]

I'm not a cmake expert (or even a compilation expert, I mostly just push buttons and hope it works!), but it looks like when building flatbuffers for the host it uses the build host gcc (ie. in my case gcc-5.4.0 on 16.04 and gcc-7.2.0 on 17.10), but when cross compiling for the target it correctly uses gcc-8.1.0 from $TOOLCHAIN - the following is from 17.10 (as 16.04 failed during the host build):

text:
neil@nm-linux:~/projects/LibreELEC.tv/build.LibreELEC-RPi2.arm-9.0-devel/flatbuffers-1.9.0$ grep -r ^COMPILER_PATH=

.x86_64-linux-gnu/CMakeFiles/CMakeOutput.log:COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/

.x86_64-linux-gnu/CMakeFiles/CMakeOutput.log:COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/

.armv7ve-libreelec-linux-gnueabi/CMakeFiles/CMakeOutput.log:COMPILER_PATH=/home/neil/projects/LibreELEC.tv/build.LibreELEC-RPi2.arm-9.0-devel/toolchain/lib/gcc/armv7ve-libreelec-linux-gnueabi/8.2.0/:/home/neil/projects/LibreELEC.tv/build.LibreELEC-RPi2.arm-9.0-devel/toolchain/lib/gcc/armv7ve-libreelec-linux-gnueabi/8.2.0/:/home/neil/projects/LibreELEC.tv/build.LibreELEC-RPi2.arm-9.0-devel/toolchain/lib/gcc/armv7ve-libreelec-linux-gnueabi/:/home/neil/projects/LibreELEC.tv/build.LibreELEC-RPi2.arm-9.0-devel/toolchain/lib/gcc/armv7ve-libreelec-linux-gnueabi/8.2.0/:/home/neil/projects/LibreELEC.tv/build.LibreELEC-RPi2.arm-9.0-devel/toolchain/lib/gcc/armv7ve-libreelec-linux-gnueabi/:/home/neil/projects/LibreELEC.tv/build.LibreELEC-RPi2.arm-9.0-devel/toolchain/lib/gcc/armv7ve-libreelec-linux-gnueabi/8.2.0/../../../../armv7ve-libreelec-linux-gnueabi/bin/

.armv7ve-libreelec-linux-gnueabi/CMakeFiles/CMakeOutput.log:COMPILER_PATH=/home/neil/projects/LibreELEC.tv/build.LibreELEC-RPi2.arm-9.0-devel/toolchain/lib/gcc/armv7ve-libreelec-linux-gnueabi/8.2.0/:/home/neil/projects/LibreELEC.tv/build.LibreELEC-RPi2.arm-9.0-devel/toolchain/lib/gcc/armv7ve-libreelec-linux-gnueabi/8.2.0/:/home/neil/projects/LibreELEC.tv/build.LibreELEC-RPi2.arm-9.0-devel/toolchain/lib/gcc/armv7ve-libreelec-linux-gnueabi/:/home/neil/projects/LibreELEC.tv/build.LibreELEC-RPi2.arm-9.0-devel/toolchain/lib/gcc/armv7ve-libreelec-linux-gnueabi/8.2.0/:/home/neil/projects/LibreELEC.tv/build.LibreELEC-RPi2.arm-9.0-devel/toolchain/lib/gcc/armv7ve-libreelec-linux-gnueabi/:/home/neil/projects/LibreELEC.tv/build.LibreELEC-RPi2.arm-9.0-devel/toolchain/lib/gcc/armv7ve-libreelec-linux-gnueabi/8.2.0/../../../../armv7ve-libreelec-linux-gnueabi/bin/

Somehow we need the host build to use the correct $TOOLCHAIN path(s).

[asavah]

>I'm not a cmake expert (or even a compilation expert, I mostly just push buttons and hope it works!)
+1
Push button, read logs, try to make sense of cryptic error messages, google it, try to fix, rinse and repeat

>Somehow we need the host build to use the correct $TOOLCHAIN path(s).

Ahh, yes, I stumbled into this long ago.
My solution was to use CMAKE_TOOLCHAIN_FILE for host too, with the right values and pathes of course.
As further improvement to this I dynamically generate CMAKE_TOOLCHAIN_FILE and toolchain.meson hints with a python script, as my build-crap-system is heavily python-based it was trivial to do.

[Milhouse]

>I'm not a cmake expert (or even a compilation expert, I mostly just push buttons and hope it works!)
+1
Push button, read logs, try to make sense of cryptic error messages, google it, try to fix, rinse and repeat

Yes, exactly!

>Somehow we need the host build to use the correct $TOOLCHAIN path(s).

Ahh, yes, I stumbled into this long ago.
My solution was to use CMAKE_TOOLCHAIN_FILE for host too, with the right values and pathes of course.
As further improvement to this I dynamically generate CMAKE_TOOLCHAIN_FILE and toolchain.meson hints with a python script, as my build-crap-system is heavily python-based it was trivial to do.

Yes, this seems to be a fundamental issue with the LE "cmake" buildsystem - it's not specific to the flatbuffers package, it's every host package we build with cmake is identifying the "wrong" (ie. host) gcc version rather than the toolchain host-gcc version. It's just that flatbuffers craps out after identifying the wrong gcc whereas other packages build successfully, so I think this needs to be fixed across the board and then flatbuffers should build successfully for LibreELEC. But PR14209 doesn't currently build anyway, so not building flatbuffers is probably the best option for now!

Hopefully one of my colleagues will be able to dig into this - I'll point them at your posts, we already generate the various config scripts but maybe we're missing something vital for host...

[asavah]

That's what my cmake toolchain file for host looks like https://gist.github.com/asavah/7eb88c165...bca69d70c3
I don't bother building a toolchain for host, but I do prefer telling cmake how to deal with eg. RPATH or ccache.
If necesary *FLAGS get added later by the buildsystem itself depending on what a particular package may want.
Hope this helps.