Posts by ghtester

AFAIK this is not an issue as the signal level on some channels is not perfect so I suppose that's why there are the Continuity errors. They don't increase much in general... It was an issue in past, I was struggling with a driver configuration (Astrometa DVB-T/T2 tuner) but now it works quite good.

I believe anybody else (who is also using a Live TV & Tvheadend) should be able to reproduce the described Timeshift / Tvheadend issue.

I don't know what exactly happens when the RAM only parameter is used but on filesystem it's immediately visible if the Timeshift / Maximum size limit is currently working or not.

I am using tmpfs for the Timethift buffer this way and it's pretty usable:

mkdir /tmp/ramdisk

chmod 777 /tmp/ramdisk

mount -t tmpfs -o size=800m myramdisk /tmp/ramdisk

I could accept that Timeshift stops (stops writing buffer data) when the buffer is about to overflow... But Kodi does not handle that situation (which happens) correctly (the question is what should be done in this case but I am sure the Timeshift pointer should not jump to nonsense / left border).

Not yet as I am not registered there so far. Also it would be nice if somebody else could confirm the same to be sure I don't make a hoax.

IMHO Kodi needs a fix as well - I believe the Timeshift pointer should never jump outside the Timeshift bar.

It looks nobody else is interested in nor has this issue.

But I have spent some time with investigation and now I know more. Maybe it's useless but let me share it anyway:

- perhaps I should rename this thread because the Timeshift data are not discarded randomly as I thought earlier.

- the behavior depends on Tvheadend server Timeshift configuration (where the Timeshift buffer should be stored - RAM or filesystem). The better solution seems to use a storage path as it's visible what's happening and the Timeshift data can be accessed / used when necessary.

- the reason is the Timeshift buffer is overflowed (when the Timeshift buffer is already full and you pause it or move the Timeshift pointer to left border). Then the Tvheadend stops overwriting the buffer data. When unpaused, Kodi can play the buffer files until end and then gets confused, jumps outside of left Timeshift border and decrementing the Timeshift offset to nonsense values.

- Tvheadend 4.3 has a serious bug in Timeshift configuration - the Maximum size (MB): option is ignored so it may lead to unpredictable results.

- only Maximum period (mins): can be used but files are created every minute so with very variable size which depends on data stream parameters so the filesystem size can't be effectively used for data streams with lower resolution.

- Kodi does not count with any possible Timeshift data buffer overflow and this issue is not covered.

Quote from lobbie1978

I was thinking, since I have a Raspberry Pi 4b with dual HDMI outputs, would it work to connect output 1 directly to the beamer and output 2 to the receiver to get the audio?

Yes it's possible, at least in LE10 (don't remember if I tried it in LE 9.2.6 as well or not) to have a video on HDMI0 and an audio on HDMI1.

But the HDMI devices must be detected when Kodi starts (otherwise you would need to play with EDID etc...).

Then you should be able to configure the audio output in Kodi menu Settings - System - Audio - Audio output device

There you should see your receiver at HDMI1.

Another update - at least there's an issue with Tvheadend backend - Build: 4.3-1940 ~ LibreELEC Tvh-addon v9.80.11.100 (2021-03-10T21:50:53+0100)

In configuration described above it ignores the parameter Maximum size (MB): and keeps writing buffer files until the filesystem is full or the Maximum period (mins): limit is achieved.

Even though the Maximum period (mins): parameter is set as the limit (to keep some free space on filesystem), when this limit is achieved, after some time (when moving the Timeshift pointer, perhaps the left border is a critical point), the Timeshift stops working as well as described in previous post...

OK - so now I can see how it works when Timeshift in Tvheadend backend service is configured to use files and when the Timeshift is active:

There's created folder named buffer, inside appears a subfolder with buffer files (every minute a new file is created until their total size match the Timeshift Maximum size configuration).

This subfolder's name is a number - starting from 0, as soon as I switch the channel, the folder with buffer files is deleted and a new folder with incremented number is created and a new buffer files are generated. Everything looks working fine...

Now what happens - sometimes - usually when I try to move the Timeshift pointer in Kodi (with left - right arrows on RC), usually backwards to see the part of the Live stream again:

- The Timeshift pointer in Kodi does not jump as expected and it's position is lost, then jumps to left border of Timeshift bar (which represents the Timeshift buffer recorded size)

- The Timeshift feature stops - the buffer data files stays there and it's possible to play them again but it looks at some further point are corrupted

- TheTimeshift offset can't be moved to zero anymore with Timeshift running (until the channel is switched to another or stopped / started again). But when I try to move the Timeshift pointer to right Timeshift bar's border (keeping right arrow pressed) until the Seeking offset is >= negative Timeshift offset, it switches to Live stream (but it does not record to Timeshift buffer anymore). In this state any left-right arrow push starts playing the Timeshift buffer from begin.

Don't know if anyone can ever read this and understand what I mean - better try. But it's a real nightmare, how this feature (not)work.

When I tried the same with Timeshift to RAM only, it was even worse because the buffer data were immediately discarded when the Timeshift pointer was lost so there was nothing to analyze.

I don't know how it works together, if Tvheadend backend (4.3) has a bug or if that's Kodi but it looks more likely that Kodi can't work properly with Timeshift / Timeshift buffer data.

Also it looks the critical moment is when the Timeshift buffer gets full (so a circle write must start).

Yes it looks this add-on was written in python2 which is now a bit obsolete and LE10 is yet using python3, which is not backward compatible.

I think there are more important tasks to do but perhaps somebody from developer team will comment it better.

Perhaps better decoding of VC-1 in future could be a side effect - AFAIK the video drivers on RPi 4B are not yet finished in general and it's still in progress. But it's hard to say how long it could take.

Thanks for a comment. I still don't understand why Kodi shows such an unusually high value of free memory.

It was always strange but as soon as I have created a tmpfs filesystem in RAM which is now occupied by about 800 MB of Timeshift buffer data, the Kodi's report regarding to Free memory is now absolutely nonsense on my RPi 4B / 2GB RAM.

That's why I am asking if developers (who can better than me understand how things work) are considering it as OK... Maybe it's not just a GUI info message - if the same value is used somewhere in Kodi's background, it could perhaps sometimes lead to memory overflow etc (and the oom killer sometimes appears...)...

FYI the current values:

Kodi Free memory: 1424MB

top - 10:39:55 up 17:22, 3 users, load average: 1.26, 1.43, 1.45

Tasks: 148 total, 1 running, 147 sleeping, 0 stopped, 0 zombie

%Cpu(s): 8.6 us, 3.5 sy, 0.1 ni, 87.3 id, 0.0 wa, 0.0 hi, 0.5 si, 0.0 st

MiB Mem : 1863.3 total, 386.9 free, 438.9 used, 1037.5 buff/cache

MiB Swap: 0.0 total, 0.0 free, 0.0 used. 529.9 avail Mem

# cat /proc/meminfo

MemTotal: 1908012 kB

MemFree: 395616 kB

MemAvailable: 542032 kB

Buffers: 45152 kB

Cached: 990108 kB

SwapCached: 0 kB

Active: 791468 kB

Inactive: 486616 kB

Active(anon): 634920 kB

Inactive(anon): 405900 kB

Active(file): 156548 kB

Inactive(file): 80716 kB

Unevictable: 45036 kB

Mlocked: 0 kB

HighTotal: 1231872 kB

HighFree: 30896 kB

LowTotal: 676140 kB

LowFree: 364720 kB

SwapTotal: 0 kB

SwapFree: 0 kB

Dirty: 0 kB

Writeback: 0 kB

AnonPages: 288024 kB

Mapped: 108004 kB

Shmem: 797996 kB

KReclaimable: 27780 kB

Slab: 59440 kB

SReclaimable: 27780 kB

SUnreclaim: 31660 kB

KernelStack: 1888 kB

PageTables: 3128 kB

NFS_Unstable: 0 kB

Bounce: 0 kB

WritebackTmp: 0 kB

CommitLimit: 954004 kB

Committed_AS: 1548760 kB

VmallocTotal: 245760 kB

VmallocUsed: 12216 kB

VmallocChunk: 0 kB

Percpu: 512 kB

CmaTotal: 524288 kB

CmaFree: 320136 kB

See here: Config.txt - LibreELEC.wiki

As there's no feedback or comment from developers and it seems the Timeshift issue is more worse than better in latest LE 10 Nightly on my RPi / 2GB, I decided to try a different Timeshift configuration.

As I had no idea what's happening in memory with Timeshift data / how it works, I created a tmpfs mount and instead of RAM Only, I changed the Timeshift configuration in Tvheadend backend to use /tmp/ramdisk with 800 MB size and currently I am testing how this works... At least I can see how the buffer files are created and when are discarded.

So far it looks that Kodi is sometimes loosing a pointer in Timeshift data (and gets messed) even in this configuration but the Plus is the files are not discarded immediately when this happens. But it's too early to say that's fact - it needs more thorough testing in my environment.

Nobody commented it so far but I would like to know if it's really OK how the Free memory in Kodi is reported?

It's still the same in latest LE 10 Nightly and to me it looks confusing.

For instance:

1)

Kodi - System info - Summary

Free memory: 1360MB

top in SSH console:

top - 21:29:55 up 4:12, 1 user, load average: 1.17, 1.36, 1.42

Tasks: 144 total, 1 running, 143 sleeping, 0 stopped, 0 zombie

%Cpu(s): 9.2 us, 4.1 sy, 0.3 ni, 85.3 id, 0.0 wa, 0.0 hi, 1.1 si, 0.0 st

MiB Mem : 1863.3 total, 462.7 free, 503.5 used, 897.0 buff/cache

MiB Swap: 0.0 total, 0.0 free, 0.0 used. 614.3 avail Mem

2)

Kodi - System info - Summary

Free memory: 1303MB

top in SSH console:

top - 22:32:01 up 5:14, 3 users, load average: 1.44, 1.38, 1.39

Tasks: 148 total, 1 running, 147 sleeping, 0 stopped, 0 zombie

%Cpu(s): 6.9 us, 4.0 sy, 0.3 ni, 87.7 id, 0.0 wa, 0.0 hi, 1.1 si, 0.0 st

MiB Mem : 1863.3 total, 225.1 free, 553.4 used, 1084.8 buff/cache

MiB Swap: 0.0 total, 0.0 free, 0.0 used. 348.5 avail Mem

The best current solution is perhaps to transcode these few movies to HEVC (if it's <= 4K@30 Hz). Or wait until there's a driver improvement regarding to VC-1 decoding.

Well, I thought this question was about a backup of further working / fresh LE installation as from my point of view it's too late to try backup a corrupted installation and .kodi folder might not be enough.

By using a search, you may find something like this: Basic backup/restore question

Quote from Aviloff1984

But how can i preserve all my settings, add-ons, media db? Should i backup .kodi folder for that?

There's a backup option in Kodi - see menu Settings - LibreELEC - System - Backup

Klojum OK, you are right - my fault, sorry, I have overlooked it...

It looks, for some unknown reason, I have focused more to your post #2 and "4 devices" mentioned than to original subject...

Yeah the .json file is not there at the moment but the Nightly builds are generated so you may still update manually through SSH console.

It's also important to keep the bootloader updated as there're several fixes regarding to SD card.

rpi-eeprom/release-notes.md at master · raspberrypi/rpi-eeprom · GitHub

There's an example how to easily upgrade the bootloader to latest one:

RE: Is it possible already to set up a rpi4 with kernel 5.4?

Also make sure you don't use any suspicious / banned add-ons which seems to be the quite often reason of such issues.

See here: Official:Forum rules/Banned add-ons - Official Kodi Wiki

Edit - Arghh, sorry - I have overlooked it's RPi 2B so my post is a bit irrelevant regarding to bootloader update (which is valid for RPi 4B)...