Rasp pi 4 slow response

A

_Alucard_

Disciple
I am running a media server combo via docker on my Rasp pi 4 gb model ( sonarr + radarr + jellyfin docker containers )
which works fine for most of the time, but often it happens that media becomes unplayable at times, like playback freezing every 2-3 seconds, stutters a lot.
all media is 1080p x265

sometimes culprit is high load average because of some of docker containers, but often they arent .
As of now, similar issue is happening, playback is freezing on jellyfin as well as vlc ( accessing the files via samba ) .
all stats of rasp pi seems to be normal ( load average, cpu/ram usage, temps )

attaching the bpytop screenshot for reference, load average currently is ( 0.04, 0.11, 0.18 ). Any help on how to diagnose the issue ?
1692683410049.png
 
So you are running Jellyfin on Pi4, and playing h265 content. The main culprit will be Transcoding, if your playback device does not support h265.
Pis don't have a powerful GPU, so even 1080p transcoding is too much.
Playing on VLC over the network, could be speed issue, or could be Pi not able to keep up with data transfer (rare)
 
h.265 is absolutely supported, infact pi4 can transcode 4k h265 as well which ive tested successfully . Also as i mentioned that normally theres no problem in transcoding and everything is buttery smooth, but i get these periods of laggyness once/twice a month and not able to find any culprit for them
 
Try decreasing the swapiness value to 10 and make sure that you are not running that pytop if media is playing. Other then this, it is expected from Raspberry, as many people experience the same.
 
thanks, will try that , how does that affect the performance ?

> it is expected from Raspberry, as many people experience the same.

still what's the source problem here , since i dont see any resource consumption in meantime ?
 
As your temp and other stats seems okay it could be a network issue. How are you connecting to it? WiFi or LAN?
I was facing similar issues with my RPi4 when it fetched video files over WiFi from my NAS. Then I realized I had a metal case (which also worked as the heatsink) , which was messing up the wifi connection, I replaced it with a cheap plastic case added small heatsinks and now it works fine.
 
Yea I'm also using a metal alu heatsink, couldbe an issue
I was looking into operating pi via lan only , letsee if it will fix the issue
Thanks
 
pika420 said:
So you are running Jellyfin on Pi4, and playing h265 content. The main culprit will be Transcoding, if your playback device does not support h265.
Pis don't have a powerful GPU, so even 1080p transcoding is too much.
Playing on VLC over the network, could be speed issue, or could be Pi not able to keep up with data transfer (rare)
Click to expand...

Actually, Pi4 has hw support for h265 decoding, and encoding/decoding for h264. So not really an issue. You just need to use the omx stuff or something - been a while since i looked into this.

The pi can also easily keep up with the transfer rate as long as its not using NTFS. With ext4 or btrfs without raid, nearly full 1G speeds are possible. Am running a set of 2 pis for this exact purpose.
 
vivek.krishnan said:
Actually, Pi4 has hw support for h265 decoding, and encoding/decoding for h264. So not really an issue. You just need to use the omx stuff or something - been a while since i looked into this.

The pi can also easily keep up with the transfer rate as long as its not using NTFS. With ext4 or btrfs without raid, nearly full 1G speeds are possible. Am running a set of 2 pis for this exact purpose.
Click to expand...
omxplayer stuff has been long outdated i think

> nearly full 1G speeds are possible

this is surprising to me , transfering files from rpi to my laptop using samba , and speed is capped to 7.5MBPS , and 12.5MBPS via scp.
Pi is running on external hdd (ext4) , wifi , while source is laptop, also on same wifi

the router I am using is an extender to main router which is 2 floor below connected via a lan cable, do you think that can be bottleneck ?
 
_Alucard_ said:
omxplayer stuff has been long outdated i think

> nearly full 1G speeds are possible

this is surprising to me , transfering files from rpi to my laptop using samba , and speed is capped to 7.5MBPS , and 12.5MBPS via scp.
Pi is running on external hdd (ext4) , wifi , while source is laptop, also on same wifi

the router I am using is an extender to main router which is 2 floor below connected via a lan cable, do you think that can be bottleneck ?
Click to expand...
Can you remove it from the case (be careful about short circuit) and run it once to see it's the wifi signal and also check if there's good wifi signal with you phone. If possible use 5GHz wifi.
 
so it was definitely a network issue i think,
I bought router much closer to pi (alu case still on it ), and speed in iperf increased by 10Mbps

final metrics, calculated by iperf3 with pi as server and laptop/pc as client

pi/wifi laptop/wifi 80Mbps
pi/lan laptop/wifi 350Mbps
pi/lan pc/lan 1Gbps

huge improvement

I will keep an eye incase this stuttering starts to happen again
 
Nice to know that it was a network issue and finally resolved it!
I feel changing the case to a non metallic one or adding an external antenna (not straightforward with the current variants, hope they add this feature in next version of RPi) would give you wifi speed another boost.

 
well, network speeds were a red herring , this now seems to be directly linked to io speeds
1693655433636.png


this is happening when only demanding thing running currently is qbittorrent-nox
which currently has 7 torrents, only one downloading (1MBPS) and others seeding (only one seeding at < 1MBPS , rest almost inactive )

attaching iotop at the moment, which doesnt seem quite high, given that hdd is attached to a 3.0 usb port in pi
1693655597418.png
 
_Alucard_ said:
well, network speeds were a red herring , this now seems to be directly linked to io speeds
View attachment 177198

this is happening when only demanding thing running currently is qbittorrent-nox
which currently has 7 torrents, only one downloading (1MBPS) and others seeding (only one seeding at < 1MBPS , rest almost inactive )

attaching iotop at the moment, which doesnt seem quite high, given that hdd is attached to a 3.0 usb port in pi
View attachment 177199
Click to expand...
qBittorrent is writing multiple small chunks to different sectors of the HDD. A HDD is terrible at small random writes, scoring a few MB/s in that test, as the disk and the write head has to make frequent adjustments to reach the position.

If you check your "top" output you'll see that your CPU is spending 50% time waiting for io operations to complete (49.0 wa).

To fix this, you can either mess around with qBittorrent write cache (but your choices are limited, as you don't really have a lot of ram), or use a separate ssd for temporary download location.
 
1693658868382.png

these are the IO section options available in bittorrent setting, which one do you think will help here ?
swithcing to ssd currently is kinda a budget breaker sadly
 
_Alucard_ said:
View attachment 177200
these are the IO section options available in bittorrent setting, which one do you think will help here ?
swithcing to ssd currently is kinda a budget breaker sadly
Click to expand...
I'd try increasing the disk queue size, but doubt that would improve a lot. qBittorrent (libtorrent) has deprecated "disk cache" option, so I don't believe you can set it now. In the earlier days we would increase the disk cache size to a few GBs, depending on the available memory, and disable OS caching policy.

You can also try setting temporary download location to your micro sd, but that would limit your download size to whatever free space you have in your sd card, and also wear it out fast.

Edit: I don't mean you need to switch to an SSD for the entire storage. You can use a small ssd (128gb) as a tiered caching drive. Torrents will download to this drive initially, and then upon completion will be transferred to the HDD for final storage. You'll still be limited to 128GB as total active downloads, but that's a lot imo. The HDD will only be subjected to bulk sequential transfer, and that's fast.
 
Last edited:
> You can use a small ssd (128gb) as a tiered caching drive

yea this is definitely feasible, luckily i do have a spare 500gb ssd, can also install the rpi os on it for better performance , but only issue is that ssd enclosures are costly, but i dont see any other choice to fix this issue .
can you recommend any ?
 
_Alucard_ said:
> You can use a small ssd (128gb) as a tiered caching drive

yea this is definitely feasible, luckily i do have a spare 500gb ssd, can also install the rpi os on it for better performance , but only issue is that ssd enclosures are costly, but i dont see any other choice to fix this issue .
can you recommend any ?
Click to expand...
I can see some available for under 500rs, with very good ratings. My friend has an orico one. You ideally want one that supports UAS. This looks decent https://www.amazon.in/Cablet-Portable-External-Enclosure-Tool-Free/dp/B0BG62HMDJ/ . Make sure your rpi power supply has enough juice.
 
Back
Top