How's your Olympics recording playback on the Raspberry Pi 4?

[monkeypet]

I am using the raspberry pi 4 as indicated on the other threads and mythtv frontend connecting to a remote backend on a the same LAN. It is overclocked and also starting mythfrontend from an .xsession bypassing the full gui also tried running without Xwindows, it is the same behavior. What I see is that playback is really good, however, there is a very slight/short pause every few secs, the pause-glitch is extremely short and most people won't notice them, but if you are watching a fast moving sport like skiing or skating, you will notice these. The recordings are primarily MPEG2 (TS files) from a HDHomerun.

Anyone notice this, you need to watch very very closely? Resolution of TV is 1080. Raspberry Pi network is wired (not wireless).

Also any other suggestions? I've also tried changing the priority and making it a realtime priority, doesn't improve anything. It is running bullseye 64bit.

My non-raspberrypi frontend also remote don't have this issue.

[mythpi]

I'm not seeing this at all. I've included a fair amount of detail of my setup, in hopes it will help you find something to tweak. If there's other information that can help, please ask.

I'm using Bullseye 64-bit as well (uname -a returns "Linux pi2 5.10.92-v8+ #1514 SMP PREEMPT Mon Jan 17 17:39:38 GMT 2022 aarch64 GNU/Linux"). I run a backend on an 8GB Pi4 B Rev 1.4 (revision d03114), and two frontends, one on a 4 GB Pi 4 B Rev 1.1 (c03111) and a 4 GB Pi 4 Rev 1.2 (c03112). All are hardwired with a 1 GB connection. For tuners I use a HDHomerun Prime, also on that 1 GB connection.

All machines are set to the ondemand scaling governor, and not overclocked at all (the backend gets the speed boost to arm_freq 1800 if needed, the others up to 1500). The frontends are both in argon one v2 cases for passive cooling, and I don't remember ever even hearing the fans running.

None of the machines are running X (all boot to console), and all run the appropriate mythtv executable via systemd service files. I have disabled UPnP on the frontends (argument --upnp) and log to /tmp. All machines are setup to run off low-end USB SSDs (nothing extravagant, and each one different based on cheap availability when I built the machine). MPEG2 (TS) files are stored on a 5GB WD Black hard drive (my recollection is it's only 5400 RPM, but that could be wrong).

TVs are HDMI connected via HDMI0, one a very old Sony Bravia, the other a slightly newer LG. Both run at 1080p.

Interestingly, in compiling this, I realized that all 3 machines are running slightly different builds of mythtv-light: backend is on 32~Pre-3227-g919eedfc3d-0, frontends are on 32~Pre-3039-g189b2a7e7e-0 and 32~Pre-3360-ga1e72a209b-0 respectively. Compilation happens on a separate pi4 running bullseye 64.

I also should note I run a fairly restrictive firewall on each machine using nftables, as they're on the same subnet as a bunch of IOT stuff.

[jfabernathy]

I'm not seeing anything every few seconds. There is the occasional jump forward but it's infinitesimally short. It's like the whole picture advances 4 or 5 frames. But I see this on occasion with DIrecTV Stream so that maybe network related.

Just now after your post I went to tonight's coverage which had a replay of Chen's Gold medal performance with lots of spinning, jumps, and speed moves. Looked perfect to me. My RPI4 is a 4GB and it's new enough that by default Bullseye 64 bits runs at 1.8 Ghz instead of 1.5. It's a combo BE/FE. I'm running from the console, no desktop environment. The command I use is:

Code: Select all

QT_QPA_EGLFS_ALWAYS_SET_MODE="1" QT_QPA_PLATFORM=eglfs QT_QPA_EGLFS_KMS_CONFIG=./pi_mythfrontend.json mythfrontend --noupnp --logpath /tmp

As referenced in other Raspberry Pi post recently. The pi_mythfrontend.json file is:

Code: Select all

{
    "device": "/dev/dri/by-path/platform-gpu-card",
    "outputs": [
        { "name": "HDMI1", "mode": "1920x1080@60" }
    ]
}

I mostly use my FireTV 4K stick to watch the video from the RPI4 backend. I see no difference between the Leanfront on FIreTV 4K or RPI4 mythfrontend.

For completeness I running fixes/32 that I built this morning. mythtv-light_32~Pre-3525-g4918468a52-0_arm64_bullseye.deb

I failed to mention originally, that I always use OpenGL Normal but change it to 4 CPUs and Low-Quality deinterlacing.

[mythpi]

It occurs to me to mention I had to change my video playback profile when I was setting up Pre32. I don't remember where in the frontend settings it is, but the setting from the Settings table is value = 'DefaultVideoPlaybackProfile' and data = 'OpenGL Normal'.

[monkeypet]

There is the occasional jump forward but it's infinitesimally short. It's like the whole picture advances 4 or 5 frames.

You described it much better than I. I guess you see it also. I am glad I am not going nuts.

[jfabernathy]

There is the occasional jump forward but it's infinitesimally short. It's like the whole picture advances 4 or 5 frames.

You described it much better than I. I guess you see it also. I am glad I am not going nuts.

I have done some more testing. The best source material to test with for this problem is a news broadcast that has the text crawl at the bottom of the screen. I recorded the CBS Saturday Morning where my Local CBS channel runs a crawl. I recorded this on my x86_64 production backend on v31 and on my testing backend on an RPI4 running v32. I can confirm with confidence that this is not a recording or tuner problem. My testing backend uses HDHR Quatro and my Production backend uses Hauppauge WinTV quadTV. Here's a summary of which frontends have the very, very short stutter or whatever you call it:

Leanfront on FIreTV and Nvidia Shield TV work perfectly, i.e. no stutter, regardless of backend.

mythfrontend on FireTV against testing backend (rpi4) lots of jitter, or stutter in crawl

mythfrontend on Shield TV against testing backend (rpi4). no jitter at all.

mythfrontend on RPI4 against it's own testing backend, the occasional, random jitter we've been discussing.

Mythfronend on 11th gen Core i7 NUC. no issues at all, against testing backend.

Kodi 19.3 on 11th Core gen Core i7 Intel NUC. Occasional jitter about the same jitter as mythfrontend RPI4.

Mythfrontend on the production backend which is a 10th gen Core i3. no jitter at all.

So the most cost effective, no jitter solution is using an RPI4 as a backend only with FireTV 4K running Leanfront. Or you can live with a little jitter. I've found through personal testing that if you drink beer while watching the Olympics you see no jitter at all.

RPI4 plus power supply $65
SATA SSD with USB3 adapter $100
FireTV 4K $30

HDHR tuners are the same $$ for any solution.

[monkeypet]

Kodi 19.3 on 11th Core gen Core i7 Intel NUC. Occasional jitter about the same jitter as mythfrontend RPI4. I do not have mythfrontend installed on this PC.

Jeff, can you get one more data point: Kodi running on Raspberry Pi and using the mythtv PVR plugin.

My observation on Kodi is not that the stutter discussed here was not observed. However, other bigger artifacts like interlacing issues or tearing during fast action for a short period. I saw this on the Olympics recording. I just want to confirm that you also see this.

So it makes me think that the performance issue isn't isolated to the mythtv frontend but in the Raspberry Pi software stack itself, kernel scheduling or video processing.

Unfortunately, I don't have the skills to isolate performance issues. I am going to Google around for performance tweaks on the Raspberry Pi to try to push it harder because it is almost there .

[jfabernathy]

First I went back and install mythtv-frontend package on my NUC and run tests there. It was perfect, much better than Kodi on that platform.

As to Kodi 19.3 on RPI4 Bullseye 64 bit, running at @ 2.0 Ghz. The new crawl was not smooth at all, forget about the occasional jitter/jerk. The lack of smoothness made the news crawl look almost blurry. All the screen would go black for a second or so and the play occasionally. The sound for system sounds like moving around is the app was fine, but no audio on playing a video. The picture was so bad I avoided even trying to fix the audio.

I hate the Kodi interface so bad, that if Kodi was all I had, I'd read a book.

Mythfrontend on RPI4 Bullseye 64 bit is certainly usable. and unless you go looking for problems won't notice the jitter we've been talking about. In a sporting event it's had to notice, particularly if you have that beer I mentioned earlier

[monkeypet]

Mythfrontend on RPI4 Bullseye 64 bit is certainly usable. and unless you go looking for problems won't notice the jitter we've been talking about. In a sporting event it's had to notice, particularly if you have that beer I mentioned earlier

Definitely usable and I am using it as my main remote mythfrontend. However, still hoping that it continues to get better as more people are developing on Bullseye and the raspberry team makes improvements.

[jfabernathy]

Just an update on some testing I'm doing. I built the latest Mythtv, fixes/32(v32.0-4-g75b942fd8c) and it show similar video playback performance to previous versions. However, I tried overclocking a bit more based on some information I saw in a Youtube video of someone pushing the video performance of the PI4. I set my overclocking as below:

Code: Select all

arm_freq=2147
over_voltage=6
gpu_freq=750

This system is still Bullseye 64Bit on a 4GB RPI4. Since this is the newest version of the RPI4 which runs by default at 1.8Ghz it has no issues with the new overclocking. I'm noticing less jitter and when I see it, it's minor. The only way I can detect it is watching news with a horizontal text crawl. It will not take much more improvement to make the RPI4 as good as everything else that cost much more.