Opened 9 years ago

Closed 2 years ago

Last modified 8 months ago

#8096 closed defect (fixed)

Music Only channels/still picture flag cause jump program error

Reported by: mia1dolfan@… Owned by: Peter Bennett
Priority: minor Milestone: unknown
Component: MythTV - Video Playback Version: 0.22-fixes
Severity: medium Keywords: hdhomerun tuning jump
Cc: Ticket locked: no

Description

"jump program error" on frontend when tuning in any program on QAM-256 channel 120. This happens to be the "music channel" on Comcast in my area. The myth front end displays the OSD, shows signal locked, hangs on a blank screen for a while, and then dies with the "jump program" error message. If you enter live TV again it goes to the last channel tuned, and the whole process repeats. I have to enter mythtv-setup and change the tuner to start on some other virtual channel number that does not map to channel 120. This is the only channel that consistently fails to tune.

I installed a fresh copy of myth on another separate system and observed the same issue. I took a packet capture and I could see the communication with the hdhomerun device, it sets the channel, sets the target, the device starts sending a UDP stream, and Myth sends filter commands to tune the program.... I think it's not tuning in the right program. I tried to change the backend to quick tune the channel, so it used the channel number instead of the PID filter, but ran into bug #7971. I can properly view the programs on the channel using VLC. In mysql I looked at the channels tables, the freqid and serviceid columns look fine to me.

I have attached a "mythbackend -v all" log along with a clean packet capture (starting with a SYN and ending with SYN ACK - ACK). I installed through Ubuntu 9.10, packages version 0.22.0+fixes22594-0ubuntu1.

Thank you.

Attachments (2)

debugging.tgz (53.1 KB) - added by mia1dolfan@… 9 years ago.
Debugging info for ticket #8096
good.mpg (1.7 MB) - added by anonymous 5 years ago.
Successful music choice recording

Download all attachments as: .zip

Change History (24)

Changed 9 years ago by mia1dolfan@…

Attachment: debugging.tgz added

Debugging info for ticket #8096

comment:1 Changed 9 years ago by anonymous

Correction: On the original problem description I stated "on frontend when tuning in any program on QAM-256 channel 120". It is only the music programs. There are two "non-music" programs on channel 120 and they function correctly.

comment:2 Changed 9 years ago by anonymous

More information

Upon further googling, the problems have been reported regarding the "Music Choice" channels for years. There is a mention on ticket #361 regarding the issue "The video stream contains the still-picture flag (e.g. it's a Music Choice(R) channel); Myth currently does not play these streams correctly." - dating back four years ago. The issue also has been reported affecting various cable providers, always the "Music Choice" channel.

comment:3 Changed 9 years ago by robertm

Summary: Unable to tune programs on channel using hdhomerun sourceMusic Only channels/still picture flag cause jump program error

Refs #361.

comment:4 Changed 9 years ago by robertm

Component: MythTV - GeneralMythTV - Video Playback
Owner: changed from Isaac Richards to Janne Grunau

comment:5 Changed 8 years ago by robertm

Resolution: fixed
Status: newclosed

Should be fixed in current trunk, otherwise reopen ticket with sample video please.

comment:6 Changed 5 years ago by iralleyne@…

Resolution: fixed
Status: closednew

This issue has not been fixed. I am still experiencing this issue with the music choice channel using comcast and the hd homerun tuner.

Changed 5 years ago by anonymous

Attachment: good.mpg added

Successful music choice recording

comment:7 Changed 5 years ago by mikep@…

Maybe this will be helpful. When I record one of the Music Choice channels, Myth makes a small file, like 376 bytes. That file sits there for like 30 seconds or a minute, at least. Then, after that period, it starts getting larger like a normal recording.

If I play a recording that didn't go long enough to start getting larger, I get an error: "Could not read first 2048 bytes". If I wait until the recording is getting larger before stopping it, Myth will play the file successfully.

I think there is something in the stream that MythTV is looking for that isn't sent down within a certain number of seconds, so Myth will time out in live tv mode. In recording mode, it basically waits for the data it needs to see before starting to put data into the recording.

I will try to upload both one of the 376 byte files and a file after the recording is playable. For what it's worth, VLC will play the stream starting immediately, without waiting for whatever it is that Myth is waiting for before putting good data into the recording file.

Edit: I uploaded a successful recording, which Myth still seems to have some trouble playing. It sounds like it skips a lot, although there is at least some sound and a video background. It seems like there is only sound right around when the image changes, then it skips to when the next video update happens?

I was unable to upload a bad file, as Myth deletes it if I stop the recording within 30 seconds or a minute. If I try to play the recording within 10 or 20 seconds of starting it (but while it is still recording), I get a message that the recording isn't ready yet. I am able to start playing recordings of normal video channels within a second or two of starting the recording, so this seems to be a result of myth not having recorded any data yet.

comment:8 Changed 4 years ago by chris@…

This is still an issue with Mythtv v27.4 in LiveTV on an HD Homerun Prime3 CableCard? tuner. "Could not read the first 2048 bytes"

comment:9 Changed 2 years ago by Peter Bennett

Owner: changed from Janne Grunau to Peter Bennett
Status: newassigned

comment:10 Changed 2 years ago by Peter Bennett

Music choice channels have video which is ostensibly 30 frames per second, according to ffmpeg and mediainfo, but actually contains 3 frames at 30fps with 6 second gaps in between. This plays havoc with many assumptions made in MythTV Player and causes multiple problems in playback. The backend also loses the first couple of minutes while setting up a recording before it starts writing to the file. Also tuning these channels takes longer than normal channels.

I plan to get this working for the benefit of those, like me, who have given up all cable boxes in favor of a cable card from the cable company. Music choice is not really something to be recorded as it has no scheduled programs, but people may want to watch it using "Live TV".

Last edited 2 years ago by Peter Bennett (previous) (diff)

comment:11 Changed 2 years ago by J.Pilk@…

Clearly this isn't aimed at DVB-T radio, which 'ain't broke.' I hope that any fix won't affect it!

comment:12 Changed 2 years ago by Peter Bennett <pbennett@…>

In 28fe92a74d0cd903ad0c154fa3cd9a74019d1ca8/mythtv:

Fix Seg Fault due to OSD painter being deleted while image loader threads are still using it.

Image loading for the OSD uses ImageLoadThread? and continues
loading while the video is playing. If the video playback
encounters an "InputChanged?" situation it deletes the OSD and its
painter and re-creates it. If the Image load is still running and
using the painter, it gets a Seg Fault calling a virtual function
using a corrupted object

Exception Details:
1 in MythPainter::GetFormatImage? at mythpainter.cpp:540

Fix: Keep the old osd painter valid until either it changes again
or the OSD is deleted.

Refs #8096

comment:13 Changed 2 years ago by Peter Bennett <pbennett@…>

In 5b011ca7e7706efe15e21d6435be72429b50194f/mythtv:

Fix Seg fault in OSD due to notification being displayed using a painter that is no longer valid.

The OSD goes through all notifications in the notification center
and displays them. Each notification screen has a painter stored in
it. The painter will be invalid if the notification started being
displayed before the playback started or before an inputchanged
notification caused it to be deleted

Exception Details:
1 in MythUIType::HandleMovementPulse? at mythuitype.cpp:374
...
3 in OSD::DrawDirect? at osd.cpp:702

Fix: Always update the painter to the latest one before painting
notifications.

Refs #8096

comment:14 Changed 2 years ago by Peter Bennett <pbennett@…>

In 2d24c4acbe858cc6eaa3dcb981d46b37b295f892/mythtv:

Setup change to allow CETON users to set tuning timeout.

The 3 second default tuning timeout is not enough. Many recordings
are marked as failed even though they are successful. Also allow
users who wish to watch music choice to set the timeout
sufficient for those slow to tune channels.

Refs #8096

comment:15 Changed 2 years ago by Peter Bennett <pbennett@…>

Resolution: fixed
Status: assignedclosed

In 2a1ccc06a58af472bd3044bff81dc93c49c83885/mythtv:

Frontend and backend changes to support music choice.

Music choice channels from Comcast are mpeg2 video which internally
identifies as 30 fps but actually sends frames with intervals
5.939, 0.033, 0.033, repeat, ... This amounts to 3 frames at 30fps
every 6 seconds. These frames are never identified as key frames.
Tuning takes up to 8 seconds for these channels on CETON. This
stream breaks several MythTV timeouts, and causes havoc with the
audio-video synchronization routines. It causes the recorder to
report a great many 6 second gaps in the video and mark it as failed.

Fix: Increase timeouts. Increase audio buffer size to allow up to
8 seconds to be buffered. In the backend allow recordings to start with a
non-key frame and set a high threshold for gaps in specific cases.
Change handling of video buffer waits so that audio data is not lost by
audio resets in music choice programs.

Fixes #8096

comment:16 Changed 2 years ago by Peter Bennett <pbennett@…>

In c2c1465f474158492f7f7f77f7bf37f64afeb40f/mythtv:

Fix Seg Fault due to OSD painter being deleted while image loader threads are still using it.

Image loading for the OSD uses ImageLoadThread? and continues
loading while the video is playing. If the video playback
encounters an "InputChanged?" situation it deletes the OSD and its
painter and re-creates it. If the Image load is still running and
using the painter, it gets a Seg Fault calling a virtual function
using a corrupted object

Exception Details:
1 in MythPainter::GetFormatImage? at mythpainter.cpp:540

Fix: Keep the old osd painter valid until either it changes again
or the OSD is deleted.

Refs #8096

(cherry picked from commit 28fe92a74d0cd903ad0c154fa3cd9a74019d1ca8)

comment:17 Changed 2 years ago by Peter Bennett <pbennett@…>

In ed7df02899f3a8dbfe67566797168c2f9d9446ce/mythtv:

Fix Seg fault in OSD due to notification being displayed using a painter that is no longer valid.

The OSD goes through all notifications in the notification center
and displays them. Each notification screen has a painter stored in
it. The painter will be invalid if the notification started being
displayed before the playback started or before an inputchanged
notification caused it to be deleted

Exception Details:
1 in MythUIType::HandleMovementPulse? at mythuitype.cpp:374
...
3 in OSD::DrawDirect? at osd.cpp:702

Fix: Always update the painter to the latest one before painting
notifications.

Refs #8096

(cherry picked from commit 5b011ca7e7706efe15e21d6435be72429b50194f)

comment:18 Changed 2 years ago by Peter Bennett <pbennett@…>

In 89e17dc0d65ca58cb3bcda4765c80986a00e4c71/mythtv:

Setup change to allow CETON users to set tuning timeout.

The 3 second default tuning timeout is not enough. Many recordings
are marked as failed even though they are successful. Also allow
users who wish to watch music choice to set the timeout
sufficient for those slow to tune channels.

Refs #8096

(cherry picked from commit 2d24c4acbe858cc6eaa3dcb981d46b37b295f892)

comment:19 Changed 2 years ago by Peter Bennett <pbennett@…>

In 7f8f1688e882cd0587097fe4867e20d8fa122cce/mythtv:

Frontend and backend changes to support music choice.

Music choice channels from Comcast are mpeg2 video which internally
identifies as 30 fps but actually sends frames with intervals
5.939, 0.033, 0.033, repeat, ... This amounts to 3 frames at 30fps
every 6 seconds. These frames are never identified as key frames.
Tuning takes up to 8 seconds for these channels on CETON. This
stream breaks several MythTV timeouts, and causes havoc with the
audio-video synchronization routines. It causes the recorder to
report a great many 6 second gaps in the video and mark it as failed.

Fix: Increase timeouts. Increase audio buffer size to allow up to
8 seconds to be buffered. In the backend allow recordings to start with a
non-key frame and set a high threshold for gaps in specific cases.
Change handling of video buffer waits so that audio data is not lost by
audio resets in music choice programs.

Fixes #8096

(cherry picked from commit 2a1ccc06a58af472bd3044bff81dc93c49c83885)

comment:20 in reply to:  12 ; Changed 2 years ago by JYA

Replying to Peter Bennett <pbennett@…>:

In 28fe92a74d0cd903ad0c154fa3cd9a74019d1ca8/mythtv:

Fix Seg Fault due to OSD painter being deleted while image loader threads are still using it.

Image loading for the OSD uses ImageLoadThread? and continues
loading while the video is playing. If the video playback
encounters an "InputChanged?" situation it deletes the OSD and its
painter and re-creates it. If the Image load is still running and
using the painter, it gets a Seg Fault calling a virtual function
using a corrupted object

Exception Details:
1 in MythPainter::GetFormatImage? at mythpainter.cpp:540

Fix: Keep the old osd painter valid until either it changes again
or the OSD is deleted.

Refs #8096

I don't see how the fix does work around the problem described.

The only way to fix this is to use a reference counted object, and here it's not thread safe either.

comment:21 in reply to:  20 Changed 2 years ago by Peter Bennett

Replying to jyavenard:

I don't see how the fix does work around the problem described.

The only way to fix this is to use a reference counted object, and here it's not thread safe either.

I agree, a reference counted object would be best, but changing Painter to be reference counted would be a major amount of work.

What the work around does is delay deleting the painter until the next reset of the OSD. The seg fault was happening if there was a resolution change right after the start of playing, while the initial OSD was still loading the images in separate threads. With my change, the painter is not deleted until the next resolution change or the eventual deletion of the OSD. Hopefully by that time the image load threads would be finished. If there were two resolution changes in quick succession, we could still get a seg fault. Hopefully this would not happen.

comment:22 Changed 8 months ago by Peter Bennett

Owner: changed from Peter Bennett to Peter Bennett
Note: See TracTickets for help on using tickets.