Page 1 of 1
Videos Stutter on PS3 - Trace logs included
Posted: Mon Jan 25, 2021 8:28 am
by 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:
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.
Re: Videos Stutter on PS3 - Trace logs included
Posted: Mon Jan 25, 2021 9:12 am
by 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.
Re: Videos Stutter on PS3 - Trace logs included
Posted: Mon Jan 25, 2021 9:27 am
by 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.
Re: Videos Stutter on PS3 - Trace logs included
Posted: Mon Jan 25, 2021 4:56 pm
by 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 6204 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.
Re: Videos Stutter on PS3 - Trace logs included
Posted: Tue Jan 26, 2021 8:43 am
by 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.
ums_trace_logs.txt