Stuttering on every video / Broken seeking (LG 49NANO)

For help and support with Universal Media Server
Forum rules
Please make sure you follow the Problem Reporting Guidelines before posting if you want a reply
protected
Posts: 41
Joined: Sun Apr 12, 2015 5:59 am

Stuttering on every video / Broken seeking (LG 49NANO)

Post by protected »

At first I thought this was encode-specific, but every video played through UMS seems to be stuttering (there is "braking" or slowing down more frequently than once per second) It doesn't matter if I request a transcode or not. It happens to every file, from the very beginning of playback. For the attached log I just played a 720p video for 30 seconds without transcoding. I'm (still) using a wired network, AFAIK all equipment is 1gbps. The audio plays without any issues. None of the resources on the server PC is anywhere near maxed out during playback, and the files are being read from a SSD.
Attachments
ums_dbg_2020-10-10-04-09.zip
(604.11 KiB) Downloaded 318 times
Last edited by protected on Mon Oct 12, 2020 2:36 pm, edited 1 time in total.
protected
Posts: 41
Joined: Sun Apr 12, 2015 5:59 am

Re: Stuttering on every video

Post by protected »

Damn, it doesn't happen on my phone (running VLC). The TV is 4k, could that have anything to do with it?
protected
Posts: 41
Joined: Sun Apr 12, 2015 5:59 am

Re: Stuttering on every video

Post by protected »

I tried streaming with Kodi to the same TV in order to check if it was a problem with the TV, but everything ran smooth as butter...
protected
Posts: 41
Joined: Sun Apr 12, 2015 5:59 am

Re: Stuttering on every video

Post by protected »

I wanted to try increasing the jvm memory, but UMS is refusing to run from UMS.bat. The trace-level log always ends on the "[main] Writing PID: ..." line.
protected
Posts: 41
Joined: Sun Apr 12, 2015 5:59 am

Re: Stuttering on every video

Post by protected »

After some more fooling around, I found out that if I use ffmpeg I can obtain smooth video, and I think that's because ffmpeg is using my gfx card for encoding. I had mencoder prioritized, but both mencoder and whatever happens when I don't explicitly use the transcode folder result in stuttering.
Nadahar
Posts: 1990
Joined: Tue Jun 09, 2015 5:57 pm

Re: Stuttering on every video

Post by Nadahar »

The FFmpeg hardware acceleration supported by UMS is only for decoding, not encoding, so I doubt that's the explanation. I have no idea if MEncoder can handle encoding to 4k, it kind of "wasn't invented" when MEncoder was written. UMS usually only chooses MEncoder if the video has internal subtitles though, so if you're switching to FFmpeg chances are that you lose the subtitles. You can turn off this functionality by disabling "defer to MEncoder for.... something subtitles". FFmpeg chokes on internal subtitles in many circumstances though, so it isn't ideal.
protected
Posts: 41
Joined: Sun Apr 12, 2015 5:59 am

Re: Stuttering on every video

Post by protected »

You are probably right. And yet, it is the only one that works. I have now confirmed that the windows task manager states the GPU is being used for decoding when ffmpeg is run by UMS, otherwise no GPU use whatsoever.

Now that I watched one video, I can say that ffmpeg went smoothly all the way from beginning to end... *provided* I don't attempt to pause or seek. If I pause or seek, when I resume video will freeze for a long time/forever. Is there any way to fix this?

On MEncoder vs FFMpeg: There was no loss of subtitles. Also, I have no videos that are actually 4k. Unsure if UMS encodes to 4k for a 4k TV even if the source video has a lower resolution?

Incidendally, I attempted to force transcoding using the override field in the UI with the file extension (so I don't have to use the transcode folder) but it didn't seem to work; it's still stuttering when not using the transcode folder.
Nadahar
Posts: 1990
Joined: Tue Jun 09, 2015 5:57 pm

Re: Stuttering on every video

Post by Nadahar »

It sounds like some weird things are going on - it shouldn't behave like this. Some of the devs should take a look at your log file.
protected
Posts: 41
Joined: Sun Apr 12, 2015 5:59 am

Re: Stuttering on every video

Post by protected »

Running some more tests on the seeking issue. Behavior seems to be inconsistent across sessions. In a non-trace run, seeking forward on ffmpeg transcodes always seems to restart the playback from the beginning of the video, while dumping a bunch of these in the log:
DEBUG 2020-10-11 17:31:33.876 [HTTPv2 Request Worker 7] Caught exception: Connection reset
DEBUG 2020-10-11 17:31:33.879 [HTTPv2 Request Worker 10] Recognized media renderer "[LG] webOS TV NANO866NA"
DEBUG 2020-10-11 17:31:37.896 [HTTPv2 Request Worker 11] Recognized media renderer "[LG] webOS TV NANO866NA"
DEBUG 2020-10-11 17:31:37.909 [HTTPv2 Request Worker 11] Caught exception: Connection reset
DEBUG 2020-10-11 17:31:38.739 [HTTPv2 Request Worker 12] Recognized media renderer "[LG] webOS TV NANO866NA"
DEBUG 2020-10-11 17:31:38.748 [HTTPv2 Request Worker 12] Caught exception: Connection reset
DEBUG 2020-10-11 17:31:38.912 [HTTPv2 Request Worker 13] Recognized media renderer "[LG] webOS TV NANO866NA"
...etc...
But I restarted in trace mode and suddenly seeking forward results in the playback continuing from where it was (not successful, but also not restarting the video). The exception is there in the log though.
Nadahar
Posts: 1990
Joined: Tue Jun 09, 2015 5:57 pm

Re: Stuttering on every video

Post by Nadahar »

It's not the first time I've seen UMS actually acting different depending on if trace is on or off. It shouldn't make a difference, but sometimes it does because the extra code that's run to make the extra logging actually, by incident, makes a difference to the logic itself. That said, if that's the case, it's a bug IMO.

About the "connection reset" exception, that's a problem with Java that I've found no way around. For some extremely stupid reason, the creators of Java chose to treat the closing of a network connection exactly like any other error that might happen, like loss of connection other actual problems. It's extremely annoying, and I've spent quite a lot of time trying to find a way to tell them apart, but I've had to give up. You can't use the "error text" ("Connection reset" in this case) because it varies by OS and by OS language. They have made all that happens completely opaque, which I really think is a huge flaw in Java that nobody seems to care much about. The point is that the closing of a network connection is no "exception" at all, it's a perfectly normal thing. One of the parties must close it, and it's perfectly normal that the remote party does so. In this case, it probably happens because it makes a seek request (a request to receive data from a different position), and thus it terminates the previous connections since it's not possible to "shift" the position in the current connection. This leads to the exception, so in the special case of a "Connection reset" you just have to ignore it.

The "recognition" of the renderer is also normal, UMS does this for every request it receives. What is more "worrying" is that this seems to repeat multiple times, you would expect just one "reset and recognize pair" per seek operation. That said, when looking at the time stamps, they are relatively far apart in time, so it might not be so strange. Many renderers seek by repeatedly requesting new positions a couple of seconds ahead (or behind) the current position in intervals.

So, all in all, the log excerpt doesn't really say anything useful or indicate a problem as such.
Post Reply