Opened 11 years ago

Closed 11 years ago

#4515 closed patch (fixed)

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

Reported by: markus.ingalsuo@… Owned by: danielk
Priority: minor Milestone: 0.21
Component: mythtv Version: head
Severity: medium Keywords:
Cc: Ticket locked: no

Description

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

Attachments (7)

mythbackend-stuck.log (76.6 KB) - added by markus.ingalsuo@… 11 years ago.
stuck on bad channel, mythbackend -v dvbcam,siparser,channel,record
write_dsmcc_packets_where_no_AV_packets.diff (5.7 KB) - added by bradley.kite@… 11 years ago.
write non-A/V data to recorded file
dsmcc.patch (4.4 KB) - added by dm@… 11 years ago.
Backend and frontend patch
4515-bradley-v1.patch (5.6 KB) - added by danielk 11 years ago.
Reviewed patch
write_dsmcc_packets_where_no_AV_packets-3.diff (10.5 KB) - added by bradley.kite@… 11 years ago.
Revised patch. Only creates initial DSMCC key-frame where no A/V PIDS exist in the PMT
4515-bradley-v2.patch (6.4 KB) - added by danielk 11 years ago.
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.
dsmcc_timeout.patch (1.2 KB) - added by dm@… 11 years ago.

Download all attachments as: .zip

Change History (33)

comment:1 Changed 11 years ago by Janne Grunau

Milestone: unknown0.21
Status: newinfoneeded_new
Version: unknownhead

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

comment:2 Changed 11 years ago by 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.

Changed 11 years ago by markus.ingalsuo@…

Attachment: mythbackend-stuck.log added

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

comment:3 Changed 11 years ago by markus.ingalsuo@…

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

comment:4 Changed 11 years ago by danielk

Milestone: 0.21unknown
Priority: majorminor
Severity: highmedium
Status: infoneeded_newnew

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.

comment:5 Changed 11 years ago by 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

comment:6 Changed 11 years ago by 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.

Changed 11 years ago by bradley.kite@…

write non-A/V data to recorded file

comment:7 Changed 11 years ago by 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.

Changed 11 years ago by dm@…

Attachment: dsmcc.patch added

Backend and frontend patch

comment:8 Changed 11 years ago by 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.

comment:9 Changed 11 years ago by danielk

Milestone: unknown0.21
Owner: changed from Isaac Richards to danielk
Status: newassigned

comment:10 Changed 11 years ago by danielk

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

comment:11 Changed 11 years ago by 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.

comment:12 Changed 11 years ago by 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.

comment:13 Changed 11 years ago by 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

Changed 11 years ago by danielk

Attachment: 4515-bradley-v1.patch added

Reviewed patch

comment:14 Changed 11 years ago by 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?

comment:15 Changed 11 years ago by 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.

comment:16 Changed 11 years ago by 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...

Changed 11 years ago by bradley.kite@…

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

comment:17 Changed 11 years ago by 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.

comment:18 Changed 11 years ago by 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.

Changed 11 years ago by danielk

Attachment: 4515-bradley-v2.patch added

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.

comment:19 Changed 11 years ago by 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.

comment:20 Changed 11 years ago by danielk

Type: defectpatch

comment:21 Changed 11 years ago by 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.

Changed 11 years ago by dm@…

Attachment: dsmcc_timeout.patch added

comment:22 Changed 11 years ago by 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.

comment:23 Changed 11 years ago by 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.

comment:24 Changed 11 years ago by danielk

Resolution: fixed
Status: assignedclosed

(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.

comment:25 Changed 11 years ago by markus.ingalsuo@…

Resolution: fixed
Status: closednew

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.

comment:26 Changed 11 years ago by danielk

Resolution: fixed
Status: newclosed

ticket reopened for a completely unrelated problem. closing.

Note: See TracTickets for help on using tickets.