Posts by musicadi

Hello,

I have LE 8.2.1 installed on my Wetek Core and UPnP just stops working, although the box is never turned off.

If I turn the service off and then back on, it starts working.

I'm not sure, but I think this started with version 8.2.1.

Here are the UPnP related settings from guisettings.xml

<upnpannounce default="true">true</upnpannounce>

<upnpcontroller default="true">false</upnpcontroller>

<upnplookforexternalsubtitles default="true">false</upnplookforexternalsubtitles>

<upnprenderer default="true">false</upnprenderer>

<upnpserver>true</upnpserver>

How can I collect some related log files to see where the problem occurs?

Thank you!

Thank you for the answers! I just started clean, seemed safer

P.S. LibreELEC is installed on NAND. I've has several crashes with Android installed on NAND, there it resulted in data loss.

I noticed no data loss with LibreELEC after the crashes.

Hello,

I've had several crashes with LibreELEC installed on my Wetek Core.

Here are the logs:

LibreELEC - Crash – Google Drive

Could this be a hardware issue? Maybe the HFS+ partition on my external drive?

The database errors were because I was messing with the database to change a thumbnail. Deleted it since then.

Thank you!

Ok, it's super clear now, thank you guys!

Ok, I see, thank you for the answers!

I actually created an EXT4 partition for local use and kept the HFS+ one for stuff I need to access when connecting the drive to my Mac.

exFAT seems really slow on macOS, so I'd rather not use it.

Do you think it's safe to keep using fsck.hfsplus on the partition from within LibreELEC whenever it gets mounted as read-only? (I'm not using it that often.)

Thank you!

Hi there,

Is there a good solution for stopping LibreELEC from "corrupting" an HFS+ partition and force it to mount read-only? (except formatting to exFAT or EXT4)

What I noticed is that the partition only gets corrupted after a reboot and will be then mounted read-only.

Issuing an fsck.hfsplus -f on the partition then a reboot actually fixes the problem and the partition gets mounted with rw flag

I remember reading somewhere that the problem arises due to the fact that partitions aren't automatically unmounted before a reboot. A user suggested adding a script that would unmount the partitions before a restart.

Wouldn't that be a good solution to add to future releases, or is that too risky?

Thank you!

Quote from Klojum

Perhaps you can give Mr. Cook from Apple a quick call, and ask him to stop f*cking around with Airplay's functions every couple of months. Kodi has to reverse-engineer the whole Airplay workings, and probably for some odd reason, Apple is not too happy with that.

In short, it can probably be fixed (again), until Apple breaks it again.

It's cause they want you to buy the Apple TV instead

Quote from mglae

No current dependencies, looks safe to disable it:

Code

systemctl disable network-online.service

and reboot to test.

Thank you! Made a clean install and the service doesn't show up anymore.

UPDATE:

I started clean with a hard reset, set everything as usual, populated my library and startup time is now normal at about 23s

Weirdly enough, network-online.service doesn't appear anymore under systemd-analyze

I haven't installed a few add-ons that I had on my other install, so one of them might be the problem:

- Youtube v5.4.5

- nfowatchedstateupdater v1.1.12 (axbmcuser mod)

- I/O benchmark

- CPU benchmark

I also noticed there were a lot of add-on script modules in the other install, probably installed by one of these add-ons. Also, the OpenELEC repository was still there after I migrated.

So, the issue seems to be resolved, it's still weird though that I had normal boot times with this same setup on OpenELEC 8.0.2

Quote from mglae

Code

systemctl list-dependencies --reverse network-online.service

Thank you!

Here is the output..

network-online.service

● └─network-online.target

● ├─kodi.service

● ├─kodi.target

● └─kodi.target

I just found this in dmesg output.

LibreELEC runs from microSD on the Wetek Core. I am constantly having problems with Android on NAND. Could this be connected?

[ 8.814880@0] EXT4-fs (mmcblk0p2): mounting with "discard" option, but the device does not support discard

[ 8.814884@0] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)

[ 12.176259@0] Connect Timeout

[ 12.176316@0] Device Not Connected/Responding

[ 16.796277@1] WARN::hc_xfer_timeout:2723: hc_xfer_timeout: timeout on channel 3

[ 16.796335@1] WARN::hc_xfer_timeout:2725: start_hcchar_val 0x01188a00

[ 16.796393@1] WARN::hc_xfer_timeout:2730: chn-3,ep1-IN:type:2,speed:2,len:4096,addr4

I also see this error:

[ 20.696343@0] [aml_sdio_timeout] time_start_cnt:999

[ 20.696343@0] [aml_sdio_print_err] sdio: Timeout error, Cmd52 arg 0xc00, Xfer 0 Bytes, host->xfer_step=12, host->cmd_is_stop=0, pdata->port=0, virqs=0x13, virqc=0x3f001f00, conf->cmd_clk_divide=177, pdata->clkc=177, conf->bus_width=0, pdata->width=0, conf=0x416270b1, clock=397940

[ 20.696343@0]

[ 21.696377@0] [aml_sdio_timeout] time_start_cnt:999

[ 21.696377@0] <4>[ 22.711456@0] sdio: queuing unknown CIS tuple 0x80 (2 bytes)

[ 22.713945@0] sdio: queuing unknown CIS tuple 0x80 (3 bytes)

[ 22.721042@0] sdio: queuing unknown CIS tuple 0x80 (3 bytes)

[ 22.725698@0] sdio: queuing unknown CIS tuple 0x80 (7 bytes)

[ 22.817400@0] sdio: new high speed SDIO card at address 0001, clock 35416666, 4-bit-bus-width

[ 22.820725@0] [sdio_reinit] finish

That's it then! I have an external USB drive with an EXT4 and a Journaled HFS+ partition.

So it must be something related to external USB (specifically EXT4 and/or HFS+ partitions) that's causing the delay. I suspect the HFS+ partition.

But, like I said, boot time was definitely faster on OE 8.0.4 with this same setup.

Is there a way to dig deeper into this and see what exactly changed that triggers the extra delay?

Thank you!

Quote from lrusak

ah, Do you have some systemd service that mounts something? The examples depend on Requires=network-online.service which will pull in that dependency.

So that could be it

Quote from lrusak

You have the "wait for network" option enabled which holds the boot for 10s. Other than that I don't see anything else out of the ordinary.

Actually, "Wait for network" was disabled (in LibreELEC settings). I enabled it and now the first 2 lines of systemd-analyze blame are these:

10.152s network-online.service

10.139s kodi-waitonnetwork.service

So, there's an extra 10s when "Wait for network" is enabled (kodi-waitonnetwork.service)

When I disable the option, I get the output which I uploaded to pastebin, with 10s for network-online.service

Time between LibreELEC boot and Kodi start is about 25 seconds

Hi,

Thank you for your answer!

Here are the logs

CVFe

FYUe

Quote from lrusak

no idea

post the output of the following commands

Code

journalctl -b 0 | pastebinit


systemd-analyze blame | pastebinit

Hello,

I just migrated from OpenELEC 8.0.4 to LibreELEC 8.2.0 on my Wetek Core.

I love the HDMI-CEC add-on and the fact that the Kodi version is always up-to-date.

However, I noticed that the boot time is about 20-30 seconds longer than when on OpeneELEC. Is this normal?

Thank you!

Does anyone else experience this?

Hello,

I am experiencing the following problem:

- "Update Channel" list is empty, when clicking on it, as well as the "Available versions" list

If turning the "Show custom channels" on and then off, everything returns to normal

Here is the pastebin uploaded just after the issue appeared and was the resolved.

PORf