[mythtv-users] PVR-350 won't record without reboot

[f-myth-users at media.mit.edu]

    > Date: Sun, 22 Nov 2009 00:40:04 -0500
    > From: "Michael T. Dean" <mtdean at thirdcontact.com>

    > On 11/21/2009 10:25 PM, f-myth-users at media.mit.edu wrote:
    > >     > Date: Sat, 21 Nov 2009 20:59:20 -0500
    > >     > From: "Michael T. Dean" <mtdean at thirdcontact.com>
    > >
    > >     > And note that MythTV trunk can still use the PVR-350 TV out with the 
    > >     > ivtvfb module and Xv video output.  So, all you lose on the PVR-350 is 
    > >
    > > ...although I think this was broken in a recent X and fixed last week;
    > > there was traffic on the ivtv list recently that I can look up and
    > > point to if anyone needs to know.  But it may be an issue with the
    > > latency with which it works its way through various distros release
    > > pipelines, etc.

    > Good info.  That may be  important for anyone who is still using the 
    > PVR-350 TV out.  Thanks.

Look for a message from Ian Armstrong from almost exactly a week ago
about xf86-video-ivtv.  I'm not sure (because I haven't done the
research) which X.org version broke the framebuffer, so I'm not
sure how much of a problem this is going to be.

    > > >     > the anachronistic 480i60 (576i50 for PAL) MPEG-2 decoder--where even toy 
    > > >     > CPU's can decode standard definition MPEG-2 at 50/60 fields per second 
    > > >     > without breaking a sweat.  It's not 1999, anymore.  :)
    > > >
    > > > You also lose the ability to let the TV decode the closed captions
    > > > itself from things you recorded on PVR-x50 tuners, and must instead
    > > > rely on Myth being able to extract the captions from the source and
    > > > then superimpose them back on the screen using its internal player.  I
    > > > get the feeling that handling captions is a perennial afterthought for
    > > > most people, and I've seen various complaints about them being broken
    > > > in various ways at various times in Myth, but I'm not sure about their
    > > > current status

    > I can say that I can't remember the last show I watched without 
    > captions--other than ones where the network breaks/messes up the 
    > captions to the point they're not useful.  (To the point that I actually 
    > recognize the work of captioning organizations that do the best/worst 
    > jobs with captions in the shows I watch.)  If they stopped working for 
    > me, I'd notice.

Good. :)

    > Sure, I would love to do some work on improving the EIA-708 caption 
    > support in Myth, but I haven't gotten around to it since the EIA-608 
    > captions work fine.

Anything that works with NTSC SD is fine with me.

    > And, yes, I'm only testing the EIA-608/EIA-708 captions in my ATSC 
    > recordings, but I haven't used a PVR-x50 for 3 years, now, so it's hard 
    > for me to test those on a frequent basis.  I'd guess, though, that in 

I -think- I recall other PVR-x50 users using captions from STB's, but
I'm unsure.  That's absolutely how I use them (given that all unencrypted
cable is basically gone for me and hence all my programming comes off
an STB; it used to come straight off the coax into the 250's RF).

And I have to admit, the quality varies all over the map.  Successive
airings of the same show can show extensive dropped characters (one of
my PBS channels had an issue for months) that aren't there in the next
one---and this is coming off an STB that's fed a digital stream, so
it's not like I was getting some sort of signal fade that killed line
21 but somehow didn't impact the video.  Often it's pretty obvious
that they do some horrible live transcription and then in a repeat
months later have used the script instead.  Somehow Mythbusters has
gotten away with precisely 5 shows including CC the last 5? years.
(But Dirty Jobs, also on Discovery, captions every one.  Go figure.)
I've seen successive airings of the -same- show where an entire
segment of captions between a pair of commercials (e.g., many minutes)
is just -gone- and then a repeat of the same show, even on the same
day, has them back.  Plays merry hell with some of the stuff I do.

    > today's US (where the transition to digital OTA has been made), since 
    > the users of PVR-350's would be using some other receiver (such as a 
    > cable- or satellite-STB), any breakage of captions is more likely due to 
    > problems with the STB's output of them than problems with Myth's ability 
    > to use them.  (Or, potentially, for some PVR-x50's/500's, problems with 
    > ivtv drivers--though I don't know the status of that one, some have 
    > mentioned there may be issues with some cards/drivers.)

Yes, there was a time when I think all -150 and -500 CC decoding
was broken for quite an interval.  I believe they've been fixed.
(I wouldn't be able to test that; I'm a 250/350 shop.)  It also
doesn't help that there are two ways of getting VBI data off the
cards (sliced and unsliced) and they can break in different ways.

    > > ---because when I want closed captions, I tell my TV to
    > > display them from what the 350 is feeding it...  [It also means you
    > > must find somewhere on your remote to bind the relevant key so that
    > > you can tell Myth enable/disable captioning, instead of using the
    > > remote for the TV itself.  This can be a problem if you're already
    > > short of buttons on the remote that Myth is listening to.]

    > Well, LIRC modes can help with that--or, for that matter, just 
    > programming the TV remote to work with LIRC, too, and intercepting the 
    > closed-caption button.  :)

I knew you'd suggest that. :)  Of course, for any given user, that
depends on their normal remote -and- their TV remote both using a
modulation protocol that their IR receiver can even see.  That's
not always an option.

    > > (If the various nVidia cards that do VDPAU have the ability to feed
    > > such captioning directly to the TV on line 21 when using their S-Video
    > > outputs, I've sure never heard of it.)
    > >
    > > This is something I'm going to be tripping over firsthand once I go
    > > to 0.22 and a VDPAU card; I'd like to take NTSC SD video, transcode to
    > > H.264 to save space, and then play it back on a VDPAU card.  How well
    > > are people finding closed-captioning is doing when thrown into this
    > > mix?  Any advice?

    > I can tell you that all of Myth's transcoding--save lossless MPEG-2 
    > transcodes--will strip out any captions/subtitles (and even the lossless 
    > can mess them up a bit, especially around cuts).

Yeah, that I know.  And ivtv's CC-embedding in the MPEG2 stream is
-really- nonstandard; I don't know of any tool that will preserve them
if any editing goes on, so I don't edit.

(See question below re ccextractor & editing.)

    > 						      My best suggestion 
    > would be to get a new 1TB to 2TB HDD or more...  (That's a serious 
    > suggestion.  IMHO, the energy cost of transcoding isn't worth the space 
    > saved--in some cases is greater than the cost of the space saved.  The 
    > latter being especially true when using older/smaller hard drives (or 
    > worse, multiple older, smaller hard drives) that could be replaced with 
    > larger/newer/more energy-efficient ones.)

...but a nonstarter in my case, unfortunately, since I need to cut a
constant factor off the rate of growth and H.264 will do that, if I'm
lucky (I'm assuming I can get 3x and will be testing that).  I use
video in a nonstandard way compared to normal viewers and storage is
an issue.  (Most of the video-storage drives will be spun down most of
the time; think of an archive where video being actively processed is
on spinning storage and the rest is parked on drives in standby or
truly off and you'll approximate the architecture.  Even an efficient
1.5T drive can be made more efficient by turning it off. :)  But I
would rather burn the power crunching down SD (which should be a lot
less power than crunching down HD) to save money (and space! including
how they're connected to anything) on the drive hardware.

Back to captioning:

I currently grab captioning data (for use outside of Myth) using
streamparser/dumpvbi and a lot of custom code that does lexical
processing on it for use upstream by various machine-learning
dohickeys.  I haven't had to worry about how -Myth- uses CC so far
because of my 350, but I always scrutinize any message to the lists
that talks about CC handling, because it's so very important to me.

As for use by Myth in non-350 playback, I'm assuming that ccextractor
can be used to snarf the captions out of NTSC SD ivtv recordings in a
way that can be used by the 0.22 internal player via .srt files.  But
I haven't had a chance to try this yet.  (I did some research on this
quite a while ago and I've seen chatter about it on the list, but I
haven't recently refreshed my memory, so if this sounds braindamaged,
please let me know. :)  I also don't remember any more if ccextractor
embeds timestamps in its output that would be usable if applied
against a stream (presumably, in my case, H.264) that has been edited
to remove commercials---basically, are both streams using absolute
timebases that won't drift against each other, so if some of the video
is missing, the corresponding captions are dropped?  It'd sure be nice
to have the option of doing cuts without completely desynchronizing
any CC data after that; at least with ivtv CC data and 350 display,
I can do the crudest of cutting and know that, even if I kill a line
of captions at the splice, everything after that is guaranteed good
(because the CC data is actually embedded in the video stream and not
in a parallel file somewhere else).  I -think- this was discussed on
the list a while ago but I can't find it; any suggestions?

[Err, uhm, I'm assuming that CC data can't be embedded in an H.264
stream and/or that even if it can, tools to do so from ivtv streams
don't exist, and/or that Myth wouldn't do anything with such embedded
data and thus .srt's or the like are necessary.  True?]

    > > Similarly, I believe you also lose wss support (e.g., the mode that
    > > allows TV's like the Sony WEGA to go to a resolution-preserving 16:9
    > > format by packing all of its lines into a smaller vertical slice of
    > > the screen), although this was uncommon to see in broadcast sources.

    > Though I don't know the state of WSS support in ivtv-recordings done by 
    > Myth and played back through the PVR-350's decoder, I can tell you that 
    > the zoom/fill modes in Myth work great.  And 0.22 has automatic 
    > letterbox detection support, too (as long as you're not using VDPAU and 
    > possibly some other hardware renderers).

That's not -quite- the same thing.  On SD sets that understand wss,
you can actually get "525" (480, whatever) lines of true resolution
crammed into the middle 2/3rds of the screen, because the set actually
changes the vertical pitch of the lines---it's not even moving the
electron beam into the top & bottom black areas, effectively.  Without
wss, the best you can do is have whatever's generating the video
simply put black bars on the top & bottom to get the right aspect
ratio, but those lines are being scanned by the TV and count against
your vertical resolution---so if you're playing a widescreen DVD on an
SD set and don't have wss, your effective resolution is, what, 300
lines?

I know you're pure-HD and so this isn't an issue for you, but people
who have actual SD sets and don't want to obsolete the investment (but
still want the vertical resolution you can get from a DVD) appreciate
wss mode.

Granted, this isn't much of an issue with Myth, because I don't think
it matters for broadcast---broadcasters just broadcast actual black
bars that get stored in the stream and scanned by the TV, and the
vertical resolution is correspondingly reduced.

    > > (It -was- common to see in DVD sources

    > And Myth will actually use the aspect ratio specified by the digital 
    > source (DVD or digital TV).

Right... but in SD, again, with a vertical resolution sacrifice
compared to handling wss all the way through the path.  (But I never
play DVDs through Myth, so this isn't -my- issue...)

    > Still, though, since no one who actually uses the PVR-350 decoder has 
    > stepped up to maintain the code, and since the functionality being lost 
    > isn't really that important, anymore, and other use cases can achieve 
    > similar functionality, the amount of code cleanup we get by removing it 
    > is seriously beneficial.  See http://svn.mythtv.org/trac/changeset/22845 
    > and note that the 4 files that were deleted (those with red boxes by the 
    > filenames) are not shown in the modifications there, and account for 
    > another 2250 lines of source code removed.

Yeah, I'm not arguing per se that removing support is a bad move---if
the code is orphaned, it's orphaned, and my desire to compress the
video I save means I'll probably go to H.264 anyway, and I'm not sure
if my frontend (currently an AMD Athlon 2800+, although I could also
use a dual-core 5400+ if I really had to) can decompress even SD H.264
in realtime and throw it at the 350's framebuffer, so I'd already been
resigned to sacrificing the 350.  I'm just pointing out that there
-are- some corner cases that non-SD users or non-350 users or non-CC
users typically don't think about when they talk about other video
cards---and using native CC and wss modes on TV's is, I believe,
entirely unique to the 350.

[My understanding was that the 350 currently worked at least, hence
didn't need maintenance per se; if it was actually -broken- in trunk
and nobody wanted to fix it, well...]

Sorry this has gotten so long.  Oy.