Wow, jfabernathy, I didn't expect you to go to all that trouble, and on a holiday weekend to boot. Thank you so much for your generous gift of time, energy and expertise. I'll try these instructions out later today, and let you and everyone else know if I need to make any changes or clarify anything.
Thanks, again. Happy New Year!
-Kevin
Raspberry Pi OS 64-bit and mythtv
- jfabernathy
- Senior
- Posts: 577
- Joined: Wed Feb 18, 2015 2:37 pm
- Location: Raleigh, NC
Re: Raspberry Pi OS 64-bit and mythtv
I know one problem you'll have. the sudo dpkg -i will not get the dependencies. So you might want to just do sudo apt install ./mythtv-light,,,,,,,kzembower wrote: ↑Sun Jan 02, 2022 2:02 pmWow, jfabernathy, I didn't expect you to go to all that trouble, and on a holiday weekend to boot. Thank you so much for your generous gift of time, energy and expertise. I'll try these instructions out later today, and let you and everyone else know if I need to make any changes or clarify anything.
Thanks, again. Happy New Year!
-Kevin
Also you don't need to change the variable php_version="7.4". Leave it alone for Bullseye.
EDIT: I fixed the original instructions a few post back.
Re: Raspberry Pi OS 64-bit and mythtv
I have attempted to follow these instructions and build a mythtv based on 32~Pre (64-bit). It actually works quite well, and I have an 8GB Pi4 running a backend, plus 2 4GB Pi4s running as frontends. Both frontends connect to TVs via HDMI cables, and audio is transferred via HDMI. On one of my frontends, I'm seeing a very odd behavior:
When you fast forward, and then press play, it frequently stops playing the audio. Several seconds later, a toast message pops up with an error "Unsupported audio signal". Mythfrontend logs at that point show an error message "AFD: Unkown audio decoding error" in decoders/avformatdecoder.cpp. This behavior also happened once (!) when simply watching a program for a few hours.
The strange thing is that if you exit playback (escape), and re-enter immediately, it picks up the audio and keeps playing just fine (so the stream is clearly there).
I'm running the raspios 10-30-21 64-bit image. uname -a reports
I have tried this with both the master and devel/ffmpeg-resync branch, both display similar behavior on this one system.
Anyone have any thoughts/suggestions on how to diagnose this?
Thanks!
When you fast forward, and then press play, it frequently stops playing the audio. Several seconds later, a toast message pops up with an error "Unsupported audio signal". Mythfrontend logs at that point show an error message "AFD: Unkown audio decoding error" in decoders/avformatdecoder.cpp. This behavior also happened once (!) when simply watching a program for a few hours.
The strange thing is that if you exit playback (escape), and re-enter immediately, it picks up the audio and keeps playing just fine (so the stream is clearly there).
I'm running the raspios 10-30-21 64-bit image. uname -a reports
Code: Select all
Linux pi1 5.10.63-v8+ #1488 SMP PREEMPT Thu Nov 18 16:16:16 GMT 2021 aarch64 GNU/Linux
Anyone have any thoughts/suggestions on how to diagnose this?
Thanks!
- jfabernathy
- Senior
- Posts: 577
- Joined: Wed Feb 18, 2015 2:37 pm
- Location: Raleigh, NC
Re: Raspberry Pi OS 64-bit and mythtv
Don't know if this is your problem, but there is a setting in mythfrontend Video section in Playback Advanced section called Audio Read ahead and it defaults to 100, I've needed that setup to 400, 600, or 800 depending on the situation. It says that setting helps if the audio drops out some.
Re: Raspberry Pi OS 64-bit and mythtv
Thanks, jfabernathy, I'll give that a try. And thanks for the research you did before I started playing with this, you saved me a bunch of time by posting about it.
I'll report back on if Audio Read Ahead helps. I've never needed it in the past, so didn't even think about it.
I'll report back on if Audio Read Ahead helps. I've never needed it in the past, so didn't even think about it.
Re: Raspberry Pi OS 64-bit and mythtv
For future Google searches...
So I've played with this a bit. At 200 ms, it is substantially better (but still occasionally drops the audio). At 300 ms, it gets worse (very strange, you'd expect it to be at least as good).
200 ms may be good enough for me. I plan to continue playing with it, and will follow up if I find anything significant.
At least I can dig into the read-ahead code, and see if I can understand why it's behaving oddly.
So I've played with this a bit. At 200 ms, it is substantially better (but still occasionally drops the audio). At 300 ms, it gets worse (very strange, you'd expect it to be at least as good).
200 ms may be good enough for me. I plan to continue playing with it, and will follow up if I find anything significant.
At least I can dig into the read-ahead code, and see if I can understand why it's behaving oddly.