Posts by nvdias

Some additional information:

A)

When watching tv with addon pvr.hts running in the same machine as tvheadend service:

- LE 11 nightly build - green artefacts; (*)

- LE 10.0.2 - green artefacts; (*)

- LE 9.2.8 - ALL OK (no issues).

(*) If I turn off "Allow Hardware acceleration with DRM PRIME" the artefacts disappear. But image loosed smoothness ...

B)

When watching tv by remotely connecting from another machine (windows pc with kodi, or vlc, or android tv with kodi)

to libreelec tvheadend service:

- ALL OK !

So, the issue is common to LE10 and LE11 and ONLY when running pvr.hts in the same machine as tvheadend ...

and with "Allow Hardware acceleration with DRM PRIME" activated.

chewitt, popcornmix should I report this somewhere else ?

thanks

Some more tests and a sample:

- Green Artefacts just appearing if using kodi pvr.hts addon viewer and tvheadend server in the same machine (libreELEC 11 in RPi4).

- Artefacts appearing only after a Continuity Counter Error in tvheadend log;

- Green Artefacts and Continuity Counter Error DO NOT APPEAR if the viewer is running in another machine (example: VLC in WINDOWS or KODI running from Android tv !

The link bellow is for a sample file recorded in LibreELEC -> the green artefacts are displayed if played in LibreELEC 11 RPi4, but almost unnoticeable if playing in VLC player in windows:

https://mega.nz/file/Ebp2kLJB#08TEUe5pt2IMeLN8D0Gfg5wTjbeN1EsaTZGGQ_ykKVI

Thanks

Quote from popcornmix

Do you see the artifacts in recordings? If so, can you provide a short sample file that shows the issue?

hi, in recordings they do not appear as green artifacts. anyway I will try to get a sample - more thinking where to share it.

Quote from smp

I had the same issue on a pi3. The issue was that when running both tvh client and server on the same pi AND using advanced deinterlacing method - green artefacts would appear from time to time, also continuity counter errors in tvh log.

The solution was to use BOB deinterlacing instead of "advanced". However, BOB looks much worse than advanced.

Another solution was to increase the arm_uc value, e.g.:

Code

# vcgencmd arbiter set arm_uc 12 0

I don't have pi4 so no idea if this would work.

pi4 using prime for deinterlacing. No options.

changing arm_uc not producing any changes.

But thanks for the suggestions.

I've been using the latest nightly builds on a RPi4.

Since the introduction of deinterlace for RPi4, it was a big evolution for live tv watching (RE: LE10 & deinterlacing in RPi4)

I've installed tvheadend server in LE11 and using the tvheadened pvr add-on to watch live tv on my RPi4.

All ok except ... some green artefacts that appear from time to time in almost every channel.

I'm using:

• TB5520SE receiver (with pre compiled modules as described here LE10 & TBS 5520SE on RPi4 // updated drivers [SOLVED]);
• tvheadend server;
• tvheadend pvr add-on;
• DVB-C unscrambled (free) signals;
• using the same cable as the one connected to the TV provider set-top box.

Watching tv in KODI running on libreelec gives the green artefacts.

As my tv is a SONY Android tv, i've installed KODI 19 in it and connected to the tvheadend server on my RPi with LibreELEC- in this case the image is stable without any artefacts.

The same goes to the tv provider set-top which also plays flawlessly.

So, the difference here is KODI20 in LE11 on RPi4 - any suggestions on how to fiddle with LE11 KODI20 to handle those green artefacts ?

thanks

Hi had the same issue.

I've also compiled myself from git and had the same problems.

In my case kodi was complaining about a missing python lib. (I believe pyhton was updated to 3.9 a couple of days ago).

Similar to a problem I had reported in another thread,

I've SOLVED the issue by "make clean" and re-building everything.

Everything is stable now with the last source versions.

As I do not know how the nighlty builds are made,

I humbly suggest to the team to re-build them from scratch.

well ...

reverted the patch .. works.

placed the patch back and it also works !!!

if ..... "make clean" and recompile everything

So, after the changes for 5.15.17 / 5.15.18 I should have rebuild everything.

my bad.

sorry.

everything is working ok.

smp , thank you for your suggestion it sent me in the correct path.

Quote from smp

I assume you are using rpi kernel 5.15.18.

Looking at the git commit history it looks like this commit was merged to kernel 5.15.17, so you may want to revert it for testing.

Correct. 5.15.18 it is.

I will then try swapping the initialization bits for si2157 , recompile and report back.

[FALSE PROBLEM ---- IGNORE THIS POST]

well ... drivers are no working anymore.

I've updated the patch file as the offsets changed (see attach) and it worked for builds compiled with version up to 2nd February 2022.

After that, tvheadend cannot lock signal.

dmesg reports errors:

si2183 22-0067: err restarting dsp
si2183 22-0067: err set agc mode
si2183 22-0067: err set dvb-c mode
si2183 22-0067: err restarting dsp

Any help will be greatly appreciated.

linux-tbs5520se.patch.txt

Hi

I’ve just compiled the current master branch in GitHub and been watching live tv (hd 25 fps) and deinterlace is working great.

Watched movies, car races and a football match.

Awesome.

Thank you to all devs 😁

I've been using LE 9.2.X for quite some time with ssd access via key pairs.

I've started some tests with one of the last nightlty builds of LE10, and after following the same steps to activate the usage of the keys as with LE9, ssh keeps refusing the connection with this error reported in journal:

userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedAlgorithms [preauth]

Any suggestions ?

Thanks

well ... the faster I asked the faster I got the answer 😁

Anyway, here is the solution to help whoever may need:

It was just a question of updating putty (the ssh client I use) to the last version (0.77 worked ok).

Pino GPIO3 (pin 5) --> GND (pin 6)

add to /boot/config.txt

dtoverlay=gpio-shutdown

Grounding GPIO3 starts the clean shutdown process.

After shutdown, grounding again power on the RPI.

But .... Librelec will display a confirmation dialog for shutdown.

To bypass that:

edit:

/storage/.kodi/userdata/keymaps/gen.xml

add:

<keymap>

<global>

<keyboard>

<key id="61662">Shutdown</key>

</keyboard>

</global>

I believe all this is already in the forum.

Quote from chewitt

deinterlace support was merged into LE11 nightlies a week or so ago, it is not in the LE10 codebase at this time.

I've compiled one of the nightlies but did not found any usable change at deinterlace level with RPI4.

Is there any additional compliation option I should have used ?

For LE9 i use the "Raspberry Pi VNC" addon ( which uses dispmanx)

But as referred by CvH, VNC stopped working in LE10.

A side note: In Raspberry Official OS, Real VNC works fine, don't know if it is possible to port it to LE10 ....

well ... I don't know in fact what to say...

I understand the difficulties and the need to wait.

I will probably continue with 9.2.8 in my main RPI4 andm and keep LE10 in the RPI4 testing.

For movie watching, netflix, tv series, LE10 is just great.

But for live TV, I've tried to disable DRM PRIME and force (software) deinterlacing, but

but unless I'm doing something wrong, it is not watcheable

there's an obvious lag, and probably the RPI4 is not able do do software deinterlacing with 1080i @ 50hz live tv.

Any sugestions / tweaks ?

yes. changes now go into linux-aarch64.conf.

I'veupdated the compiled drivers and upload them.

Available here:

https://mega.nz/folder/cbwCARoR#jPgzah63psSCOtrwbt9gnQ

I've been using this pack for a while. small, simple, without external dependencies or versions.

It does the job.

A great compliment for tvheadend on-the-fly transcoding.

With a transcoding web interface.

ffmpeg and nginx compiled with the more recent official sources.

Though it was a good idea to share it with the community.

You are free to use (or not).

Thanks

yes. but this addon was made to work also on LE10 - the compiled ffmpeg version has all the libs included for using omx and mmal for hw encoding acceleration, giving the on-fly transcoding for the proposed server

This addon is more than ffmpeg:

It is a full transcode server with a ready to use configuration and user interface to help you serve your local content to an external device (example: stream from your pi --> ipad on the run).

It includes ffmpeg and nginx in order to have everything together in just one add-on without external dependencies.

Quote from CvH

isn't the included ffmpegx (ffpge-tools) already compiled with everything that it works with rpi transcode ?

For what I've seen in the past, omx and mmal weren't included.