Posts by milhouse

Quote from yubby

Do I 'lose' anything using the older video driver ?

I don't think so.

Thanks for your post. However at the moment we have no plans to switch away from busybox for mount (but if we do, we would most likely switch to using mount from the util-linux package).

Guest access is becoming increasingly more difficult to achieve, with Microsoft now actively disabling such access to shares, so you might want to consider adding authentication (and avoid using SMB1 which is the default CIFS protocol used by kernels earlier than 4.13.y):

guest-access-smb2-disabled-by-default-in-windows-10-server-2016

Note that starting with kernel 4.14.y the protocol negotiated by CIFS will be at least SMB2_10 and never SMB1 unless forced with vers=1.0. (kernel 4.13.y did not support multi-protocol negotiation and simply enforced SMB3).

Yes, I'd still go with 320.

Default cache in Kodi 18 is the same as Kodi 17. However the videoplayer in Kodi 18 has been heavily modified since Kodi 17, and may now be able to work better with lower or unstable bandwidth.

Not at this time. There are plans to support colour profiles in future, but at the moment the current implementation is not ready for release.

Quote from LeChuck

Can anyone please help me interpreting the log after that line?

Code

18:42:58.931 T:139745040508672   DEBUG: ### [Qlock] - Delaying 240 secs

The problem occurs beginning with the next line that happens 2 minutes later (at 18:44:04.115).

Before I start playing around with cache settings for all local sources, I'd really like to understand what has been logged in the requested debug log.

Perhaps "Qlock" is from an add-on you've installed? I can't find any reference to "Qlock" in the source code used to build LibreELEC.

Start with a "clean" .kodi folder without any additional add-ons or repositories and see if the problem continues.

Why do the binary files need to be in the writeable partition? What happens if the binary files are deleted, will you need to recreate them? What happens if you create a new version of your image, will you need to overwrite older binaries?

Extracting the binary files to /storage if they're not present or out of date would work more reliably (and with fewer changes) than modifying the resize script (and the image creation process), though I'm interested to know why it is necessary to install the binaries in /storage if you are creating the image.

Installing the binaries via a Kodi add-on is the other solution for third-party binaries as this allows periodic updates without updating the whole image.

If you adapt their script into a Kodi add-on you can probably get it to work with RPi.GPIO instead of Wiring Pi. I wouldn't expect anyone to write this for you unless they have one of these devices, as it's a very niche requirement. You might have more luck contacting the manufacturer, to be honest.

We'll happily take a PR if anything is developed.

You might also want to fix the typos in your samba.conf:

Jan 29 17:55:03 HTPC smbd[584]: [2018/01/29 17:55:03.007792,  0] ../lib/param/loadparm.c:772(lpcfg_map_parameter)
Jan 29 17:55:03 HTPC smbd[584]:   Unknown parameter encountered: "brwoseable"
Jan 29 17:55:03 HTPC smbd[584]: [2018/01/29 17:55:03.007833,  0] ../lib/param/loadparm.c:1750(lpcfg_do_service_parameter)
Jan 29 17:55:03 HTPC smbd[584]:   Ignoring unknown parameter "brwoseable"
Jan 29 17:55:03 HTPC smbd[584]: [2018/01/29 17:55:03.007861,  0] ../lib/param/loadparm.c:772(lpcfg_map_parameter)
Jan 29 17:55:03 HTPC smbd[584]:   Unknown parameter encountered: "writeabele"
Jan 29 17:55:03 HTPC smbd[584]: [2018/01/29 17:55:03.007871,  0] ../lib/param/loadparm.c:1750(lpcfg_do_service_parameter)
Jan 29 17:55:03 HTPC smbd[584]:   Ignoring unknown parameter "writeabele"

Did you read the announcement documenting the Samba changes? Network browsing is no longer supported which is why you don't see the other shares listed in Kodi - you need to manually add their network location now.

I don't know why the min/max protocol settings would be resetting to "None" after a reboot - that's not right but you're the first person to report it. Are you changing the Kodi client settings, or the settings in the LibreELEC Settings add-on?

If you're editing the Samba Server configuration samba.conf then you may have added an error. Upload your version, and also "journalctl -a" from the server (to a pastebin site, then post the links).

Out of the box LE 8.2.3 with default/stock Samba Server and Kodi client SMB settings will work fine with Windows 7+ so if it's not working then check any changes you've made, reset them to default and start again.

4K is not possible on RPi.

Since the Videos folder could normally be expected to contain large multi-gigabyte media files, this folder is not included in the backup.

The only folders that are included in the backup are as per the "Help text" description in the LibreELEC Settings addon:

Quote

Create a tar archive containing all LibreELEC and Kodi configuration settings, databases and thumbnail content. Backup files will be stored in /storage/backups

This means the following folders are included in the backup:

/storage/.kodi
/storage/.config
/storage/.cache

/storage/.ssh

Backing up random user content is not supported by the Backup option.

Your best bet would be to create your changes as a Kodi addon which stores it's settings and artwork inside Kodi in the usual way as this would be backed up.

Or submit a PR to the LibreELEC Settings addon Github which enhances the backup implementation with support for additional folders.

Are you able to try LE9.0/Kodi 18/linux 4.14.15 builds, as these naturally include updated everything, and see if you have the same artefacts?

Uploading a sample ts file (small one!) might be useful if you can detail where you see the artefacts and then others can view it on their systems (even if they don't have DVB hardware, which would help rule out DVB entirely) to see if they see the same artefacts.

If this is a GPU issue I'm not really sure what we can expect from Nvidia as this would be with their legacy GPU driver which is on it's last legs.

Quote from t3uch1

I do not see the RPI in SMB, so I can not test

On the RPi in Kodi > Settings > File Manager, add the Odroid_C2 as a source ("Add source").

In the left listing, click on "Add source" and enter the smb:// path details for the Odroid C2 share after clicking on Browse > Add network location (create a Windows network (SMB)" location). You'll then be able to create the new SMB source using the new network location - name it "Odroid SMB".

If you don't have a source on the RPi in which you can store videos then in the right list click on "Add source" and create a source using one of your "Home folder" directories, eg. videos, and then name the new source "Local videos".

Navigate into the "Local videos" source using the right list.

Now, in the left list, navigate into your "Odroid SMB" source, assuming you have any large 4GB+ files open the context menu ("c" on a keyboard) and if you click on "Copy" the file will be copied from the Odroid to the RPi using the smb:// protocol.

You can also copy files from the right list to the left list, which - if unchanged from above - would copy a file from the RPi "Local videos" source to the "Odroid SMB" source, thus testing the copy in both directions.

Quote from t3uch1

I copy a file of 10GO and it is a 8go without er er message to 2.06gb

I'm not entirely sure what you are saying here or what the different numbers mean - are you saying the 10GB file is being copied successfully (with no errors and no missing data) to the RPi? In which case test #3 is confirmed as OK.

Please confirm if test #1 is working - if test #1 is not working, then this would point more strongly towards an Odroid C2 issue (or perhaps some issue between the Odroid C2 network interface and your router?)

Quote from t3uch1

On the RPI with Libreelec 8.2.3 it works ... So either it's the special distribution for Odroid (I doubt it) or it's the Odroid ... what do you think?

Just to be clear - when you say "On the RPI with Libreelec 8.2.3 it works" is this with the RPi as the Samba Server (and Windows/Mac as the clients) or the RPi is the client and Odroid is still the server?

What I'd like you to test is:

#1: With Odroid C2 as Samba Server, use the RPi as client to copy a large file to/from Ordoid C2 (you should be able to use the Kodi File Manager and smb:// source for this)

#2: With Odroid C2 as Samba Server, use the Windows/Mac as client to copy a large file to/from Ordoid C2

#3: With RPi as Samba Server, use Windows/Mac as client to copy a large file to/from the RPi

We know #2 doesn't work, but I'd just like confirmation on the other tests to avoid any confusion.

Probably best answered by the Odroid maintainer - not hardware (or a build) I'm that familiar with. I do know it uses an older kernel, but I believe we internally tested Windows to an Odroid, and didn't see a problem.

Quote from t3uch1

Thank you in any case for trying to help me

You think it can come from my network? because under Windows 7, 10, and mac similar ...

If it is the case I test an installation on an old RPI 3 to see if it's joking also we will know that it is not the Odroid server, or the Odroid version ...

I use Orange as an internet network, in France we have a lot of this network and we do not have the same problem ...

It would be interesting if you could test a LibreELEC client (can you boot your Windows PC with a LibreELEC 8.2.3 Generic USB memory stick in "run" mode?) with your Odroid LibreELEC server. If this also fails then there are only two possibilities - your network (router, switch, cables), or there is something wrong with the Odroid implementation of Samba Server.