On Mon, 2005-10-03 at 12:17 +0100, Stuart Auchterlonie wrote: > 2) While watching liveTV EIT is no longer collected. I'll re-enable this. No Biggie.
> 1) If the EIT crawler picks a channel that is off air (& so only a > data channel) the crawler gets stuck and doesn't go any further. > Daniel, part of what happens in #1 is that when the backend > attempts to reconstruct a PMT for the frontend, it can't find > any video and so gives up building a new PMT. i.c. My hope was that someone would want to improve the scanner right away and change it to tune to transports instead of channels, but this PMT problem is easy enough to fix, I'll commit something soon. > I think this is a root cause of a number of other problems that > some people have been seeing. What I would like to do is as follows > 1) Contruct a PMT under all circumstances and pass it through > 2) Add handling to cope with PMT that may be only data or audio. I'll just turn off the video requirement for PMT's during EIT Scan. this is only a couple of lines of code in mpegstreamdata. > The interesting part about this is we can use #2 to implement > preliminary support for audio only (ie. radio) channels and also > data only channels. I can enable audio only channels in TVRec by just changing a couple constants, the reason they are disabled is because VideoOutput requires video to work. If someone fixes that I'll enable audio in TVRec. > What I would need to do this is a way of insterting a static > mpeg I frame into the stream to generate a video stream > even though it doesn't change. One could be an image of a radio, > one an image representing data. Just patch AVFormatDecoder and the VideoOutput to cope with audio only streams... it shouldn't be that hard. I don't have any audio channels with listings so I don't have any motivation to implement this, but it wouldn't be too difficult. -- Daniel
_______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
