Videos Stutter on PS3 - Trace logs included

[lucius]

Issue: Videos are stuttering when attempting to play them. Let's say if I were to reinstall CentOS, and install UMS whether directly or through docker, my video content will play fine (flawlessly) for several months with no stuttering. Then out of the blue videos begin to stutter. I would check disk size, and memory usage but they appear to be fine. My only solution at this time is to blow away the OS and reinstall everything but I was hoping for a more viable and technical solution to my issue now that I am pulling logs.

Below is my overall system configuration for my UMS server:

Code: Select all

UMS server: Dell Latitude E7450 (laptop)
CPU: Intel Core i7-5600U
Memory: 16GB (2x8GB) 1600MHz DDR3L
OS: Centos 8.3.2011
Docker: Debian v10
Network: LAN (wired)
Settings for eno1:
    Supported ports: [ TP ]
    Supported link modes:   10baseT/Half 10baseT/Full
                            100baseT/Half 100baseT/Full
                            1000baseT/Full
    Supported pause frame use: No
    Supports auto-negotiation: Yes
    Supported FEC modes: Not reported
    Advertised link modes:  10baseT/Half 10baseT/Full
                            100baseT/Half 100baseT/Full
                            1000baseT/Full
    Advertised pause frame use: No
    Advertised auto-negotiation: Yes
    Advertised FEC modes: Not reported
    Speed: 1000Mb/s
    Duplex: Full
    Port: Twisted Pair
    PHYAD: 1
    Transceiver: internal
    Auto-negotiation: on
    MDI-X: off (auto)
    Supports Wake-on: pumbg
    Wake-on: g
    Current message level: 0x00000007 (7)
                   drv probe link
    Link detected: yes

Renderer: PS3

Media storage: Synology DS918+

conf:

Code: Select all

uuid = (removed)
ffmpeg_available_gpu_acceleration_methods = none,auto,vdpau
folders = /media/movies,/media/tv,/media/kids,/media/documentaries,/media/misc,/media/fitness,/media/shows,/media/tv-kids
folders_monitored = /media/movies,/media/tv,/media/kids,/media/documentaries,/media/misc,/media/fitness,/media/shows,/media/tv-kids
cred.path = /home/lucius/.config/UMS/UMS.cred
network_interface = eno1
show_new_media_folder = false
show_transcode_folder = false
show_media_library_folder = false
show_recently_played_folder = false
resume = false
log_level = DEBUG

Here are the logs for your review:

ums_trace_logs.txt

(110.2 KiB) Downloaded 232 times

The logs are based on playing the Marvel Studio intro on Captain Marvel which runs for approximately 40 seconds. The only error I see from the logs are:
- DEBUG 2021-01-24 19:08:57.938 [HTTPv2 Request Worker 3] Connection error: java.io.IOException: Broken pipe
I am unsure how if this is the reason I am having this issue and if so, how to resolve it.

Please know the stuttering also occurs on my XBOX One but not as bad as my PS3.
Any help on how to resolve this issue will greatly be appreciated.

[valib]

I see in your login that the video is transcoded but the FFmpeg output transcoding speed is only about 0.5 and fps about 13 so it must stutter. You can try to use the Automatic maximum bandtwith not to use the default value "90". It may help. Or there is something in your PC which slows down the transcoding. The transcoding is out of the UMS and depends on the FFmpeg.

[Nadahar]

If it degrades over time, it sounds like some kind of disk fragmentation issue. UMS shouldn't normally write to disk during transcoding, but if you have little RAM available the OS might start swapping. If so, the swapping target could potentially be vulnerable to fragmentation. It depends on how you've configured your system. Do you swap to a partition or a file? If file, what filesystem is that file on? Just to be safe, I'd also look for potential fragmentation issues for the drives where UMS' "temp" folder and log file are mapped. You can see the paths in question in the beginning of the log file. Unfortunately, using "tail" means that this info isn't available in your attached log file.

Edit: I see that you have 16GB RAM, which should be way more than needed, but it depends on how much RAM is actually available.

[lucius]

@valib
I have added the following line to my conf: automatic_maximum_bitrate = true but the issue still persists.
I would like to add that I am currently using Docker to run UMS. This laptop is mainly used as my media server. My CentOS is headless, so there is very little to no overhead in terms of system resources; no anti-virus or anything. I do have other Docker images running such as Radarr, Plex, Sonarr, and SabNZBD. Whether I run UMS through Docker or directly execute the UMS.sh script on my main OS, the stuttering problem may present itself some time later in the future.
Is there anything I can do to increase the FFmpeg output transcoding speed?

@Nadahar
In terms of degrading overtime; yes this is true but the degradation process is not gradual, it's almost instant. Everything would be working flawlessly one day then all of a sudden the stuttering happens. When you say disk fragmentation, are you referring to the local disk, docker disk, or the disks on my Synology?
I did notice there is no stutter on videos that have smaller file sizes. For example I can play a 100M MP4 video file with no issue at all but stutters when playing the Captain Marvel MKV video file which is approximately 5.3G does.
I have done nothing special to this filesystem's configuration.
Below is my current filesystem:

Code: Select all

Filesystem                    Type     1K-blocks       Used  Available Use% Mounted on
overlay                       overlay   52403200    7373724   45029476  15% /
tmpfs                         tmpfs        65536          0      65536   0% /dev
tmpfs                         tmpfs      8040696          0    8040696   0% /sys/fs/cgroup
shm                           tmpfs        65536          0      65536   0% /dev/shm
/dev/mapper/cl-root           xfs       52403200    7373724   45029476  15% /tmp
192.168.0.147:/volume1/videos nfs4    5763662720 2771402624 2992141312  49% /media
/dev/mapper/cl-home           xfs      438201292    7349136  430852156   2% /opt/ums/data
tmpfs                         tmpfs      8040696          0    8040696   0% /proc/asound
tmpfs                         tmpfs      8040696          0    8040696   0% /proc/acpi
tmpfs                         tmpfs      8040696          0    8040696   0% /proc/scsi
tmpfs                         tmpfs      8040696          0    8040696   0% /sys/firmware

Swap

Code: Select all

root@localhost:/opt/ums# free -m
              total        used        free      shared  buff/cache   available
Mem:          15704        2019        5600          17        8084       13372
Swap:          8019           0        8019

Code: Select all

root@localhost:/opt/ums# cat /proc/swaps
Filename                Type        Size    Used    Priority
/dev/dm-1                               partition    8212476    0    -2

I have attached of a screenshot of my system's resources while UMS stutters for your review

Screen Shot 2021-01-24 at 7.51.40 PM.png (1.05 MiB) Viewed 3960 times

Is there anything else I can try?
Last resort would be is to reinstall CentOS, which would definitely resolve my issue...temporarily for several months, but I would like to avoid doing that.

[Nadahar]

I don't really have anything specific in mind when it comes to fragmentation - it's just one of the few things I know of that will gradually worsen over time on a computer. It could be anything involved, swap, temp storage or where the media files are stored. The reason I assumed "gradual" is that you're talking about months. Even if something gets gradually worse, you might not notice until it reaches a certain threshold. Let's say that your car has a top speed of 200 km/t, but you never drive more than 90 km/t. If it starts to gradually lose top speed, you won't notice until it has gotten quite bad and the top speed is less than 90 km/h.

I know next to nothing about how Docker works and manages memory, so I'm quite lost there, but you claim the behavior is the same if not using Docker, which sort of excludes that as the source. I also have very little experience with xfs, and found some threads about xfs fragmentation issues, but they seemed rather old and relatively few - so I suspect that's an unlikely cause too.

That said, I'm not sure either fragmentation or memory management is the issue here. What looks very suspect to me is that you have 9 different ffmpeg processes running at the same time, not to mention all the Java processes. I'm not familiar with the view in the screenshot, but I assume that since they all have different PIDs that they actually are different processes, not just different threads. If they are threads, it's as would be expected, but I've never heard of threads being assigned different PIDs..

There are only a few things that can make transcoding performance suffer (as long as transcoding speed is below 1x, it WILL stutter): Insufficient processing power or too slow input. If many transcoding sessions run in parallel, even a powerful CPU might be overwhelmed. Likewise, if network or disks deliver the source too slowly, this will limit the processing speed. Neither seems obvious or likely here, but in the end something must restrict this to a point where it can't deliver the stream in real-time.