Posts by chewitt
-
-
Code
Display More2025-11-01 10:48:10.652 T:1208 info <general>: ffmpeg[0x212e50a0]: [https] Opening 'https://ed0-as2119.cdn.svt.se/l1/se/svt1/19a2a5efb80/cmaf-audio-aac-sv-tts-2ch-130/cmaf-audio-aac-sv-tts-2ch-130-init.mp4' for reading 2025-11-01 10:48:10.653 T:1208 info <general>: ffmpeg[0x212e50a0]: [hls] Opening 'https://ed0-as2119.cdn.svt.se/l1/se/svt1/19a2a5efb80/cmaf-audio-aac-sv-tts-2ch-130/cmaf-audio-aac-sv-tts-2ch-130-107195.mp4' for reading ... 2025-11-01 10:48:10.770 T:1208 info <general>: ffmpeg[0x212e50a0]: [hls] No longer receiving playlist 3 ('https://ed0-as2119.cdn.svt.se/l1/se/svt1/19a2a5efb80/cmaf-video-avc-448x252p50-1100/cmaf-video-avc-448x252p50-1100.m3u8') ... 2025-11-01 10:48:10.778 T:1208 info <general>: ffmpeg[0x212e50a0]: [https] Opening 'https://ed0-as2119.cdn.svt.se/l1/se/svt1/19a2a5efb80/cmaf-video-avc-1920x1080p50-6000/cmaf-video-avc-1920x1080p50-6000-107196.mp4' for reading ... 2025-11-01 10:48:10.908 T:1044 debug <general>: ActiveAE::SyncStream - average error of -35.808218, start adjusting 2025-11-01 10:48:10.908 T:1044 debug <general>: ActiveAE::SyncStream - average error -0.016552 below threshold of 30.000000 ... 2025-11-01 10:48:13.342 T:1214 debug <general>: CPtsTracker: detected pattern of length 1: 19999.99, frameduration: 20000.000000 2025-11-01 10:48:13.771 T:1215 info <general>: CVideoPlayerAudio::Process - stream stalled 2025-11-01 10:48:14.174 T:1214 debug <general>: CDVDVideoCodecDRMPRIME::GetPicture - flush buffers ... 2025-11-01 10:48:14.480 T:1208 info <general>: ffmpeg[0x212e50a0]: [https] Opening 'https://ed0-as2119.cdn.svt.se/l1/se/svt1/19a2a5efb80/cmaf-video-avc-1920x1080p50-6000/cmaf-video-avc-1920x1080p50-6000-init.mp4' for reading 2025-11-01 10:48:14.483 T:1208 info <general>: ffmpeg[0x212e50a0]: [hls] Opening 'https://ed0-as2119.cdn.svt.se/l1/se/svt1/19a2a5efb80/cmaf-video-avc-1920x1080p50-6000/cmaf-video-avc-1920x1080p50-6000-107197.mp4' for reading 2025-11-01 10:48:14.784 T:1214 debug <general>: CPtsTracker: pattern lost on diff 3200000.000000, number of losses 1 2025-11-01 10:48:15.308 T:1214 warning <general>: OutputPicture - timeout waiting for buffer ... 2025-11-01 10:48:15.842 T:1214 warning <general>: OutputPicture - timeout waiting for buffer ... 2025-11-01 10:48:16.375 T:1214 warning <general>: OutputPicture - timeout waiting for buffer 2025-11-01 10:48:17.719 T:1042 info <general>: Skipped 1 duplicate messages.. 2025-11-01 10:48:17.719 T:1042 debug <general>: CLibInputKeyboard::ProcessKey - using delay: 500ms repeat: 33ms 2025-11-01 10:48:17.719 T:1224 debug <general>: Thread Timer start, auto delete: false 2025-11-01 10:48:17.743 T:1037 debug <general>: Keyboard: scancode: 0x2d, sym: 0x78 (x), unicode: 0x78, modifier: 0x0 2025-11-01 10:48:17.743 T:1037 debug <general>: HandleKey: x (0xf058) pressed, window 12005, action is StopI'm not an expert in reading streaming service logs (and different services will behave differently) but it looks like audio and video are separate streams, and everything goes through a normal looking process of obtaining stream manifestsa and then selecting audio and video streams. The audio stream looks to be selected, but then the video stream switches from SD (448x252@50) to HD (1080p@50) and then the stream stalls.
There are quite a lot of streaming add-ons installed so I would be interested to see logs from a current LE13 nightly that has only the SVT play and inputstream.adaptive add-ons installed. I'm not expecting anything to be different, but it will remove some noise from the log. I don't see any 'errors' that would e.g. indicate Python issues or something that traces back to the underlying OS. IMHO if there's a difference between the add-on under LE and the add-on the author tested on Ubuntu it's more likely to be add-on or i.a configuration and not the OS environment.
NB: The stream is H264 and RPi5 does not have H264 hardware decode or hardware deinterlacing so the v4l2_m2m errors in the log that Da Flex has seized upon are nothing more than ffmpeg correctly failing to find hardware decode and deinterlace /dev/video nodes that don't exist and failing back to use software capabilities. All normal and expected on an RPi5 device.
-
If you want to run Kodi in a container, go find a container that runs Kodi: https://hub.docker.com/search?q=kodi
-
I'm using 'black' as the screensaver with a variety of ARM SoC boards since forever and nothing has changed. I'm admittedly using LE13 images for a long time now but when I was using LE12 in the past (and LE12.2 is based on the same Kodi codebase/version) it worked fine. The description of "First couple of seconds it's dark grey, then pitch black" sounds more like the TV having an issue.
-
I'd argue the bug is not strictly adhering to the logic of using DHCP .. OR .. manual configuration, i.e. If you switch from DHCP to manual I would expect that the correct action is forcing the user to (re)define everything from scratch. That's probably an issue with our implementation of a ConnMan agent, and something to fix.
-
The codebases are different, but the kernel media capabilities are essentially the same and largely untouched since 2020.
-
The differences between RK3588 and RK3588S are minor and handled in the upstream kernel for a long time already.
-
a) LibreELEC does not support S928X hardware
b) This is not a forum for recovering Android boxes
c)

-
-
-
I'm not sure if this ^ is the same as the evalation (evb) boards present in u-boot/kernel, but if I was building an image to experiment from that would be my starting point. That said, device-tree changes/improvements to RK boards in the kernel seem to be made on a very individual basis (no bulk enablements etc.) so you may also find the evb files need some fixups; they are inherently often the first board to be added for each SoC type, and then development focus quickly switches to commercially available boards, so the evb boards fall behind current driver capabilities over time.
-
To understand what's happening you'll need to share the serial UART output from u-boot (needs a USB UART cable) and then the kernel or system log.
-
I think I was half-asleep this morning..
-
The issue is nothing more than packaging. Some binaries need to be deleted from build infra, and then rebuilt. No change to the release tag.
-
Someone wrote that it might be a problem with initializing in time.
It's not impossible, but given this is RPi, I'd expect the firmware to be tolerant of that kind of thing.
If it continues to work fine (after reimaging) it's just another random SD card event.
-
What advantages are there using LE 13 nightly on le potato compared to LE 12.2(1) stable?
None. Both are equally unfunctional

-
Make /flash writeable with mount -o remount,rw /flash then edit /flash/syslinux.cfg in nano and append ^ to kernel boot params (put everything on a single line). Reboot with the HDMI cable connected to HDMI-A-1 and see if forcing the initial DRM connector state to 1080@60 solves the problem?
If not, create /storage/.kodi/userdata/advancedsettings.xml with the content below and reboot:
-
SSH in and run ^ after boot. It will dump the initial log to file then tail/append future journal content to the same file. Now go start something playing until it hangs. The logging task will die when the system hangs but the file will remain on-disk after you power cycle and log back in. Then do:
a) cat /storage/journal.log | paste
b) cat /storage/.kodi/temp/kodi.old.log | paste
Share the URL's and if you're lucky there's a trace of something in the system log that correlates to the kodi old log.