Posts by chewitt

Kodi runs great on an RPi3 but if you install the amount of pirate add-on crapware that your log shows I would expect problems. Aside from the dubious legal status of those add-ons (and banned in this forum) they are poorly coded and frequently attempt to detect and break other 'competing' add-ons to drive user traffic to their forums where you generate adsense profits for the scum who operate the sites.

As you have discovered, the problem follows you between LE, OE, OSMC, which proves it is not an OS problem. If you purchase a NUC and reinstall the same crap it will run the crap faster, but equally crappy.

If you are using Ethernet there is no need for cache tweaking. Your network has to be royally buggered for Ethernet to not work in an out of box config and if that's the case, the solution is fix the network not force Kodi into the unknown with ridiculous cache settings.

No debug log = no problem

Stick with the default LE image or @codesnakes image. Report the issue to WeTek support. Let them guide/help you.

FYI.. glibc: add UTF-8 support by thoradia · Pull Request #1524 · LibreELEC/LibreELEC.tv · GitHub

[    0.000000] Linux version 4.4.32v7-aufs (max@lynx) (gcc version 4.8.4 (Buildroot 2015.02-gf4a5ebb-dirty) ) #1 SMP Fri Nov 18 23:17:35 CET 2016
[    0.000000] CPU: ARMv7 Processor [410fd034] revision 4 (ARMv7), cr=10c5383d

BerryBoot?

If yes, no further support until you've tried a proper LE image running our kernel not the frankenstein image you're using. Seriously. We build a tightly integrated OS/app package and we do not support someone else's completely different kernel.

You need to create different sources for Movies and TVShows. If you add tvshow content to a shared folder that had "content type" movies set, they will not scrape; or to be correct, they will scrape but the scraper won't find movies matches for them.

\\SERVER\MEDIA\MOVIES
\\SERVER\MEDIA\TVSHOWS

or

\\SERVER\MOVIES
\\SERVER\TVSHOWS

not

\\SERVER\MEDIA <= with both types in the same location

Does anything happen when you run "eject /dev/sr1" from the console? .. on some wireless devices the fake CD device (with drivers etc.) must be ejected before the wireless part is made available. Otherwise there are some messages in dmesg that I haven't found a clean explanation for yet.

The easiest way out of this is to shift the content off the drive and do a clean reformat, copy it back. As much as a I like debug challenge it would be quicker if you have something to temporarily move the data to.

hammerboy, that image is updated with a large patch from OE's collection that probably solves a bug in the driver. Test again and report back.

If you had an upgrade issue solved by deleting Addons27.db I am interested in obtaining a copy of the previous AddonsXX.db from your box. For users updating from Jarvis this will be Addons20.db. Kodi devs would like to see examples to try and figure out why this issue is (still) seen.

hammerboy.. please test this image Index of /test/ and report back, it has updated misc-firmware. NB: It's tagged as 8.0.2 but don't read anything into the version number; release is a way off yet.

LE already moved master branch (future LE 9.0) back to OpenSSL but there are no plans to move 8.0.x releases as it requires a load of additional rework to add-ons and there isn't the appetite for that. Current milhouse builds (with Kodi Leia code) are available. If/maybe we opt to create an LE 8.2 release to bring a kernel bump and other new hardware changes before Leia (as it's a long way off) we will do it then, but there's no guarantee we'll do that.

If you combine the S905 build project from @kszaq's github repo and the WeTek Hub or Play2 projects in the OpenPHT-embedded repo you probably get a working image. Some of the OpenPHT folks actively contribute and collaborate with LE and their version of the OS is deliberately not too different.

If you want a reliable network experience use Ethernet. It's a sucky answer, but it sucks less than the sh1t quality realtek drivers that we are forced to embed in our otherwise reliable distro.

connmanctl
agent on
scan wifi
services

leave 10 seconds between scan and services; this will list the networks in-range assuming the drivers are loaded and the wireless device is working

a smorgåsbord of missing firmware bits should be present in LE 8.0.2 which is under preparation (but no dates just yet)

I would avoid doing this split set-up because Windows\saves\files\paths\like\this and Linux/uses/paths/like/this .. so while most config will work, there is always a percentage off stuff that will not. Unpicking the stuff that does not work usually takes longer than doing it the 'hard' way.

dmesg | paste
blkid | paste
parted -s /dev/sdb unit s print | paste <= where /dev/sdb is the 2TB drive

share the URLs here

"SMB" encompasses multiple not-quite-compatible versions of a shitty designed networking protocol that is implemented via a third-part integration library (smbclient) that is wrapped in Kodi code that hasn't seen much love in aeons. Somewhere in that list resides a mess of problems. The current resurgence in reported issues (which may or may not be your issue) is largely due to Microsoft changing things in their SMB server stack. I forget what changed and thus what might be required to coerce things to work again; but it probably involves registry hacking to downgrade features on the Windows end. Best solution is to get a NAS because this will run "Samba" with an older SMB protocol version which is more widely supported (and powered on permanently which solves other silliness) or use NFS on the server side to sidestep SMB completely. Sorry if that sounds a bit shitty-worded, but Windows networking has been a complete turd since Windows '95 and I'm struggling to work up the enthusiasm for it today..