"Richard Evans" <R.P.Evan...@Sky.com> wrote in message
news:t9head$1bjt$1...@gioia.aioe.org...
> On 25/06/2022 12:12, Ar wrote:
>
>> Rather than sending it to a tip, I turned an old unused computer in to a
>> PVR, zero problems, record all the steams on the multiplex if you want.
>> Pick your own cable / terrestrial / or satellite card (or a combi card).
>> Overkill yes, but it works and you chose what you want depending on
>> budget.
>
> If you mean MythTV, I pretty much gave up on that because the video
> playback was jerky. The reason is simple enough but actually
> solving it, seemed to be impossible :|. It would probably be
> fine in the USA where the refresh rate is 60Hz. But here were
> we use 50Kz, but computers are 60Hz. That was just a frustrating
> problem that I gave up on.
>
> Perhaps it depends on what you find acceptable.
For playing back 50 Hz video on my PC, I've set the video card refresh rate
to 50 Hz (or maybe 100 Hz) as opposed to 60/120 Hz. That hopefully means
that there is no 10 Hz beating pattern between the rate at which the screen
is redrawn and the rate at which video frames change. On a CRT monitor where
each pixel is lit sequentially, 50 Hz would have been far too low, but on an
LED monitor where all the pixels are lit for almost the whole 1/50 second,
it doesn't matter. I use VLC to play videos.
I investigated MythTV as a means of recording, and found it difficult to
configure. I quickly abandoned it and chose NextPVR instead. And since that
wasn't (at the time) available on Linux, I changed from NextPVR to TVHeadend
when I moved from a Windows PC to a lower-powered Raspberry Pi as the
recording device.
I now record using TVHeadend on a Pi, but I use a Windows PC to store the
recordings, watching a lot of them on that PC, but also running Plex server
on the PC and a Plex client on a Roku that is connected by HDMI to the main
TV. I separated out the functionality for several reasons:
- didn't want the workload of playing the video in VLC to affect the
integrity of recordings that were being made at the same time, leading to
dropped frames and other glitches
- didn't want to have to keep a couple of multi-TB HDDs spinning all the
time; instead just use a single HDD as the temporary recording storage; at
present that disc is a spinning one, but I might be able to save power by
using a solid state HDD instead
- although Plex server will run on a Pi4, it makes the CPU usage and
temperature shoot up when a video is being served to the Roku Plex client; a
lot of that is due to the stupid transcoding that takes place between the
raw MPEG/H264 TS file and whatever bizarre format the client wants to see -
why couldn't the client be left to decode the TS file served by simple SMB
over the network?