Refresh Rate change stops playback (October Update)

Since the October update that came yesterday I have the following problem:

When I start for example a TV show, playback starts, my TV changes the refresh rate but then stops playback. I have to start an episode several times before playback actually works.

This is new since the October update. Before everything worked flawless in regards to playback. There are no changes on the system beside the update that came yesterday.

This is basically symptomatic for the problem (only using relevant parts from non debug logs for easier understanding):

10:36:50.430 T:4109709312 NOTICE: Display resolution ADJUST : 1920x1080 @ 23.98 - Full Screen (28) (weight: 0.000)
10:36:50.698 T:4109709312 NOTICE: VideoPlayer: OnLostDisplay received
10:36:51.462 T:4109709312 NOTICE: VideoPlayer: OnResetDisplay received
10:36:55.104 T:3310351344 ERROR: GetDirectory - Error getting
10:37:01.598 T:4109709312 NOTICE: CVideoPlayer::CloseFile()

Basically on a OnResetDisplay (refresh rates adjusted) I get the GetDirectory error and the file playback closes. Not that it doesn’t even log the directory, so it looks like it tries to get something that doesn’t exist (hence the error, at least this is my current working assumption)

The file itself is shortly playing (maybe a second or so) before playback closes. Also that it is actually able of reading the mediainfo and starting playback means it can access the file.

There is nothing in the logs pointing to the root cause. Refresh Rate change, playback starts, then stop with GetDirectory() error almost immediately after the refresh rate change.

Once I got the following additional error:

10:36:25.605 T:3213558768 ERROR: Read - Error( -1, 103, Software caused connection abort )

In that case no GetDirectory error. Same deal basically.

Files are fstab mount on SMB shares and Kodi uses path redirection from the SMB locations I have inmy SQL database the the mnt location on the Vero. All that worked flawless since the day I bough the Vero 4K. No changes. Yesterday it broke right away.

What seams strange is that Kodi does not show any cases of usinng the /mnt/ path substitution I have in my config. But I am not sure if it ever showed the /mnt/ or if it always showed the SMB path.I have in my advancedconfig. Maybe an issue with path substitution?

But since the update yesterday I have to start playback several times until a movie or a TV show from my NAS actually gets played.

Debug Logs show nothing more. It basically is what is in non debug logs. GetDirectory error after RefreshRate change, File closed and hence playback is aborted.

if I turn off the Refresh Rate changer the problem does not occur again. Changing the delay makes no difference. So it is somewhat tied to it, suggesting probably a regression in Kodi itself once more that is probably unrelated to the refresh rate change itself (as it shows a GetDirectory error) but just manifests in that way on my system (and hence reproducible for me).

So question: How can I downgrade the system to the September version (with the high CPU usage fix) so the system is useable again? That would solve my problems immediately and I have a running system again (and never update again probably).

To exclude certain factors here. Suggest to copy the file onto the Vero and try:

  1. Playing just from the files menu
  2. Scanning it into the library and play from the library view
    With that two results it might give more evidence on where the culprit is

Will do a couple of more experiments and check some variations to limit down what could cause this for me after the update and will report back then.

So did some quick checks:

File or Library Menu makes no difference. The problems comes up every time. Usually on the 3rd attempt a file is playable. So it is not a problem with the database. As said, file is accessed (hence the refresh rate changer) and I can see it playing for a second.

Playing a file locally the problem did NOT come up. So that would limit it down to Kodi accessing remote files (as said in my case SQL Library, fstab SMB mounts and path subsitution in the config).

In 1 out of the 20 tries the refresh rate changer didn’t kick in and playback never started. With refresh rate changer disable the problem never came up though. In that case instead of the GetDirectory error the above mentioned Read Error showed up, but only once in 20 tries on random files, which could be a coincidence.

I any case I assume now that the delays in playback just helps to re-produce the problem on my end and the problem is due to some recent change in Kodi or OSMC. Just for good measure: playing on Windows with recent Kodi 17.5 does not show the problems, nor does it playing from an old Amazon Fire TV 1 (the later does direct SMB access from Kodi).

Only on OMSC with the Vero 4K the problem shows up. And that is right after the update.

The only symptom in the logs is basically the GetDirectory error without even trying to list the directory in question itself. Which is odd in itself.

For testing purposes I removed the path substitution and let Kodi access the SMB shares directly. Well the problem was still there.

11:29:53.166 T:3559126000 ERROR: GetDirectory - Error getting

And for good measure I tried to access the files over NFS. Same deal. Playback stops right away.

Note that the directory name is empty! And the file actually started playing as always before but then it aborted with that error. So as said before, access is not a problem. But trying to get a directory “0x00” (or whatever it is empty here) will of course always produce an error.

So what does the GetDirectory after playback actually started does here and while does it fail / is empty? All this seems to point to a Kodi regression on OMSC for the Vero 4K for me.

Any suggestions?

As said I’d like to do a downgrade of the packages to restore a working system. How do I do that?

Will experiment a bit more to limit the problem more down and also check recent changes to Kodi that might be involved here…

Complete reinstall using the image from last month.

Providing a complete debug log would surely be useful.

Guess full re-install it is then so I have a working unit in the living room again. Need to quickly read-up how to do this. I was hoping I could just install older versions of the packages recently updated…

Will play a bit more with it later tonight maybe before reinstalling. But no promises, want to get it working again as quickly as possible. In case I play with the current version a bit more I can upload full set of debug logs then. But as said nothing to be seen in the Kodi logs out of the ordinary. Just the GetDirectory error and nothing else to point to anything here. Video player is setup, error logged, video player is teared down. Whatever happens there causing the issue is not logged.

In any case will report back with more information later.

I guess i’l having the same issue


Can you please provide debugging logs?

Thanks Tom.


Apologies I missed that, fzinken has picked this up in your topic.

Thanks Tom.

Are you saying that the video plays Ok with Adjust Refresh Rate disables?

Can you post a debug log


Here from me from my last try some time ago:

Relevant time stamp: 12:02:14.919 - Played an episode right after a reboot, problem showed, subsequent plays worked right away.

Random episodes starts playing, playback is stopped right away (about a second maybe). Only thing I can see in the log is the strange “ERROR: GetDirectory - Error getting” without listing the directory.

What I play makes no difference. Same filed played before without any issues.

Once this happens player is teared down. The error usually logs after the refresh rate change, but a few times before, which most likely is related to the way logging happens.

If SMB, NFS, fstab mount or not makes no difference. Problem does not seem to occur on local playback. Using path substitution or not (e.g. direct accessing smb instead of /mnt) makes no difference.Playing from my library or directly from the file source makes no difference.

Disabling the refresh rate changer though stops the problem for what ever strange reason for me (only 1 in 20 tries fail with a generic read error but that has been there now and there before and could be network related in general). More likely I can reproduce the problem easier with the refresh rate changer running compared to it being responsible somehow. Changing the delay makes no difference at all.

No changes on NAS at all. Vero 4K updated on October 30th, had all patches before installed and no issues at all. No changes beside updating yesterday and the problem showed right away. Usually on the first try the problem comes up.

Though it could be some kind of racing condition, as when I enable full logging on the UI the problem rarely shows but it is still there. With loglevel 1 it shows way more and with no debug logging is it even more pronounced (sometimes 3+ tries before any files plays).

Once a file plays there are no issues. Have not testing if skipping forward/backwards or rew/ffd will have any impact.

Yeah, it is strange, but very likely some regression in the latest Kodi.

And no streaming plugins or whatever installed.

Thanks for letting us know local playback is OK. There’s only been one major networking change, and it was for SMB.

This is line with Kodi master (backported).


As I compiled the recent 17.6 version for some personal adjustments the problem is gone, whatever caused it. Though still seeing the strange error message but it is of no consequences.

So with the November Update the problem - at least for me - should be gone as well…

You can try 17.6 from OSMC now. Feedback would be appreciated.

  1. Login via the command line
  2. Edit the file /etc/apt/sources.list
  3. Add the following line: deb jessie-devel main
  4. Run the following commands to update: sudo apt-get update && sudo apt-get dist-upgrade && reboot
  5. Your system should have have received the update.

I also recommend you edit /etc/apt/sources.list again and remove the line that you added after updating. This will return you to the normal update channel.

Will verify later today and let you know…

All fine with 17.6. No issue. Looks like whatever caused the issue in the end for me was fixed upstream.