Posts by chewitt

Thread renamed and commented to remove the name of the pirate addon. No support for pirates in this forum.

I'm fuzzy on the precise details in some areas ( popcornmix can probably describe things more accurately) but I think this is broadly what's happening:

The H264 hardware decoder supports a maximum 1920x1080 resolution on both boards (RPi4 inherited the same IP block as RPi3) and you are trying to play 2560x1440 resolution media on a 1024x768 monitor. As hardware decoding cannot be used because the resolution is too large the boards fall back to software decoding + resizing to match the output resolution + adjusting from 15fps to 60fps refresh rate (the only easy bit). RPi4 has the CPU grunt for the task so you see output. I'm unsure why RPi3 shows a blank screen where RPi4 shows output, but this is probably due to a capability difference between RPi3 (1080p max) and RPi4 (4K capable) so display pipelines are not equial. Disabling DRMPRIME in Kodi disables hardware decode and changes rendering in the kernel DRM layer; hence you now see something on RPi3 instead of nothing, but I'd guess it's still beyond the capabilities elsewhere in the pipeline so it's not usable output.

Quote from acamas125

I'm using this sports add-on to watch live NBA games. There are links called Home and Away. Most of the time when I click on that, it's either LE will crashed or playback failed will appear. While Kodi on Windows 11, the video plays almost instantly.

In the absence of any technical information (crash logs or such) I consulted my son's magic 8-ball, and it said "it is certain" .. so there's your answer

Quote from osflake

Please tell me what is wrong, what I done wrong.

No clue. Update firmware. Check cables. Check ports. Usual stuff .. and don't assume I'm your personal support person. I'm not.

The board pic posted in the Armbian forum doesn't show the WiFi chip on the board. Yours is a Silicon Village "SV6256P" but no guarantee what the other user had (might be the same, might be Realtek, etc).

Searching on GitHub finds a few "ssv6x5x" drivers, but some of them are tagged as being usable with Linux 4.4 (as used in older downstream Allwinner kernels) and there are substantial crypto changes since then which mean drivers will not forward-port onto the modern upstream kernels that LE uses. You might find newer ones, or you might not

NB: Even if you do find a newer one, LE will not add support for downstream drivers that have no visible hope of being upstreamed to the kernel; we've only just managed to exorcise the last downstream Realtek drivers from our codebase. You're welcome to self-build custom images with your own driver changes though.

Quote from Fritzables

I installed Kodi Omega and the Diggz Xenon build

This is admittedly on the Firestick not the RPi board, but pirates are pirates. Good luck with your problem somewhere else.

2025-03-31 21:27:16.485 T:1163    debug <general>: CActiveAESink::OpenSink - trying to open device ALSA:hdmi:CARD=PCH,DEV=0
2025-03-31 21:27:16.485 T:1163     info <general>: CAESinkALSA::Initialize - Attempting to open device "hdmi:CARD=PCH,DEV=0"
2025-03-31 21:27:16.486 T:1163     info <general>: CAESinkALSA::Initialize - Opened device "hdmi:CARD=PCH,DEV=0,AES0=0x04,AES1=0x82,AES2=0x00,AES3=0x00"
2025-03-31 21:27:16.486 T:1163     info <general>: CAESinkALSA::InitializeHW - Your hardware does not support AE_FMT_FLOAT, trying other formats
2025-03-31 21:27:16.486 T:1163     info <general>: CAESinkALSA::InitializeHW - Using data format AE_FMT_S32NE
2025-03-31 21:27:16.486 T:1163    debug <general>: CAESinkALSA::InitializeHW - Request: periodSize 2205, bufferSize 8820
2025-03-31 21:27:16.486 T:1163    debug <general>: CAESinkALSA::InitializeHW - Got: periodSize 2205, bufferSize 8820
2025-03-31 21:27:16.486 T:1163    debug <general>: CAESinkALSA::InitializeHW - Setting timeout to 200 ms
2025-03-31 21:27:16.486 T:1163    debug <general>: CAESinkALSA::GetChannelLayout - Input Channel Count: 2 Output Channel Count: 2
2025-03-31 21:27:16.486 T:1163    debug <general>: CAESinkALSA::GetChannelLayout - Requested Layout: FL, FR
2025-03-31 21:27:16.486 T:1163    debug <general>: CAESinkALSA::GetChannelLayout - Got Layout: UNKNOWN1, UNKNOWN1 (ALSA: UNKNOWN UNKNOWN)
2025-03-31 21:27:16.487 T:1163    error <general>: CActiveAESink::OpenSink - no sink was returned
2025-03-31 21:27:16.487 T:1162    error <general>: ActiveAE::InitSink - returned error
2025-03-31 21:27:16.546 T:1260  warning <general>: OutputPicture - timeout waiting for buffer
2025-03-31 21:27:16.987 T:1163     info <general>: Skipped 6 duplicate messages..

The initial file played (Cosmos s01e11) seems to evaluate/read from NFS storage okay but Kodi then ends up repeatedly attempting to setup the audio output sink and never succeeding with content like this ^

The connected HDMI device is a monitor that only supports 1920x1080@60? - Does it have speakers? - It's rather unusual to see no ELD data (from EDID on the HDMI connection) returning info on speaker placement options:

2025-03-31 21:26:34.536 T:1162    debug <general>: CAESinkALSA - HDMI device "hdmi:CARD=PCH,DEV=0" may be unconnected (no ELD data)
2025-03-31 21:26:34.537 T:1162    debug <general>: CAESinkALSA - HDMI device "hdmi:CARD=PCH,DEV=1" may be unconnected (no ELD data)
2025-03-31 21:26:34.538 T:1162    debug <general>: CAESinkALSA - HDMI device "hdmi:CARD=PCH,DEV=2" may be unconnected (no ELD data)
2025-03-31 21:26:34.538 T:1162    debug <general>: CAESinkALSA - HDMI device "hdmi:CARD=PCH,DEV=3" may be unconnected (no ELD data)
2025-03-31 21:26:34.556 T:1162     info <general>: CAESinkALSA - No playback configurations available for device "surround21:CARD=HID,DEV=0"

The problem smells like bad/missing EDID data on the HDMI connection so I'd suggest experimenting with different HDMI ports on both ends, different HDMI cables, etc. - You can also update to an LE13 nightly but I rather doubt this is a software issue.

If something crashes the question is what/where?

If Kodi crashes (and then restarts itself) we need to see the Kodi crash log. It's useful if debug is enabled beforehand, but the main point is the crashlog will show what Kodi was doing when it crashed.

If it crashes at a lower level there will be some kind of info or kernel splat in the systemd journal, and we need to see that no a Kodi debug log.

Generic uses a different install flow to ARM SoC boards like Raspberry Pi where you write the image direct to boot media. Generic expects to boot from an install USB which installs LE to a formatted (as anything) spare storage device; normally an internal drive but can also be another USB stick. You've written the installer to the target device, but the installer cannot install to itself when its the active boot device (and there are correctly no other devices to install-to found). The workaround is to interrupt boot at the syslinux stage and type 'run' instead of booting into the installer; the 'run' (from USB) mode should expand the storage partition to 100% size and then boot into Kodi. You end up at the same destination but having taken a different route.

Kodi saves settings on shutdown and if you trigger a hard crash before exit that doesn't happen. So not saving settings is normal and expected in that scenario. The crash would be more interesting .. but the log you've shared looks like the log on startup (after the crash) rather than the actual crash log, and debug is not enabled, so there are no obvious clues to the failure. In future use the native paste function so can click a URL instead of having to download and open log files.

The only things that do stand out are:

a) The huge number of add-ons installed and these are often the source of instabilities and random issues. I'd suggest stopping Kodi, renaming /storage/.kodi to /storage/.kodi-old and then restarting with a clean instance and then progressively migrating a more minimal config back. Stick with the default Estuary skin to eliminate the demands of super-heavy skins.

b) The pirate IPTV feed with 15,000+ channels (no legal feed has that many) which results in a huge amount of additional processing when attempting to use DVB and EPG functions. Kodi works great with hundreds of channels, it doesn't work so great with that kind of feed size. That's a self-inflicted problem though .. and I lost interest in looking further.

Merged.

Quote from yamcenutzer

BTW, why did you single out that one warning line about waiting for a buffer? What does that tell you?

Da Flex has an obsession with buffering and frequently flags it for no discernable reason

I'm not seeing anything in the log. The relevant streams are being selected and Kodi outputs RAW to the HDMI device. Make sure the HDMI port's involved (on TV and AVR) support eARC, as sometimes it's only implemented on one of them.

It should work, but not all HDMI ports are eARC compatible, not all cables support HDMI 2.0+ modes, and NUC firmware continues to be a lottery so ensure the system BIOS and particularly any LSPCON chip firmware is at latest versions. If an LSPCON chip is used the output may need to be set to DP not HDMI as the LSPCON chip converts DP to HDMI for output (which is cheaper than wiring up the native HDMI outputs). If none of the above ..

You can't install it (there is no package manager) but you can self-build an image with the driver patched into the kernel. There are some threads around the discuss the process.

I'm waiting for Kwiboo to finish with u-boot support. Once that's done we'll ship an image using whatever codecs are upstream and everything else using software decode, and then periodic kernel bumps will bring more codecs and features over time. I will go nag Jonas again..

Da Flex it's not a different architecture.

rolapinou Basically correct. I would clean install then add sources.xml and check the SMB access is working fine. Then I would stop Kodi and move the SQL database config to advancedsettings.xml and restart Kodi to start the DB migration. I doubt there's much else that can or should be reused from the older install, perhaps some addon settings from userdata.

Note that current Kodi requires MySQL/MariaDB v5.7 or newer so check the version on the Synology first. I'd also SSH in to tail the kodi.log file to check for errors during the DB migration as it will need to step through quite a few versions and will take time.