00:24 <cyph84> chewitt: thanks!

01:11 <cyph84> chewitt: can you pull https://github.com/libre-computer-project/libretech-linux/commit/01ad134081bed0e24e9dd54038e406fccd2164d3 and https://github.com/libre-computer-project/libretech-linux/commit/6e91d124deb8effff1dd73e0564bbe1b94dcecd6 into your tree? I am having problems connecting to ethernet coz of that

05:59 <LEBot> [slack] <chewitt> cyph84: have those been posted to a mailing list anywhere yet? .. the convo on how to resolve some of the issues with ethernet on specific boards has been running for ages and since Ethernet generally works in most places I’m not too interested in patches that haven’t gone through upstream review (and ideally merge)

06:02 <LEBot> [slack] <chewitt> there are also more patches in that series

06:03 <LEBot> [slack] <chewitt> I’m not seeing them on any mailing lists

06:44 <cyph84> chewitt: not sure, but it definitely resolves it on Le potato. i think there was some discussion on armbian forums

06:45 <cyph84> chewitt: alternatively, i find that running ethtool --set-eee eth0 eee off solves this problem

06:49 <cyph84> i think the current view is the hack works, but its not upstreamable

06:52 <LEBot> [slack] <chewitt> I’ll ping Da (who runs LibreComputer) to ask what’s the plan

08:03 <cyph84> chewitt: i am not sure about your experience, but i have to get up to unplug/replug the ethernet cable on every reboot

09:05 <LEBot> [slack] <chewitt> I have that on an S905D box that uses internal_phy (10/100) but I don’t see it anywhere else; probably because they all have external phy

09:06 <LEBot> [slack] <chewitt> I don’t use LePotato often these days, as other boards have more interesting problems to poke 🙂

09:09 <LEBot> [slack] <chewitt> I’ll do some testing in the week .. last day of summer vacation (and travels home) to be completed first :)

09:36 <LEBot> [slack] <chewitt> cyph84: updated 5.19.y branch pushed to github and fresh images on my test share

09:36 <LEBot> [slack] <chewitt> I spoke with Da .. and I might as well test and see if anyone complains of things breaking or working

09:38 <cyph84> chewitt: thanks!! i am rebooting so often as i am trying to figure out a bug with analog audio on armbian. trying to compare it with LE. it seems to be extremely prone to race conditions

09:46 <cyph84> chewitt: i've also increased the value on this line from 5 to 7:  https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/meson/meson_overlay.c#L182 without that kodi gives a black screen when you try to play VCD sized videos. narmstrong seems to suggest there is a limit in the hardware, but 5 is an arbitrary number

10:43 <LEBot> [slack] <chewitt> there are lots of magic values scattered around Amlogic code 🙂

10:44 <LEBot> [slack] <chewitt> can you share a suitable test video so that I can look at that

10:51 <cyph84> chewitt: sigh yes... let me find one thats public domain

10:54 <cyph84> chewitt: https://sample-videos.com/video123/mp4/240/big_buck_bunny_240p_30mb.mp4 this should give you a black screen on LE on Amlogic boards

10:59 <cyph84> chewitt: you should also checkout what happens when you unplug/replug your HDMI cable. the alpha mask of the UI overlay gets shifted, though the overlay does not shift. so this results in black shadows to the right of every UI element. i've been digging through the code and registers with no idea what might be going on.

11:19 <LEBot> [slack] <chewitt> I’ve seen that with the OSD in Kodi where the dark shadow to text elements shifts by 1px each time you put the OSD on-screen.

11:22 <LEBot> [slack] <chewitt> It only happens under specific conditions though, and I haven’t seen it for a while

12:36 <cyph84> chewitt: testing with MPV, its pretty obvious there is always a shadow. depending on phase of the moon, it might be 1px, or 10px or more. it happens less on 1920x1080 ( which kodi uses). it shows up more if you're on 1280x720

12:57 <shibboleth> chewitt: ping (re the usb dac/audio issue i mentioned. i've been able to reliably reproduce the "bug")

13:05 <shibboleth> i'm running libreelec on rpi4 connected to an audio amplifier through usb (kmod snd_usb_audio). if, for any reason, there is an "audio stutter" (let's say i'm navigating the UI while playing video/audio causing a performance bottleneck) audio becomes unstable. most often it results in a lower volume and an equally "loud" "hiss" but sometimes the audio goes completely haywire producing the worst sound you've ever heard, enough to invert even

13:05 <shibboleth> the neighbors speakers. reboot required, then it'll be fine until the next time theres an audio stutter due to a perf bottleneck

13:05 <shibboleth> seems to only happen when an rpi is connected, tested with two pcs, windows, linux

13:06 <shibboleth> tried options snd_usb_audio nrpacks=1, options snd_usb_audio ignore_ctl_error=1 to no avail

13:25 <shibboleth> almost forgot, logs: https://paste.debian.net/hidden/cc79159e/. it happened at 22:01:00, nothing in kodi log, nothing in dmesg

13:56 <LEBot> [slack] <chewitt> shibboleth: best to post that to a GitHub issue so that the RPi devs can be pinged to look

13:58 <shibboleth> yeah... you know of any other relevant sources of info, are there alsa logs on le?

14:02 <shibboleth> also also: if i run LE at 1920x1080 because the monitor/tv is a lot better at upscaling sd/720/1080 to panel native 4k than the rpi is, will LE switch to actual 4k output when playing actual 4k content? or will it downscale 4k to 1080 and force the monitor to upscale it back?

14:02 <LEBot> [slack] <chewitt> You can experiment with Kodi component logging .. but I doubt it will reveal anything extra

14:02 <shibboleth> it's on, but debug is off atm

14:02 <LEBot> [slack] <chewitt> I’m not sure what components are optional there as I’m not anywhere near a box

14:03 <LEBot> [slack] <chewitt> re switching

14:03 <LEBot> [slack] <chewitt> it depends on what you have in the whitelist

14:03 <LEBot> [slack] <chewitt> as a rule Kodi does a good (and compute acceptable) job at upscaling to 1080p

14:04 <shibboleth> nothing whitelisted, buit "adjust refresh..." is on

14:04 <shibboleth> sure, but the tv wipes the floor with the rpi at sd/720/1080->4k

14:04 <LEBot> [slack] <chewitt> then it won’t actually do anything

14:05 <LEBot> [slack] <chewitt> whitelist 1080p @ 60/59.94/50/24/23.98 and the 4K modes

14:05 <shibboleth> ok, i'll try whitelisting the known suspects

14:05 <LEBot> [slack] <chewitt> note that I omitted 1080p @ 30/29.97 so you have can enable double rates which are needed for interlaced media

14:05 <LEBot> [slack] <chewitt> note that I omitted 1080p @ 30/29.97/25 so you have can enable double rates which are needed for interlaced media

14:06 <shibboleth> 10-4

14:06 <LEBot> [slack] <chewitt> also see if that resolves your audio glitching

14:06 <LEBot> [slack] <chewitt> playing stuff at the wrong refresh is always a compromise somewhere

14:07 <LEBot> [slack] <chewitt> once the 4k modes are listed and 1080p set for desktop it will switch as needed

14:07 <LEBot> [slack] <chewitt> FYI, https://wiki.libreelec.tv/configuration/4k-hdr

14:07 <LEBot> [slack] <chewitt> worth reading

14:07 <LEBot> [slack] <chewitt> (and saves me typing it again)

14:13 <shibboleth> i'll take a gander

14:13 <shibboleth> bbl, 30 minute-ish, dinner

15:29 <shibboleth> back. and then i renbale both 3:2 pulldown & double refresh?

15:29 <shibboleth> enable

15:36 <shibboleth> i can trust "fbset" to report actual hdmi out resolution, right?

15:37 <LEBot> [slack] <chewitt> 3:2 shouldn’t be needed, but double refresh should be checked

15:37 <LEBot> [slack] <chewitt> use the status/info button on the TV to report actual resolution

15:47 <shibboleth> there doesn't seem to be an option for the display to show current res/fps/info

15:47 <shibboleth> but i can clearly see the kodi UI being at a higher res when tabbing out while playing 4k content

15:48 <shibboleth> also, no audio breakage yet

15:53 <shibboleth> ok, i opened up the pvr epg and held "down" for 10 seconds, this would reliably reproduce the audio issue

15:54 <shibboleth> and the issue did occur, but now audio will recover by stop+replay channel

15:54 <shibboleth> how about them apples. thanks

15:56 <shibboleth> actually, stop+start diff channel->stop->start first channel. audio will be fine on diff channel and first channel but only if you've gone through diff channel

15:57 <shibboleth> first channel with issue - > stop -> first channel = issue remains, first channel with issue - > stop -> second channel = no issue -> stop -> first channel = no issue

15:58 <shibboleth> does this help narrow things down re likely culprit? makes me a happy camper, no three reboots an hour, but still