Grounding an Appliance

[JohnW2]

I do not know much about TV advertisements in this country. (Australia) (I see them mainly when they are reviewed on Gruen !) ... Apart from a nightly News Program, I do not watch much TV directly but set up my PVR to record that which I might wish to view at a later time - at my convenience and NOT that of any broadcaster. ... (Of course, I then "fast forward" over all the advertisements.)

I think that's true of many people here - like, as I've said, my wife.

I am quite amazed that statistics seem to indicate that only about half the households in this country have a PVR, since the precursors to this in the form of VHS and even Beta tape recorders seemed to be so common.

In the UK, I think that all 'boxes' used to access satellite TV channels, and many (most?) of those used to access digital terrestrial channels come with PVRs as standard (often quite 'clever' ones - e.g. that can record two or more programmes at once, whist simultaneously watching a previously recorded ones - and which always record a channel being watched live, so that one can 're-wind' if desired).

As Harry has said, one doesn't even have to wait until after the live broadcasting of a programme has finished before one can start 're-viewing' it and fast-forwarding over the adverts. One merely has to start 'watching' a few minutes after the broadcast starts - since the machines can simultaneously continue recording a programme whilst replaying bits of the same programme that it has already recorded.

This increasing ability of people to 'evade' the advertisments by viewing recorded programmes has lead to an increasing prevalence of "product placement" within programmes, which people can't really avoid. I have a feeling that such is not necessarily allowed in all countries.

Kind Regards, John

 

[FrodoOne]

I would think streaming and 'catch up' services make a separate PVR virtually unnecessary.

Actually NO!
Some programs are NOT later available on the "streaming services", possibly because of copyright limitations.
Also, when viewing "streaming" programs from commercial TV channels one is subjected to "commercials" at regular intervals.

One can record these streams and view them later skipping over the commercials (if one has the facilities to overcome that with which these channels try to prevent this) but it is a bit of an effort.
(The 1x2MN3D HDMI splitter comes to mind as a way of getting over the above "problem".)

 

[EFLImpudence]

Perhaps it is different in Australia.

With the local programme supplier here, all programmes are viewable for seven days (and, as john says for example, just a few minutes late) and it is possible to then fast forward through the adverts.
Plus I can 'record' them and keep - not sure if there is a maximum time; assume there must be - when they are stored in the cloud.

It is slightly different regarding the adverts in UK programmes but Channel 4 only shows the sponsor (not sure of the word) message and a trailer when watching on catch-up. ITV do show adverts which one has to watch.

 

[Harry Bloomfield]

I would think streaming and 'catch up' services make a separate PVR virtually unnecessary.

As I pointed out elsewhere - An HDD attached to my TV, allows any channel on the TV and live, to be paused. Pause it for a few minutes at the beginning, then press play - you can then FF through the adverts. I do it quite a lot. The HDD equally allows me to record anything which is on, whether I'm in or not, to watch it later.

 

[SimonH2]

This increasing ability of people to 'evade' the advertisments by viewing recorded programmes has lead to an increasing prevalence of "product placement" within programmes, which people can't really avoid.

And you may have noticed a lot more short ads at the start and end of the profram segments/ad breaks. I believe these few seconds are now worth more than the time in between as they are hard to miss.
I use MythTV for nearly all my viewing, and that has a skip forward/back which is far better than ff/rew but it's unusual to miss that short product placement slot without missing a bit of the program.
I now have a quad tuner in it, each configured with 3 virtual tuners - so in principle I could record up to 12 simultaneous programs off up to 4 Freeview muxes, while watching a different recording on each telly (only 2 at the moment as the 3rd PC is faulty) ! I think I'd hit some disk I/O issues first though.

 

[JohnW2]

And you may have noticed a lot more short ads at the start and end of the profram segments/ad breaks. I believe these few seconds are now worth more than the time in between as they are hard to miss.

Yes, and that makes sense. One can't blame them (from their POV) for trying to retain some 'hard to avoid' ads!

I use MythTV for nearly all my viewing, and that has a skip forward/back which is far better than ff/rew but it's unusual to miss that short product placement slot without missing a bit of the program.

I don't know what MythTV is, but it's presumably not possible to 'skip forward' a programme one is watching in real ('broadcast') time?

I now have a quad tuner in it, each configured with 3 virtual tuners - so in principle I could record up to 12 simultaneous programs off up to 4 Freeview muxes, while watching a different recording on each telly (only 2 at the moment as the 3rd PC is faulty) !

As I recently wrote, these machines are getting very clever at this 'multi-tasking'

I think I'd hit some disk I/O issues first though.

I must say that I've often wondered how the HDDs manage to avoid 'shaking themselves to bits' very rapidly, since the heads must be going crazy jumping backwards and forwards between different places on this disks at almost unimaginable speeds!

Kind Regards, John

 

[Harry Bloomfield]

I must say that I've often wondered how the HDDs manage to avoid 'shaking themselves to bits' very rapidly, since the heads must be going crazy jumping backwards and forwards between different places on this disks at almost unimaginable speeds!

They will be using sequential segments, for the different recording intertwined, at a guess.

 

[JohnW2]

They will be using sequential segments, for the different recording intertwined, at a guess.

Yes, I imagine they try to do something like that when recording two or more programmes simultaneously, However, what if, at the same time as those recording activities, one is simultaneously viewing some previously-recorded programme - given that there can be no guarantee that it won't be located at some distant part of the same platter one is recording on?

Kind Regards, John

 

[plugwash]

According to wikipedia even a cheap 5400 RPM hdd can do about 50 IO operations per second. With modern (or even a decade ago) ram prices buffering a few seconds video should be no big deal. Even a cheap HDD should easily handle multiple independent video operations at the same time.

 

[Harry Bloomfield]

Yes, I imagine they try to do something like that when recording two or more programmes simultaneously, However, what if, at the same time as those recording activities, one is simultaneously viewing some previously-recorded programme - given that there can be no guarantee that it won't be located at some distant part of the same platter one is recording on?

Kind Regards, John

Memory buffering?

 

[JohnW2]

According to wikipedia even a cheap 5400 RPM hdd can do about 50 IO operations per second. With modern (or even a decade ago) ram prices buffering a few seconds video should be no big deal. Even a cheap HDD should easily handle multiple independent video operations at the same time.

Memory buffering?

Yes, I presume that the answer has to be in buffering. Indeed, there obviously has to be some (whether internal and/or external to the HDD), otherwise it often just wouldn't work (sensibly) at all.

Indeed, I suspect that even the "50 IO operations per second" mentioned by plugwash probably relies upon (I assume 'internal') buffering, because, in the worse-case situation of alternate operations being at physically very separated locations on the disk, I would somewhat doubt that the head(s) could move fast enough (at least, without 'shaking themselves to pieces') to do those 50 (logical) I/O operations as 50 (physically and temporally) separate ones. However, that's all 'gut feeling', since I don't know the facts.

None of this alters the fact that I am extremely impressed by what these things can do - in some cases things which would have been totally unthinkable not all that long ago.

Kind Regards, John

 

[FrodoOne]

Memory buffering?

My own PVR is a Beyonwiz T4, which can record programs on 4 different channels at once. (https://beyonwiz.com.au/t4/manual/Beyonwiz_T4_User_Manual_eng 090614.pdf)
Quite often I find that it IS recording 3 programs at once (while I am watching something previously recorded) but that is partly because I record sequential programs on the same channel as two separate programs and there is an overlap (built into the "Setup" - and adjustable) so that a number of minutes may be recorded before the program's nominal start time and a much larger number of minutes may be recorded after the program's nominal finish time. This is because many programs on the commercial channels often run "late", so the extra recording time is required in order that the program end is recorded when that happens!

I note in the specifications of this PVR that it has
2 GB NAND Flash Memory and
2 GB DDR SDRAM Memory

I also note that a 1 hour of a Standard Definition program occupies about 2 GB on the hard drive (The installed hard drive is 2 TB - in my case)

While I do not know how all that memory is being manipulated, it is obvious that many minutes of up to the 5 programs which can be manipulated at once can be stored in memory before it is necessary to write onto the hard drive or read more program information from the hard drive.
Hence it seems that the head would not need to jump about so much that it would "shake itself to pieces".

(This thread seems to have drifted from its original topic!)

 

[SimonH2]

I don't know what MythTV is, but it's presumably not possible to 'skip forward' a programme one is watching in real ('broadcast') time?

Yes it does do ff/rew - but jump forward/back is far quicker and easier to use. Instead of going to FF and watching while the crazy high-speed people go running around, and still take a minute or two to skip a 4 minute ad break - just tap the right key and you're 30s (configurable) ahead, tap agin for another 30s. If you know how long the ad breaks are (e.g. a lot I find are 4 minutes) then press "4" and the jump forward key and you're 4 minutes ahead. It also has the ability to scan recordings and detect the ad breaks, but it tends not to be too reliable on UK TV.
MythTV is a free & open source PVR application which I believe can be run on Windows and Mac OS as well as Linux - but Linux is where the bulk of the development and support happens. It's not something to go for if you want "plug and play" as the learning/setup can be a fair hill to climb. But if you're prepared to put that effort in, you get a networked (one primary backend, additional backends if needed, multiple frontends) PVR where storage is limited only by the disk space you feed it, tuners only by your ability to connect them, amount recorded limited only the disks to handle the data, and it records programs by rules - so will automagically take care of (e.g.) recoding a second showing of one program to allow the tuner to be used for a program that doesn't have an alternative showing to record.
With DVB (T or S) it can record multiple programs off one transport - I have my new tuner set to limit this to 3, and there are four tuners on the card, making a total of 12 virtual tuners.
Each frontend can watch anything independently of the others, and independently of what's being recorded. You can start watching a recording while it's still in progress - and that does give you the ability to skip through the ads.
Using it to watch live TV is a bit weak - and TBH I don't actually do that. I think it's a case of few of the devs use that so it really doesn't get a lot of attention.

As I recently wrote, these machines are getting very clever at this 'multi-tasking'

In the case of MythTV it's fairly simple - each task is a separate process. So when a recording is going on, there is a process (actually two for reasons I won't go into unless you want a discussion on caching algorithms ) slurping data from the tuner to a file on disk - each recording is just a file on disk. The main program simply notes when a recording is due to start and fires up the relevant program to do it. Similarly, when a frontend starts showing a recording, a backend process starts up to stream the file to it. Scheduling (determining what to record, when, and on which tuner) is another process kicked off whenever anything changes - such as adding/deleting/changing a recording rules, new listings imported.

I must say that I've often wondered how the HDDs manage to avoid 'shaking themselves to bits' very rapidly, since the heads must be going crazy jumping backwards and forwards between different places on this disks at almost unimaginable speeds!

Recording is the hardest (sustained) load on disks. For a number of technical reasons, part of the process while recording is to "fsync" the file - which tells the OS (Operating System) to write out anything it currently has in it's buffers for that file. So the data in the buffers is written, and the file system tables must also be updated. This means a minimum of two separate writes, to two different places, every second - you can hear the disks ticking as the heads move.
Recording two programs ? 4 separate writes/second. 3 recordings ? 6 writes/second. I don't know what my system limits are, but in the past I've seen at least 6 recordings going across 2 disks.
Key here are two specifications for the disk - seek time and rotational latency. The head needs to seek to the right track, then it must wait for the right bit of that track to come round as the disk spins. Seek times are typically quoted for adjacent track (typically quite quick) and average (average time to seek from "any track" to "any other track") - worst case is seeking from innermost track to outermost track (or vice-versa). Rotational latency depends primarily on rotational speed - which is why a 15k (15,000 rpm) disk is a lot quicker than a 5400 rpm drive, but at the expense of needing more power and generating more heat. Hmm, I've just been looking up the specs of my drives, and neither manufacturer (WDC and Toshiba) quotes seek times - that's really strange, it always used to be one of the key parameters for a drive But the WDC drive is one of their "Purple" drives which is optimised for surveillance systems use - i.e. recording multiple streams from multiple cameras, and is rated for "up to" 64 cameras. From discussions on the mailing list, it seems that people are managing far more consecutive recordings than I do per drive without seemingly hitting limits - 2,4,6, 8 seeks/second isn't actually very high at all, get a really busy system going and the drives can be "buzzing". With rotation latency a few ms, and typical seek times in a similar order of magnitude, you can see that even a modest spec (I think mine are 5400 and 7200 rpm) drive should be able to manage several recordings without too much trouble.
One key though is advice for MythTV setup is to never have your recordings and the OS & database on the same drive(s). The database can be very busy, and that can easily cause problems if it shares the same disk as a recording. I have everything but the recordings on a mirrored pair of SSDs.

 

[JohnW2]

Yes it does do ff/rew - but jump forward/back is far quicker and easier to use. ....

Fair enough - but it doesn't alter my point to which you are responding - namely that it's clearly impossible to 'jump forward' (or 'fast forward') in a program that one is watching in real (broadcast) time.

In the case of MythTV it's fairly simple - each task is a separate process. .....

That I assumed, but I've been talking exclusively about the issues of I/O to what is (to the best of my knowledge) nearly always (in PVRs, Sky/Freeview boxes etc.) a single HDD. However, as has been discussed, that must all be down to buffering/caching, both within and outside of the HDD.

Recording is the hardest (sustained) load on disks. .....

That may be true, but there is still an issue with simultaneous reading if that is happening at a physically very different part of the disk from the writing. However, again, I presume that's all down to buffering/caching - of both read and write operations.

Kind Regards, John

 

[SimonH2]

Fair enough - but it doesn't alter my point to which you are responding - namely that it's clearly impossible to 'jump forward' (or 'fast forward') in a program that one is watching in real (broadcast) time.

Clearly one can't jump forward past the live transmission point. But you can pause/jump back/jump forward as much as you want as long as you don't go forward past "live". With Myth even watching live TV is done by recording the stream and watching the recording - and I suspect that's the case with other PVR systems. Within the constraints of not going past the beginning or end, it's just another recording

That I assumed, but I've been talking exclusively about the issues of I/O to what is (to the best of my knowledge) nearly always (in PVRs, Sky/Freeview boxes etc.) a single HDD. However, as has been discussed, that must all be down to buffering/caching, both within and outside of the HDD.

Yes, buffering is the key - but typically not as much as you might think.
Recording is in some ways the less onerous since a delay doesn't matter provided you don't lose any data. But this is where it can get "interesting". Unless the system is tuned for the task, what can happen is that the OS caches writes while it has free memory - then at some point it will write some or all of it out. It might seem that having lots of memory for the buffer, but what can happen is the system can almost pause if it needs memory and has to weite the cache out. So Myth has one process that just grabs bytes as they come in from the tuner and stuffs them in a modest sized circular buffer. - a small code loop designed to avoid any loss of data from not reading from the hardware buffer quickly enough A second process wakes up roughly once a second, grabs any data from the buffer and writes it to the file (which the OS caches) - and to avoid the OS cache building up, the write process tells the OS to flush it to disk.
Reading is simpler - the process simply reads the file and streams it to the frontend as the frontend asks for more data. The frontend buffers this so it cab play from the buffer if there's a delay getting more data - but that buffer is only a few seconds. There's a tradeoff in that a larger buffer takes more filling when starting up - and that makes the system feel sluggish.
If you think about it, anything involving disk i/o must involve some buffering since modern disks all have a sector size of 4k - which is only around 5 to 10ms of video at typical DVB-T bitrates (if my mental arithmetic is correct !).

That may be true, but there is still an issue with simultaneous reading if that is happening at a physically very different part of the disk from the writing. However, again, I presume that's all down to buffering/caching - of both read and write operations.

Correct. Although as previously noted, the delay shifting fron one track to another is quite small - so in general little buffering is needed.
There is also the option of readahead. Many drives do this internally - you read one block, the drive reads the next few and holds them in RAM ready for the system to read them. The system can also do that.
Most modern drives have huge amounts of RAM - many times what I had in my first computer.