A Home cinema forum. HomeCinemaBanter

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » HomeCinemaBanter forum » Home cinema newsgroups » UK digital tv
Site Map Home Register Authors List Search Today's Posts Mark Forums Read Web Partners

Programme cut short



 
 
Thread Tools Display Modes
  #1  
Old October 10th 18, 03:45 PM posted to uk.tech.digital-tv
Davey
external usenet poster
 
Posts: 2,334
Default Programme cut short

I sat down this morning to watch my recording of Ch. 5's WRC Welsh
Rally, and just before the end, it was uncertain who was about to win
it. Then the recording stopped, according to the signal sent out by Ch.
5. I happened to have it on a second recorder, and it was the same. It
was as though somebody had waited for a crucial moment, and decided to
really mess up us watchers.

Luckily, I was able to catch it on My5 Catchup, but it was really bad
programming.

--
Davey.
  #2  
Old October 10th 18, 04:32 PM posted to uk.tech.digital-tv
[email protected]
external usenet poster
 
Posts: 29
Default Programme cut short

On Wed, 10 Oct 2018 14:45:05 +0100
Davey wrote:
I sat down this morning to watch my recording of Ch. 5's WRC Welsh
Rally, and just before the end, it was uncertain who was about to win
it. Then the recording stopped, according to the signal sent out by Ch.
5. I happened to have it on a second recorder, and it was the same. It
was as though somebody had waited for a crucial moment, and decided to
really mess up us watchers.


Thats probably when the sheduled program was due to end and they didn't
bother to update the EPG. I've set up my box to always record another 15 mins
onto the end of any program just in case as this sort of thing happens a lot
especially on the minor channels like Quest.

  #3  
Old October 10th 18, 05:10 PM posted to uk.tech.digital-tv
NY
external usenet poster
 
Posts: 1,567
Default Programme cut short

wrote in message news
On Wed, 10 Oct 2018 14:45:05 +0100
Davey wrote:
I sat down this morning to watch my recording of Ch. 5's WRC Welsh
Rally, and just before the end, it was uncertain who was about to win
it. Then the recording stopped, according to the signal sent out by Ch.
5. I happened to have it on a second recorder, and it was the same. It
was as though somebody had waited for a crucial moment, and decided to
really mess up us watchers.


Thats probably when the sheduled program was due to end and they didn't
bother to update the EPG. I've set up my box to always record another 15
mins
onto the end of any program just in case as this sort of thing happens a
lot
especially on the minor channels like Quest.


Yes I routinely add 5 mins of padding before any recording (in case the
programme starts early) and 10 mins of padding afterwards (in case it
finishes late).

  #4  
Old October 11th 18, 01:40 AM posted to uk.tech.digital-tv
Davey
external usenet poster
 
Posts: 2,334
Default Programme cut short

On Wed, 10 Oct 2018 16:10:45 +0100
"NY" wrote:

wrote in message
news
On Wed, 10 Oct 2018 14:45:05 +0100
Davey wrote:
I sat down this morning to watch my recording of Ch. 5's WRC Welsh
Rally, and just before the end, it was uncertain who was about to
win it. Then the recording stopped, according to the signal sent
out by Ch. 5. I happened to have it on a second recorder, and it
was the same. It was as though somebody had waited for a crucial
moment, and decided to really mess up us watchers.


Thats probably when the sheduled program was due to end and they
didn't bother to update the EPG. I've set up my box to always
record another 15 mins
onto the end of any program just in case as this sort of thing
happens a lot
especially on the minor channels like Quest.


Yes I routinely add 5 mins of padding before any recording (in case
the programme starts early) and 10 mins of padding afterwards (in
case it finishes late).


My PVR is set to Accurate Recording, which follows the signal sent by
the broadcaster. Padding is not normally required, as long as the
signal is correctly sent, which this one was not.

--
Davey.

  #5  
Old October 11th 18, 11:46 AM posted to uk.tech.digital-tv
NY
external usenet poster
 
Posts: 1,567
Default Programme cut short

"Davey" wrote in message
news
Yes I routinely add 5 mins of padding before any recording (in case
the programme starts early) and 10 mins of padding afterwards (in
case it finishes late).


My PVR is set to Accurate Recording, which follows the signal sent by
the broadcaster. Padding is not normally required, as long as the
signal is correctly sent, which this one was not.


That's why I use padding: I've been caught out too many times with accurate
recording being *not* accurate :-( In the days of VHS, you wanted your
recordings to use the minimum of space so you could get exactly three 1-hour
programmes on a 3-hour tape. But nowadays with hard disc space being so
cheap, it doesn't matter if you record some crap at the beginning and the
end. And I tend to edit that off (together with commercials) before watching
or adding to my library. All that matters is that the padding at the end of
one programme doesn't prevent a programme on a different multiplex from
recording completely. My PC has two DVB-T receivers so I can record
overlapping or immediately-following programmes on different multiplexes,
and two programmes on the same mux will record using the same receiver even
if they overlapp because of padding.

I've just "upgraded" my recording computer from Windows 7 to a Raspberry
Pi - lower power computer, but much lower power consumption so I don't mind
leaving it on 24/7 for recording TV and for logging data from my weather
station.

  #6  
Old October 11th 18, 12:53 PM posted to uk.tech.digital-tv
Roderick Stewart[_3_]
external usenet poster
 
Posts: 2,411
Default Programme cut short

n Thu, 11 Oct 2018 00:40:17 +0100, Davey
wrote:

Yes I routinely add 5 mins of padding before any recording (in case
the programme starts early) and 10 mins of padding afterwards (in
case it finishes late).


My PVR is set to Accurate Recording, which follows the signal sent by
the broadcaster. Padding is not normally required, as long as the
signal is correctly sent, which this one was not.


That seems like a good case for not relying on it. If you want
something done properly, do it yourself.

Rod.

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

  #7  
Old October 11th 18, 01:04 PM posted to uk.tech.digital-tv
Davey
external usenet poster
 
Posts: 2,334
Default Programme cut short

On Thu, 11 Oct 2018 11:53:07 +0100
Roderick Stewart wrote:

n Thu, 11 Oct 2018 00:40:17 +0100, Davey
wrote:

Yes I routinely add 5 mins of padding before any recording (in case
the programme starts early) and 10 mins of padding afterwards (in
case it finishes late).


My PVR is set to Accurate Recording, which follows the signal sent by
the broadcaster. Padding is not normally required, as long as the
signal is correctly sent, which this one was not.


That seems like a good case for not relying on it. If you want
something done properly, do it yourself.

Rod.



The fact that this occasion stands out shows that it is very rare for
it to fail. I had several 'padding' failures before I decided on AR as
the best method.

--
Davey.
  #8  
Old October 11th 18, 02:35 PM posted to uk.tech.digital-tv
Jeff Layman[_2_]
external usenet poster
 
Posts: 817
Default Programme cut short

On 11/10/18 12:04, Davey wrote:
On Thu, 11 Oct 2018 11:53:07 +0100
Roderick Stewart wrote:

n Thu, 11 Oct 2018 00:40:17 +0100, Davey
wrote:

Yes I routinely add 5 mins of padding before any recording (in case
the programme starts early) and 10 mins of padding afterwards (in
case it finishes late).


My PVR is set to Accurate Recording, which follows the signal sent by
the broadcaster. Padding is not normally required, as long as the
signal is correctly sent, which this one was not.


That seems like a good case for not relying on it. If you want
something done properly, do it yourself.

Rod.



The fact that this occasion stands out shows that it is very rare for
it to fail. I had several 'padding' failures before I decided on AR as
the best method.


+1

Been using it for years. I doubt that it has failed on more than a very
few occasions of the many hundreds of recordings made during that time.

--

Jeff
  #9  
Old October 11th 18, 07:35 PM posted to uk.tech.digital-tv
Johnny B Good[_2_]
external usenet poster
 
Posts: 574
Default Programme cut short

On Thu, 11 Oct 2018 10:46:18 +0100, NY wrote:

"Davey" wrote in message
news
Yes I routinely add 5 mins of padding before any recording (in case
the programme starts early) and 10 mins of padding afterwards (in case
it finishes late).


My PVR is set to Accurate Recording, which follows the signal sent by
the broadcaster. Padding is not normally required, as long as the
signal is correctly sent, which this one was not.


That's why I use padding: I've been caught out too many times with
accurate recording being *not* accurate :-( In the days of VHS, you
wanted your recordings to use the minimum of space so you could get
exactly three 1-hour programmes on a 3-hour tape. But nowadays with hard
disc space being so cheap, it doesn't matter if you record some crap at
the beginning and the end. And I tend to edit that off (together with
commercials) before watching or adding to my library. All that matters
is that the padding at the end of one programme doesn't prevent a
programme on a different multiplex from recording completely. My PC has
two DVB-T receivers so I can record overlapping or immediately-following
programmes on different multiplexes, and two programmes on the same mux
will record using the same receiver even if they overlapp because of
padding.

I've just "upgraded" my recording computer from Windows 7 to a Raspberry
Pi - lower power computer, but much lower power consumption so I don't
mind leaving it on 24/7 for recording TV and for logging data from my
weather station.


Ever since I was forced by a major hardware upgrade some 3 1/2 years
back to give up win2k, I've been running Kaffeine under Linux Mint 17.1
to record the Beeb's SD broadcasts from the single SD MUX using the
KWorld twin tuner DVBT adapter for which there had never been any win2k
driver software.

Great, at last a means of recording two simultaneous broadcasts you
might think but, except when I was occasionally recording the odd "Red
Dwarf" episode from Dave on a commercial MUX, the extra tuner was
overkill for 99.9% of the time since Kaffeine could, I accidentally
discovered, record every single TV stream in a MUX simultaneously anyway,
making padding/channel conflicts a nightmare of the past.

There were even times when EPG updates would create confusion in the
order of two back to back programme timings to the extent that I could
simply record both programmes to two separately named files
simultaneously and sort out the confusion by simply deleting the wrongly
named files in a "Shoot First, Ask Questions Later" process rather than
sorting out a possible misnaming error by faffing around with renaming
the two singular copies later on - deleting is a lot simpler than
renaming. :-)

Oh the contrast between using "DTVR" under windows and Kaffeine under
Linux Mint was like night and day (on an overcast moonless night after a
midsummer day's cloudless sky)!

All I had to do to set up a recording schedule was to trawl through the
week's epg listings and mark each programme of interest for inclusion
into the schedule without any concern whatsoever for padding/channel
conflicts (I had Kaffeine configured to globally apply 2 minute start and
3 minute end paddings on each recording).

Since Kaffeine recorded 'silently' (watching 'live' was a completely
independent function), unlike DTVR in win2k which fired up the 'live
view' window in order to run its recording operation (the only way to
achieve 'silent recording' was to minimise its window and mute the master
volume control), I never recorded so much "TV" yet watched so little.

The other nicety of using Kaffeine was being able to have three (or even
more) programmes actively recording simultaneously and be able to watch
any one of the growing .ts files using VLC independently as they were
being recorded right through to the end even if started with only a few
minutes of the programme captured thus far at that stage of the
proceedings.

Your point about HDD storage being cheap is well made. The error of any
recordings that turned out to be a waste of disk space could be corrected
in an instant by a simple act of deletion. :-)

These days, the padding facility no longer matters so much since I now
only record 5 minute snippets to create a 'to do' list for get_iplayer's
download schedule (I have to manually edit the recording schedule to
achieve this since there's no way to automate a "Five minute only
snippet" recording option).

The reason for editing most of the scheduled recordings down to 5 minute
snippets is simply to minimise wear on the 240GB SSD to halt the effect
of allowing what had been a manageable rate of wear on the drive to begin
with to get out of hand with the extra traffic generated by get_iplayer's
downloads and processing of same into finalised MP4 files ready for
archiving to the NAS box.

In essence, the 15GB a day's worth of Kaffeine's recordings had been
tripled up to 45 GB's worth a day which had gone on for about 18 months
or so and was starting to prey on my mind as "Something I ought to do
something about" before the gyppos running the iPlayer concession had
decided to drop the 1GB/hour 25fps 1280x720 'half HD' downloads in favour
of the 2.3GB/hour 50fps 1280x720 downloads which increased the daily
traffic to a totally untenable 60 to 80GB.

My solution was to move get_iplayer's recordings folder onto one the HDDs
and use the --raw option to suppress a pointless ffmpeg recoding process
(I was using the more effective Handbrake option to convert the 2.3GB .ts
downloads into 50fps 1.2GB mkv files (originally, I'd been converting
them into 25fps recordings but dropped this when I realised I could
create fractionally smaller mkv files if I didn't bother converting the
fps from 50 to 25!).

As best as I could figure it, I'd already clocked up some 50TBW out of
the meagre 75TBW allowance which trumps the 5 year time limited warranty
that Samsung offers on this drive. Since I'd like to reach the 5 year
limit before hitting the paltry 75TBW limit as I'd originally planned,
I'm minimising the traffic produced by Kaffeine's recording operations,
hence the 5 minute snippets limit on most of Kafeine's scheduled
recordings. Assuming my 50TBW figure is right, that should preserve the 5
year warranty, by which time, the SSD will be well and truly overdue for
a well deserved upgrade anyway.

--
Johnny B Good
  #10  
Old October 11th 18, 09:16 PM posted to uk.tech.digital-tv
NY
external usenet poster
 
Posts: 1,567
Default Programme cut short

"Johnny B Good" wrote in message
...
I accidentally
discovered, record every single TV stream in a MUX simultaneously anyway,
making padding/channel conflicts a nightmare of the past.


One of my two DVB-T decoders (PCTV 292e) can do this when driven by VLC
(Media | Open Capture Device) - I've recorded the whole of a DVB-T or DVB-T2
multiplex - mainly because it's possible rather than so I can record now and
copy to separate programmes at a later stage. The other decoder (Hauppauge
Win-TV Nova) fails miserably at this task, but then it is rather a tall
order. I can certainly record two or three channels on the same mux using
either decoder, using NextPVR (Windows) or TVHeadend (Pi).

It's fairly rare that I need to record more than one mux at once, but it's
nice to have the ability to spill over onto a second decoder in case I need
a bit of overlap time.

At present, I've not completely cracked the problem of TVHeadend writing its
recordings to an external USB device (pen drive or hard disk) that is
mounted into the Unix filesystem. 99% of the time it works fine, but
occasionally I get the dreaded "file missing" error which means that for
some weird reason TVH refuses to write to the USB device, even though I can
still copy to or from it from UNIX commands or even from Windows via a Samba
share. Since I've told it to write to the Pi's SD card, I've not had that
problem. I just need to make sure I copy recordings (via the Samba share) as
soon as they have finished recording so as not to fill up the card.

It was a symbolic occasion the other night when I put my Windows PC to sleep
the other night until I needed it the following day, now that TV recording
and weather station data logging are both done by the Pi. :-)

 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Sweeney Todd cut short. AJM UK digital tv 19 January 6th 06 02:34 AM
TiVo recordings coming up short -- WAY short Jim Beaver Tivo personal television 9 January 19th 05 06:05 PM
Mordaunt Short Avant 908 vs Mordaunt Short 502 THX Simon UK home cinema 0 May 17th 04 08:35 PM
Analog Television cut off Skip High definition TV 20 April 22nd 04 04:52 PM
Hitachi 57S500 - cut-off screen Owlman High definition TV 7 November 8th 03 02:28 PM


All times are GMT +1. The time now is 04:36 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
Copyright 2004-2018 HomeCinemaBanter.
The comments are property of their posters.