EDL in mythpvr on OSMC

Anyone else having an issue with Mythtv add-on with OSMC and Krypton v17?

My setup was working flawlessly, skipping commercials etc, under v16.

Ran the upgrade last evening and it went fine. Menu renders a bit slower, and such, but it works.

Playback on mythtv PVR announces a commercial break in the OSD and then freezes playback at that point. You cannot do anything except jump 30 seconds to “un-freeze” playback and it will start again, but obviously the idea would be to jump commercials outright.

I am very convinced this is NOT an OSMC issue, but could use some feedback from fellow MythTV PVR add-on users. Are you experiencing the same problem?


You got further than me! I get listing for my TV channels (which rarely get used because I’m always watching recording from the backend), but when I go to the recordings menu (on side menu now), I get a frozen screen and no recordings ever get listed. Is there a fix for this?

For queries about addons you are much better served by the Kodi forum http://forum.kodi.tv/forumdisplay.php?fid=27 or by contacting the add-on developer directly.

The problem is discussed here: http://forum.kodi.tv/showthread.php?tid=307012

… and I’m experiencing it as well. One poster said it’s resolved in Kodi 17.1 rc1. Is there an easy way I can upgrade to that? Or will we see a corresponding OSMC release soon?

Did the 17.1rc1 update. Still same symptoms.


Me too. Unfortunately this serioulsy reduces wife acceptance. :worried:

Logs don’t show any error in the playback and the video seems to continue without the auto skip (the progress bar just resumes with the clock ticking, but no video/audio output).

If you specify what is needed I can upload logs.

I’m watching this issue.



Thanks! (as always…) It “looks” like the info to tell the player to jump forward past the break is not happening… It is probably, like others have said, and issue with the player.


Hi Jim

Once this is resolved in Kodi, we can get it resolved in OSMC. I understand it may already be fixed. If that’s the case, you should see improvement on Sunday when we release our next update.


Ok, Sam was faster…

Anyways for the interested reader I just created logs showing the behaviour.

This is definately not the case. The player recognizes the .edl file and reads the defined skips on video start. Here I started a video:

22:25:13.140 T:1379922928 NOTICE: running thread: CVideoPlayerAudio::Process() 22:25:13.140 T:1413477360 DEBUG: ReadEditDecisionLists - Checking for edit decision lists (EDL) on local drive or remote share for: /media/TVRecorder-NAS/TV/Die Simpsons (1989)/S23E01.Homer Impossible.mkv 22:25:13.153 T:1413477360 DEBUG: AddCut - Pushing new cut to back [00:00:49.240 - 00:01:36.560], 3 22:25:13.153 T:1413477360 DEBUG: AddCut - Pushing new cut to back [00:11:28.920 - 00:18:28.280], 3 22:25:13.154 T:1413477360 DEBUG: AddCut - Pushing new cut to back [00:29:09.960 - 00:30:14.320], 3 22:25:13.154 T:1413477360 DEBUG: ReadEdl - Read 3 cuts and 0 scene markers in EDL file: /media/TVRecorder-NAS/TV/Die Simpsons (1989)/S23E01.Homer Impossible.edl 22:25:13.154 T:1413477360 DEBUG: AddSceneMarker - Inserting new scene marker: 00:00:49.240 […]

Kodi also recognizes the correct start time of a skip and pops up a message a few secconds before. It tries to jump to the end of the skip, too.

Here the 2nd marker is reached:
22:34:51.777 T:1413477360 DEBUG: CheckAutoSceneSkip - Clock in commercial break [00:11:28.920 - 00:18:28.280]: 00:11:28.938. Automatically skipping to end of commercial break (only done once per break) 22:34:51.778 T:1413477360 DEBUG: demuxer seek to: 1108281.000000 22:34:51.778 T:1413477360 DEBUG: SeekTime - seek ended up on time 1104821 22:34:51.778 T:1413477360 DEBUG: demuxer seek to: 1108281.000000, success 22:34:51.778 T:1413477360 DEBUG: CVideoPlayer::FlushBuffers - flushing buffers 22:34:51.786 T:1958879232 DEBUG: ------ Window Init (DialogNotification.xml) ------ 22:34:51.818 T:1388311536 DEBUG: CVideoPlayerVideo - CDVDMsg::GENERAL_SYNCHRONIZE 22:34:51.820 T:1379922928 DEBUG: CVideoPlayerAudio - CDVDMsg::GENERAL_SYNCHRONIZE 22:34:51.891 T:1958879232 DEBUG: ------ Window Init (DialogSeekBar.xml) ------ 22:34:54.576 T:1958879232 DEBUG: ------ Window Deinit (DialogSeekBar.xml) ------ 22:34:57.574 T:1958879232 DEBUG: ------ Window Deinit (DialogNotification.xml) ------ […]

BUT obviously that jump is not successful.
22:34:59.941 T:1413477360 DEBUG: CVideoPlayer::HandleMessages - player started 2 22:35:00.065 T:1929376752 DEBUG: ActiveAE::SyncStream - average error of 415897.062436, start adjusting 22:35:00.534 T:1388311536 WARNING: CRenderManager::WaitForBuffer - timeout waiting for buffer 22:35:01.827 T:1379922928 WARNING: Previous line repeats 2 times. 22:35:01.827 T:1379922928 ERROR: CDVDAudio::AddPacketsRenderer - timeout adding data to renderer 22:35:02.068 T:1388311536 WARNING: CRenderManager::WaitForBuffer - timeout waiting for buffer 22:35:03.638 T:1379922928 WARNING: Previous line repeats 1 times. 22:35:03.638 T:1379922928 ERROR: CDVDAudio::AddPacketsRenderer - timeout adding data to renderer

I’m no developer, but it seems the video after the jump is not loaded correctly. Interestingly enough though you can manually jump to the end of the marker via RC and the video plays just nicely as supposed.

The Kodi forum suggests this bug is already solved in Kodi v17.1 RC1 so the current OSMC should also work. Apparently it doesn’t though.

17.1 RC1 is very vague.
RC1 isn’t published yet. There is no RC1. Kodi bumps version before commits.

If Kodi is saying it’s fixed though, I can cherry-pick those fixes for Sunday.

Thumbs up for that! :grinning:

I guess this is it?: