Music Only channels/still picture flag cause jump program error

[mia1dolfan@…]

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

[mia1dolfan@…]

Debugging info for ticket #8096

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

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

[robertm]

Refs #361.

[robertm]

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

[iralleyne@…]

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

[anonymous]

Successful music choice recording

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

[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"

[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".

[J.Pilk@…]

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

[Peter Bennett <pbennett@…>]

In 28fe92a74d0cd903ad0c154fa3cd9a74019d1ca8/mythtv:

Error: Processor CommitTicketReference failed

GIT backend not available

[Peter Bennett <pbennett@…>]

In 5b011ca7e7706efe15e21d6435be72429b50194f/mythtv:

Error: Processor CommitTicketReference failed

GIT backend not available

[Peter Bennett <pbennett@…>]

In 2d24c4acbe858cc6eaa3dcb981d46b37b295f892/mythtv:

Error: Processor CommitTicketReference failed

GIT backend not available

[Peter Bennett <pbennett@…>]

In 2a1ccc06a58af472bd3044bff81dc93c49c83885/mythtv:

Error: Processor CommitTicketReference failed

GIT backend not available

[Peter Bennett <pbennett@…>]

In c2c1465f474158492f7f7f77f7bf37f64afeb40f/mythtv:

Error: Processor CommitTicketReference failed

GIT backend not available

[Peter Bennett <pbennett@…>]

In ed7df02899f3a8dbfe67566797168c2f9d9446ce/mythtv:

Error: Processor CommitTicketReference failed

GIT backend not available

[Peter Bennett <pbennett@…>]

In 89e17dc0d65ca58cb3bcda4765c80986a00e4c71/mythtv:

Error: Processor CommitTicketReference failed

GIT backend not available

[Peter Bennett <pbennett@…>]

In 7f8f1688e882cd0587097fe4867e20d8fa122cce/mythtv:

Error: Processor CommitTicketReference failed

GIT backend not available

[JYA]

Replying to Peter Bennett <pbennett@…>:

In 28fe92a74d0cd903ad0c154fa3cd9a74019d1ca8/mythtv:

Error: Processor CommitTicketReference failed

GIT backend not available

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.

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