Heavy stuttering, pausing, loss of sound during video playback

After the last two updates, the Vero 4K is experiencing heavy stuttering, pausing, and temporary loss of sound during SMB video playback. This usually happens during the first minute of the video. Here is a log that captures the problem.

There is also what seems to be a related problem of videos randomly stopping during playback and showing a black screen, then returning to the file selection menu 20-30 seconds later. This also started happening recently, but it’s not captured in the log above.

P.S. I have not tested with local playback because Vero 4K does does not power my USB hard drive sufficiently to spin it up (this issue has been discussed in other threads).

1 Like

Copy the file to eMMC and try

Sam

No stuttering issues on the same video played from eMMC. It must be network-related buffering.

What are the next things to troubleshoot? If you could give me specific steps, that would be great.

It looks like you are using a 4K, rather than a 4K +

You may benefit from an fstab mount.
I would certainly not use hostnames, but rather IPs at the least.

Sam

Can you do this with a Windows drive without creating a separate partition?

What’s the hardware advantage of the 4K+ that would help prevent this?

Thanks, I will try this. Do you think SMB discovery is slowing down buffering? Seems it could make a difference when listing directories, but not when the file has been identified and is already streaming, no?

Also, the router is set to DHCP. What if it decides to reshuffle IPs? That’s the main reason I’ve always used host names for Kodi setups.

Servers should always be configured with a static IP. As far as your Kodi clients, most modern consumer routers have the ability to configure IP reservation by MAC address.

I’ve reserved the IPs for all clients and now need to edit shared directories on Vero to change the paths from hostname to IP. There doesn’t seem to be a way to do that from the GUI without rescanning all content into the library. Is there a way to access the settings file and edit all the paths with a text editor or perhaps something even quicker and avoid rescanning?

Well, path substitution could be a way to do the trick, see https://kodi.wiki/view/Path_substitution.

PS: I can’t see the relation using static IPs instead of DNS with DHCP+name server having fixed IPs on the DHCP server … and your topic?!

It looks like you definitely have an intermittent network bandwidth issue between your Vero and the Samba/Windows server by the amount of stream stalled entries in your log, example:

2019-06-22 23:15:04.802 T:2585748192  NOTICE: CVideoPlayerAudio::Process - stream stalled pts:7.584 clock:7.603

iperf3 is a tool which helps you to verifiy the available bandwidth between the Vero and server (running iperf3 in server mode, there). If you need further help, try to describe the used topology with all components between the Vero and the server, first.

Thanks. I decided to go with a more permanent solution and suffered through retyping the IP address over and over a couple dozen times with that superb on-screen keyboard. Once the host name was changed to an IP, all directories had to be rescraped, so I basically lost the entire library, again. :fearful:

That’s what I wrote in response to @sam_nazarko but haven’t heard back. For what it’s worth, the stuttering has slightly improved after changing from host name to IP.

So just run it like this and start streaming in Kodi?

image

Vero 4K is hardwired to the router. The server is a Windows laptop, connected to the router via WiFi (wired connection is not an option). For testing purposes, there are no walls or obstacles between the laptop and the router. In fact, they are only a few feet away from each other, and the stuttering still occurs.

1 Like

Nope after you start the server you need to start Client on the Vero.

Check this post.

2 Likes

Although you wrote “wired is not an option” … it could be helpful at least for this test phase to connect the laptop via LAN cable if it has an ethernet interface. Perhaps, this already isolates the issue.