[TESTING] Kodi v19 builds for Raspberry Pi 2/3/4

Nope, it doesn’t. Running hdparm gives the same result. But…it’s the same on OSMC on rPi 3b, with the same hub with the same drives connected. Kodi indeed starts before the drives are mounted and once GUI is on on Rpi3 oSMC , there are messages indicating the drives are mounted one by one.
Anyways, here are the debug logs:

  1. Rpi4 Bad - When boot is stuck. but accessibe via SSH: https://paste.osmc.tv/fodisogatu
  2. Rpi4 Bad - Same session, after mediacenter restart and GUI is ON: https://paste.osmc.tv/oyemawicom
  3. Rpi4 Good - Starting withou the hub connected: https://paste.osmc.tv/ukowefezip
  4. Rpi3 Good - for the sake of experiment, the log from Rpi 3b OSMC, with the latest “legacy” update, the same hub is connected: https://paste.osmc.tv/mujelakudi

Hopefully it’ll help.

+1 for the problem, I got that too

@sam_nazarko hey Sam, did you by any chance had a look on this problem? (The responded message concerning 4k60 on rp4)

No - I suspect it’s an upstream issue.

I wouldn’t worry too much about those SG_IO: bad/missing sense data messages from hdparm. They’re probably related to a limitation of the USB to SATA interface, rather than being caused by a faulty disk (they all seem to produce the message).

I’m guessing that Kodi is starting too quickly and the external disks are starting too slowly.

Just as proof-of-concept test, edit the file /lib/systemd/system/mediacenter.service (using sudo) and add this line in the [Service] section:

ExecStartPre=/bin/sleep 30

This should allow the system 30 seconds for the disks to mount before Kodi starts.

Reboot and see if it helps. (If not, it’s probably worth also trying 60 seconds.)

Could you elaborate what does an upstream issue means?

Thank you

Alright, that does it. Turned out 15 sec is enough, 10 is not. Thanks !

Well would be interesting to see if it is a Pi4 or a new Kernel / Kodi v19 issue.
When you have time maybe you can try a cloned SD in the Pi3 with Kodi v19 installed.

Device :raspberry pi 4b
Issue: after changing sbm version from sbm 3 to sbm 2 , it asks me to restart and when click restart it stucks on the image with the kodi and the screen doesn’t not closes (been waiting 20 mins to restart) and the only way to restart and make osmc usable again is to reboot through ssh

Hey @sam_nazarko upgraded another 3B+ recently. Upgrade went perfectly. Currently feels a lot snappier and the GUI looks sharper and feels more responsive.

Audio seems clearer and sharper. These are all subjective comments I know but that is the real world of these devices. Mostly they are plugged into 4K Samsung or Sony TV’s with just a few 1080P TV’s left.

No complaints from the users of that one yet or the previous one which we updated yesterday. Everything they have clicked on played perfectly. We are not at the cutting edge of formats. We are generally of the opinion that 1080P is mostly good enough and the TV’s do a great job of enhancing the video. We have 000’s of DVD’s in our library and also 000’s of TV shows. I am sure we’ll find a few problematic ones.

Keep up the great work OSMC rocks the PI!

Cheers
Spart

1 Like

We’re not finished yet. You just confirmed my hypothesis but the next time Sam pushes an update to the mediacenter package, you’ll lose the change. So to make it permanent, I’d recommend that you create a systemd “drop in”.

sudo mkdir /etc/systemd/system/mediacenter.service.d
sudo nano /etc/systemd/system/mediacenter.service.d/sleep.conf  

In the file, paste these two lines:

[Service]
ExecStartPre=/bin/sleep 15

Remove the line from /lib/systemd/system/mediacenter.service, then reboot.

There are probably more elegant ways of fixing the issue, but a “cheap ‘n’ cheerful” hack should be enough in this case.

It means it is not an OSMC issue.

Audio will be the same as existing Pi models.

We won’t support HBR audio passthrough until Debian Bullseye is released and we move to that (2022).

Some AVRs are clever enough not to need the new ALSA libs which will come with the new Debian version, but this is not common.

It works, thanks!

Kodi v19.1 was released yesterday with a bunch of fixes and various linux builds are now available. Wondering if we are gettting near with OSMC :slight_smile:

This is already shipping - but it won’t be released as stable for a while yet, it’s still a test build.

1 Like

Вы {только|просто} подтвердили мою гипотезу.

It’s good enough for me, thank you.

Hi,
I have one more issue I have been testing on over the weekend but where I can’t get to a solution myself. It is on a Raspberry 3B.
Issue: Whenever I start OSMC without my TV on, the system does not start up. It also does not shut down properly when saying “shutdown” and then turning off the TV before the system is fully shut down.
What I tested:

  • Turned off HDMI CEC → did not help
  • Tried to access via SSH when system “hanged up” or after start without TV on → No access possible
  • Turned on the TV a few seconds after boot → system starts
  • Plugged out HDMI cable after OSMC booted and plug in again after 1 minute → OSMC stays alive
  • Turned off TV after OSMC booted and turned on again after 1 minute → OSMC stays alive
  • Added hdmi_force_hotplug=1 to config.txt and user-config.txt → no change

It feels like OSMC does not start up or does not shut down properly without an active HDMI connection, but once it started, I can do whatever I want. I first thought it is an issue with boot or CEC, but as it also does not shut down properly when turning off the TV, I suppose the issue is somewhere else.
I have been separately trying around with cec-utils separately via SSH (after stopping mediacenter via SSH) and when I put the TV into standby via SSH command line, the system crashes.
I tried to look into logs, but as I can’t access via SSH after hang-up and logs (as far as I understand) are deleted after reboot, I failed to do so far.

Does anyone here experience a similar issue on a RPi3 or has a hint to guide me in the right direction? That would help me in narrowing down whether it is only on my side or potentially a general bug.

Thank you and best regards

sebir

That’s expected with Pi and new DRM mode setting logic.

Hardcode and EDID or ensure your TV equipment is on when booting.