[Milhouse]

OpenELEC is going through a lot of change right now (mostly build system related) and I don't have the time to fix all the issues, so I've made the temporary decision to stop pulling OE updates while continuing to provide Kodi updates.

[thent]

[*]"Sync playback to display" now disabled by default

With the last build you'll probably find "Sync playback to display" is disabled.
Historically when "Sync playback to display" is disabled you may get stuttery playback.
This occurs when, by chance the presentation time occurs too close to the vsync.
That results in small amounts of jitter in the timing causing frames to either hit or miss the nearby vsync.
Each time you start, resume from pause, or seek the render time vs vsync changes, so may cause or cure the stuttering.

The last build always blocks until the next vsync before presenting frames. I'm hoping that will avoid the stutter,
but as the occurrence of the stutter is random and fairly rare it is hard to be sure.

Please report if you see stuttering that wasn't in the preceding build. Also report if enabling "Sync playback to display" helps.
Also report if you see any hangs during playback. The method for blocking until vsync has provoked hangs in the past, but I hope I've avoided that with this version.

Actually playback has significantly improved for me with "sync to display" disabled. I had many problems with some TV recordings with mp3 audio in the past, playback was mostly stuttering. Nevertheless codec info still counts a lot of skipped frames even with the latest builds, it's about 100 frames within 10 minutes. If you're interested I could upload a sample file.

[popcornmix]

Actually playback has significantly improved for me with "sync to display" disabled. I had many problems with some TV recordings with mp3 audio in the past, playback was mostly stuttering. Nevertheless codec info still counts a lot of skipped frames even with the latest builds, it's about 100 frames within 10 minutes. If you're interested I could upload a sample file.

Please do. Do you believe the frames are actually being skipped, or might it be falsely reporting the skips?

[thent]

Both. Most of them are falsely reports, but from time to time I still do observe real skips, every 30 seconds or so.
Testfile is here:
https://www.dropbox.com/s/14fdph2uxs7mzb...o.avi?dl=0

[popcornmix]

Both. Most of them are falsely reports, but from time to time I still do observe real skips, every 30 seconds or so.
Testfile is here:
https://www.dropbox.com/s/14fdph2uxs7mzb...o.avi?dl=0

Just tried it in my debug environent (MMAL, sync playback to display disabled) on a pi3 and "skip:" doesn't increase and it looks smooth.
It shows 2 skips from start of playback (or possibly bringing up the codec info overlay) but it's still on 2 at end.

There was some stutter investigation here and it seems lirc_rpi and a USB remote dongle were implicated in causing stutter. We'd like to work out what is happening there, but if you have any peripherals connected it might be worth testing with then removed.

[thent]

There was some stutter investigation here and it seems lirc_rpi and a USB remote dongle were implicated in causing stutter. We'd like to work out what is happening there, but if you have any peripherals connected it might be worth testing with then removed.

Thanks a lot for pointing me into that direction! You were actually right, I had a USB MCE remote (like this one) connected to my Pi2 and when I cut the cord, the frame skipping had stopped completely. This also improved playback for other files of mine, e.g. 1080p with AC3 and passthrough, or streamed amazon videos.

[popcornmix]

Thanks a lot for pointing me into that direction! You were actually right, I had a USB MCE remote (like this one) connected to my Pi2 and when I cut the cord, the frame skipping had stopped completely. This also improved playback for other files of mine, e.g. 1080p with AC3 and passthrough, or streamed amazon videos.

Okay that's interesting. I wonder if you could try adding:

Code:

dtoverlay=lirc-rpi

to config.txt (with the USB dongle still removed) and confirm if that also stutters. You don't need actual lirc hardware - there are reports of just that option causing stuttering with OSMC.
That's what I'm trying to use to reproduce the issue, but I'm not seeing it in my debug environment so far.

[thent]

Okay that's interesting. I wonder if you could try adding:

Code:

dtoverlay=lirc-rpi

to config.txt (with the USB dongle still removed) and confirm if that also stutters. You don't need actual lirc hardware - there are reports of just that option causing stuttering with OSMC.
That's what I'm trying to use to reproduce the issue, but I'm not seeing it in my debug environment so far.

The playback stays smooth and free of stuttering, I still see a few false reported frame skips, but much less than with the USB remote connected.

[fizbin]

You can only use one skin for testing and that's estuary.

Switching to the estuary skin did correct the inability to get to the CEC settings and the Pi rebooting, however the core issue still remains.

With CEC enabled, when I turn my TV off and back on again, it loses signal with the Pi.

Disabling CEC corrects that issue, but there is your proof that there is a bug with some new facet of CEC. Rolling back to Openelec 6 results in correct behavior, even with CEC enabled. It happens on 2 of my 3 TVs and at least 2 people have reported this issue on Kodi 17 Milhouse builds in this thread.

Let me know if I can be of any help further troubleshooting.

Thanks,
Jay

[popcornmix]

With CEC enabled, when I turn my TV off and back on again, it loses signal with the Pi.

What do you have "When the TV is switched off" set to? I believe the default is ignore, but setting it to shutdown would produce the behaviour you describe.

[illiac4]

From which build Kodi disables all third party addons if it chrashes?

I don't believe this is deliberate behaviour. Possibly the crash is occurring when Addons22.db is being written, leaving it in an unusable state.
Finding the first build with this problem would be useful for tracking it down.

http://forum.kodi.tv/showthread.php?tid=...pid2289270

[stevegal]

I'm on build #318. things are generally good, but I've noticed a few issues
- On playback of a pvr record from tvheadend, after about 15 minutes the pi stop freezes and playback stops - and has to be force power cycled to return. The recorded file plays fine on other playback media. Any ideas? Known issue or debug log required?
- When setting a timer the "timer set" flag on the epg doesn't return true so when you get the response back from the json-rpc interface it is always false. The timer is set however and does appear in the list of timers.

Try build #0321.

The timer set flag is definitely fixed in #321! I've yet to checkout the playback. Good stuff so far!

[herrmeier01]

I have some trouble with the latest changes of handling the device trees and overlays since #0314

I want to load the analogue soundcard and SPI interfaceas.

Before it was working with:
/flash/config.txt
dtparam=audio=on
audio_pwm_mode=1
audio_sdm_mod_order=2
dtparam=spi=on

As I understand I have to configure it now like this:

/flash/config.txt
dtoverlay=rpi-dac,audio_pwm_mode=1,audio_sdm_mod_order=2
dtoverlay=spi-gpio35-39

But the overlay will not be loaded
# dtoverlay -l
No overlays loaded

I think I'm doing something wrong

[Milhouse]

http://forum.kodi.tv/showthread.php?tid=...pid2289270

Starting with build #0220 there are problems with addons, for sure. I suspect PR9110 is responsible - I've posted already on github about the startup issues when there is no Addons*.db file. Unfortunately I can't reproduce in Ubuntu, although maybe it's a timing issue.

[popcornmix]

I think I'm doing something wrong

Best to ask here where the device tree guru will be able to answer.