Posts by GDPR-7

shouldn't that be

systemctl restart wpa_supplicant.service

and to check if started:

systemctl status wpa_supplicant.service

Quote from vhgroup

While switching things on and off, I may have had both wifi and internet enabled. Is this a problem? Obviously the system only connects to one at a time?

but switching connections needs some time and that could cause your problem.

- but usually it should stay with the strongest connection, usually LAN -

anyway, you could in an console let

journal -f

running to see if playback issues happens at the same time when connection switches (if they do at all)

thanks HiassofT for lightning fast response !

I'll close this thread/report

- no expert here -

grepping your log for "avg speed" it seems the speed varies a lot.

Question:

streaming via wifi ?

2^cd:

^...

^{connect replacing configured host mysql-pi01 with resolved host 192.168.1.177}

^...

^{I guess you're running a mysql db/server ?}

^{I wonder why it needs to resolv the IP Address ever and ever again.}

^{mysql config problem ?}

^{- but as said: no expert here -}

not a real bug just a headup/hint, cause the box runs well with it.

I see this in my log with dmesg:

...

[ 0.024310] Kernel command line: root=/dev/ram0 rdinit=/init usbcore.autosuspend=-1 BOOT_IMAGE=/KERNEL boot=UUID=1BD6-475D disk=UUID=d90fcae6-4a95-436b-807c-b61b8355cb56 i915.enable_guc=2 quiet

[ 0.024354] Setting dangerous option i915.enable_guc - tainting kernel

[ 0.024363] Unknown kernel command line parameters "BOOT_IMAGE=/KERNEL boot=UUID=1BD6-475D disk=UUID=d90fcae6-4a95-436b-807c-b61b8355cb56", will be passed to user space.

...

Quote from powerarmour

...fall back to VAAPI, is HW decoding shown then?

of course it is !

and that *is* the main point for opening this thread:

having usually HW decoding and additionally switching "hardware acceleration with DRM PRIME" ON shouldn't switch all HW decoding OFF

with DRM PRIME off: HW decoding is enable/active for h264 (see attachment below)

with DRM PRIME on: HW decoding is disabled/in-active for h264 (see attachment im comment #1)

Quote from chewitt

not all hardware will support all media/codec types for hardware decode, and when something is not possible we fall back to software (CPU) decode

according to this:

Intel Graphics Technology - Wikipedia

en.wikipedia.org

scroll to:

=> "Hardware-accelerated algorithms"

=> "...Coffee Lake..."

my GPU is/should be able to decode h264 in hardware and therefore is makes me wonder it does not when "Allow hardware acceleration..." is on.

AFAIK "DRM PRIME" does some "offload" the GPU, but putting all load on the CPU is to be sure the most "GPU offload" one could get, but not what one would expect.

I guess I need to read/learn more on this stuff !

any pointer ?

I don't regret having bought the NUC.

but it's some work with this NUC to find the right compromise for cooling (ventilator speed) and heat

thanks powerarmour

it's a NUC8 with Iris Plus Graphics 655

sorry, codec, profile, xybit, is currently "a number to high" for me

it's sufficing to know if I "unexpected regarding the wording" get more load on my CPU when "Allow hardware acceleration with DRM PRIME" is on.

I guess that's the case ?!

NUC: cooling <=> loudness !!!

cause "ps aux | grep kodi" returns 2 values and that's a "beloved" mistake ?

without seeing your script it's a wild guess what doesn't work ...

anyway:

pgrep kodi.bin ?

or

pgrep kodi.sh

parameter:

pgrep --help

running generic nightly on an NUC8

as you can see I activated "Allow hardware acceleration with DRM PRIME" (1^st photo) and I'm running german HD-TV (2^cd photo)

questions:

why do I see "ff-h264-drm_prime (SW) ?

does it mean all GPU-HW-Features are switched off ?

any pointer to fresh up my knowledge ?

thanks mglae looking into this and letting me know.

to me it's not that dramatically what need a (*urgent*) fix, its seems to be sufficing that the developers are aware of this.

I mark this thread as ~resolved~

Okay ?

thanks heitbaum

btw: last nightly with kernel 5.16 is running well (here), thanks

msderganc thanks for response

what I can find is this:

[SOLVED] No Graphic Driver Offered for Gigabyte Brix GB-BMCE-5105 - Linux Mint Forums

long story short:

it seems you need a newer kernel, what is in nightly.

and that's here:

Index of /

key in "gen" in the grey box to filter the images for your device

I wonder how you were able to install LE ?!

shouldn't it be: "same kernel, same (driver-)fun" ?

*I* would also check for a new BIOS:

GB-BMCE-5105 (rev. 1.0) Unterstützung | Mini-PC Barebone (BRIX) - GIGABYTE Germany

=> F4 from 2021.07.29

=> "BIOS Fixed : Random Boot Failures issus"

that's might answer my question ...

Omina did check the Volumen Control on the TV too ?

Quote from mglae

Up to (and including) their 10th generation Comet Lake processors Intel only have HDMI 1.4 interfaces implemented. For HDMI 2.0 output the LSPCon Display Port to HDMI converter are used and required. ...

slighty OT, but out of interest:

it seems Intel uses a sorta LS and PCon in some NUC11 too:

scroll to the picture "Block diagram" 

Intel NUC 11 Performance Kit - NUC11PAHi5 - Panther Canyon (RNUC11PAHI50002) ab € 540,75 (2022) | heise online Preisvergleich / Deutschland

=> PCON

and

Intel NUC 11 Pro Kit NUC11TNHi7 - Tiger Canyon (BNUC11TNHI70002) ab € 649,93 (2022) | heise online Preisvergleich / Deutschland

=> PCON and LS/Retimer

were I translate:

PCon := protocol converter

LS:= level shifter

LSPCon:= Level Shifter/Protocol Converter

I wonder what heitbaum (owner of an NUC11; (11 right ?)) see if he connects his display via HDMI and "tail /sys/class/drm/*/status"

Quote from HorzaSe

I guess I could try the Nightly 11 but they seem pretty flakey.

running nightly since some weeks (and btw. the above output is from nighty too):

nothing flakey here.

I've no idea why the kernel ~sees~ the HDMI Port as inactive when only HDMI is connected.

things might change if we see in LE a 5.16 kernel (a lot of GPU driver work went in)

at least on my desktop (i5-11400, UHD Graphics 730, MB: B560 Chipset) connect via HDMI it looks like this [1]:

tail /sys/class/drm/*/status:

==> /sys/class/drm/card1-DP-1/status <==

disconnected

==> /sys/class/drm/card1-HDMI-A-1/status <==

disconnected

==> /sys/class/drm/card1-HDMI-A-2/status <==

connected

[1]

so far I couldn't figure if my desktop has a LSPCon too...

Quote from HorzaSe

If I disconnect HDMI, the DP-1 is disconnected and when HDMI reattached it shows DP-1 is connected again.

weird

according to this doc:

https://objects.icecat.biz/objects/mmo_36674449_1496735571_8567_29150.pdf

page 21

one internal DP goes through an ~"DP to HDMI converter"~ (LSPCON)

and the other two through an "PCIe-Data-lane-multiplexer (?)" to an USB-C (Data/Display signal)

from my NUC (also with an LSPCON) connected via HDMI (-cable)

tail /sys/class/drm/*/status

==> /sys/class/drm/card0-DP-1/status <==

connected

==> /sys/class/drm/card0-DP-2/status <==

disconnected

==> /sys/class/drm/card0-HDMI-A-1/status <==

disconnected