Frontend unknown error, exiting decoder, livetv stuck on bad channel

[markus.ingalsuo@…]

When selecting a channel on DVB-C that tunes (LMS Lock) but has nonexistent content or something that mythtv does not understand results in an "Error displaying video.". When trying to watch tv again, the same channel is tuned and the same error message is displayed and mythtv is stuck on the bad channel.

A quick fix is to record something from another mux and simultaneously watching livetv. That will get mythtv unstuck.

This happens with mythtv svn r15532

[Janne Grunau]

please attach a mythbackend log with -v dvbcam,siparser,channel,record

[bradley.kite@…]

I believe this occurs when a channel stops broadcasting - like when cbeebies stops at 7pm each night and the MHEG "this channel has stopped" screen should pop up. Thats what used to happen any way.

I previously attached logs to #3326 for this - although that was some time ago.

​http://svn.mythtv.org/trac/attachment/ticket/3326/backend.log.gz

If required, I'll get some fresh logs from trunk (the log above was before the merge but I'm sure the problem is the same).

Interestingly, if I'm quick enough with the remote I can go into LiveTV and change to a different virtual tuner before the error is displayed. However I still cannot use the tuner stuck on the "bad" channel until I update the start-channel in MySQL.

[markus.ingalsuo@…]

stuck on bad channel, mythbackend -v dvbcam,siparser,channel,record

[markus.ingalsuo@…]

Log attached from: mythbackend -v dvbcam,siparser,channel,record

[danielk]

We currently don't handle the case where we're still recording when a broadcaster stops broadcasting. It's a known issue that we're lived with since the dawn of MythTV, but someday it should be fixed.

[bradley.kite@…]

Hi Daniel,

In the UK, when a channel stops broadcasting, they start broadcasting an MHEG screen which says something like "this station will return at <time>" or similar - like a place-holder screen.

Up until the multirec merge MythTV would do the right thing and display this MHEG screen (much like it does for DVB Radio), however since the multirec merge (which otherwise works very well and is a "killer feature" of Myth now, thanks very much to every one involved) it causes the "unknown error" and the tuner gets stuck on this channel as described, so I dont think this is quite the same as the problem that's existed since the dawn of MythTV (like if a station stops broadcasting completeley, no MHEG or any thing).

I'll see if I can get a bit more debug info for this in the next few days. Could you offer me any pointers/tips/ares of code that I should focus on?

Many thanks

[dm@…]

I tried out the latest SVN and also noticed that if I tune to a channel that is not currently broadcasting it does not display the MHEG "off air" banner. I've done a little bit of investigation and there are several problems. In the backend it seems that data is only written to the output file when a keyframe is seen. However when there is no audio or video there is no keyframe so nothing gets written. Bypassing that test did result in data getting written to the file. On some channels that resulted in the frontend seeing the DSMCC stream and beginning to build the carousel. I don't understand why that only occurred on some channels and not all. The frontend, though, seemed to be stuck generating Prebuffering messages and I suspect that was again because there was no video or audio. I did try bypassing the prebuffering here and actually succeeded in getting the banner displayed so potentially this can work.

I hope this is helpful. I don't really understand the code well enough to propose a patch but I'm happy to help with testing. Although I was responsible for adding the dummy video for radio and MHEG I always felt it was a hack so I'm pleased to see that radio at least works without it.

David.

[bradley.kite@…]

write non-A/V data to recorded file

[bradley.kite@…]

I have attached a patch (write_dsmcc_packets_where_no_AV_packets.diff) which allows DSMCC TS packets to be recorded to disk by the back-end (Many thanks to David Matthews "dm at prolingua D co D uk" who has been helping me with this).

I'm not sure if its valid to create "fake" key-frames (as is done with audio TS packets) or not, so the patch just creates 1 key-frame the first time a non-audio/video packet is seen, and just writes all other non-audio/video packets to disk. I cannot see a reason to FF/Rewind through DSMCC data (but maybe there is a valid reason??). If a recoding starts early (before a broadcaster starts the A/V streams) then the first GOP will create a new key-frame so the user can skip passed the entire DSMCC stream to start watching their recoding.

This patch does not address any issues with the front-end tho, which still has problems.

[dm@…]

Backend and frontend patch

[dm@…]

I've also been working on patches to get the text pages and off-air logos to work. The attached patches work at least on the BBC channels. There is still a problem with some of the other channels and I suspect that it is because the low data rate causes time-outs.

I've used FindAudioKeyframes? to generate keyframes in the same way as for radio. I have found it useful in the past to be able to fast-forward through the off-air logo when recording the first programme broadcast as a channel comes on air. I haven't tested how this works without the dummy video stream so I don't know if there actually is a timebase when there is no audio or video.

David.

[danielk]

(In [15754]) Refs #4515. Applies portion of David's MHEG patch for off-air screens.

[danielk]

David, I applied everything but the portion of the patch that would break other recorders. I don't understand what the ProcessTSPacket() change was about anyway.

Bradley, is your patch still required with David's patch applied? After a cursory look it doesn't look harmful, but I don't want to apply it if it isn't needed.

[bradley.kite@…]

Daniel,

My patch is an alternative way of doing the same thing as David's patch, but has 2 main differences:

1) It doesnt break other decorders. 2) It only inserts 1 key frame at the begining of the DSMCC stream, (not like the audio-processing which periodically creates key-frames within the audio-only stream itself). You can still FF/RR but it will jump direct to the begining/end of the DSMCC stream (I dont see the need for being able to seek within the DSMCC stream itself).

Hope this helps.

Regards -- Brad.

[dm@…]

Daniel, Although FindAudioKeyframes? is passed the packet as argument it does not actually make any use of it. It simply notes that a packet has been received and generates a keyframe entry if the video hasn't. It seemed to me that it was safe to use it for all non-video packets which is what my patch does.

I obviously don't want to break anything else so if you feel happier with Bradley's patch please go with that in place of my backend changes. It may be true that there really is no advantage in being able to fast forward and that a simple skip to the real video/audio is sufficient.

Thanks for committing the frontend changes.

David

[danielk]

Reviewed patch

[danielk]

Bradley can you change your patch so that it only generates the fake keyframe if we don't see any video or audio streams?

[bradley.kite@…]

Hi Daniel,

I'm working on this at the moment - I'm guessing I need to look up in the PMT to make sure there are no audio/video PIDS?

Also, would it be acceptable for the mpegstreamhandler to call its callbacks with pointers to each packet instead of making copies? If so then I'll submit a seperate patch for this (and each of the dtv recorders) as the TS packets seem to get copied around alot.

[danielk]

That would be idea. If that is too complicated you could just set a timer and only create this keyframe if you don't see any video and audio data within 1-2 seconds after seeing any data.

For any copying changes make those a separate patch. I would really like to make everything in /libs/libmythtv/mpeg be able to run as a zero copy class against the raw read only DMA buffer provided by the OS. Which means all pointers and references must be const, and copies must be made of anything you modify. Also, any data not used in the callback itself must be copied, since it will disappear...

[bradley.kite@…]

Revised patch. Only creates initial DSMCC key-frame where no A/V PIDS exist in the PMT

[bradley.kite@…]

Hi Daniel

I have just uploaded write_dsmcc_packets_where_no_AV_packets-3.diff which adds some methods to the ProgramMapTable? class to keep track of the existance of audio/video pids in the PMT. I didnt use FindPIDS() becuase it would be called such a lot so think this is maybe more efficient. The DVBRecorder class then uses this to decide when to create the Key frame in the DSMCC stream.

Hopefully this is OK.

[bradley.kite@…]

Daniel,

I have just submitted #4622 which reduces a lot of the copying of tspackets, however it conflicts with the patch in this ticket. If you apply #4622 then I will update the patch in this ticket.

[danielk]

Reviewed version of Bradley's second patch. This gets rid of some unneeded changes in mpegrec & also makes sure we check for a/v streams using the current system info standard.

[danielk]

Bradley, can you check if the latest patch works? It should be a bit more efficient than your last patch, but still only add the fake keyframe when needed.

[bradley.kite@…]

Hi Daniel,

I've tested your modified patch and it seems to work fine - the back-end records as it should.

I've still got to look into why the FE doesnt stream properly tho - it too keeps looking for key-frames waiting for the buffer to fill. I'll see if I can do further investigation in the next few days.

[dm@…]

I've been looking at various issues to do with the frontend. The attached patch deals with the situation where av_find_stream_info is looking for timing information on the streams. Since DSMCC packets are not part of a PES stream there is no timing information available.

There are other issues: mpegts.c sets AVFMTCTX_NOHEADER for the transport stream presumably because information about the stream is held in the PMT. That causes av_find_stream_info not to return until MAX_FRAMES packets have been returned, or there is both video and audio. That can cause the ring buffer to time out on some channels (e.g. TeleG) with a very low rate of DSMCC packets. One possibility would be to clear AVFMTCTX_NOHEADER once a PMT is seen. The original ffmpeg version of av_find_stream_info actually waits for read_size >= MAX_READ_SIZE only and it looks as though this condition has been weakened in the Myth version to speed up channel changing in live TV.

RingBuffer?.cpp sets end-of-file and produces a "Timing out wait due to impending livetv switch." message if the user changes channel. If this happens before sufficient packets have arrived for NuppelVideoPlayer::OpenFile? to return successfully this appears as a hard error and the log shows something like:

2008-02-18 13:05:12.067 RingBuf?(/video/1008_20080218130508.mpg): Timing out wait due to impending livetv switch.
2008-02-18 13:05:12.067 NVP::OpenFile?(): Error, couldn't read file: /video/1008_20080218130508.mpg
2008-02-18 13:05:12.067 NVP: DoPlay?: rate: 25 speed: 1 skip: 1 => new interval 40000
2008-02-18 13:05:12.067 Set video sync frame interval to 40000
2008-02-18 13:05:12.067 NVP, Error: JumpToProgram? failed.

This can make it impossible to change to a different channel if one is tuned to a channel that is producing DSMCC packets slowly.

I've tried out Daniel's revised backend patch and it seems to work fine.

David.

[danielk]

(In [16135]) Refs #4515. Fixes regression in handling off-air MHEG channels from the multirec merge.

This uses a patch originally written by Bradley Kite and modified by me to be less intrusive. This adds creates a fake keyframe entry for an MPEG stream with no audio or video streams so that the frontend can read the data and tell you that the channel is off-air instead of timing out waiting for data.

[danielk]

(In [16136]) Fixes #4515. Fixes ffmpeg timeout issues with Off-air MHEG stations.

Because of changes we've made to ffmpeg to make channel changing faster our ffmpeg can cause an undesired timeout while looking for A/V streams in off-air channels, this patch from David Matthews checks for CODEC_ID_DSMCC_B data and reduces the parsing ffmpeg requirements to avoid ringbuffer timeouts on off-air MHEG channels.

[markus.ingalsuo@…]

Problems still exist. My backend gets stuck on encrypted channels (LMSC lock, and I have no working subscription, hw cam though) and does not allow me to change channel. Frontend then exits livetv and tells me that there was an error displaying video. Enter loop, backend stuck.

[danielk]

ticket reopened for a completely unrelated problem. closing.