Opened 14 years ago

Closed 10 years ago

#799 closed defect (fixed)

DTV recordings sometimes show doubled recording length

Reported by: danielk Owned by: Janne Grunau
Priority: major Milestone: 0.22
Component: mythtv Version: head
Severity: high Keywords:
Cc: Ticket locked: yes

Description

I thought I had seen this before, but it that it had been fixed. Most 60 fps recordings do not have this problem anymore. But I have a recording from last night that exhibits the problem. This also throws off skipping, bookmark, etc.

Change History (44)

comment:1 Changed 14 years ago by gdragon

I also see this problem. It usually occurs when playing back a pseduo-live recording, and the recording ends.

comment:2 Changed 14 years ago by anonymous

I have seen this problem for a long time. Always on HD content. The time shows normal if you are watching it as it is being recorded, but as soon as the recording stops the time shows double. If you exit and play the recording again it shows normal.

comment:3 Changed 14 years ago by danielk

It appears this is neither a ffmpeg nor MythTV problem. At least in the recording I have, the MPEG sequence header is reporting framerate of 29.97 fps, when it is in fact a 59.94 fps video. This is an upconverted standard definition program, so my guess is they just forgot to update the sequence header when they doubled the framerate. :/

It may be possible to autodetect and correct for this efficiently. But I dunno yet.

comment:4 Changed 14 years ago by gdragon

based on your decription, I don't think that the problem you're seeing is the same as mine & anon's. I've never noticed the issue on an upconverted program, atleast that I can remember, I always see it on true HD programming (720p most likely since I watch fox & abc most). There are very things that I watch that are upconverted.

If you anything from recordings, I can prob recreate this fairly frequently.

Nothing bad seems to occur from it, skip, etc seems to work.. so I haven't really bothered to report it. It's more of a visial annoyance.

comment:5 Changed 14 years ago by danielk

Milestone: 0.190.20
Type: taskdefect

Glen I think you may have a different problem.

The problem I'm seeing turns out to be due to the simplistic way we scan for pictures in the DTVRecorder. It picks up an extra frame whenever the sequence 0x0 0x0 0x1 0x0 occurs in the stream; even if the syntax is not right for a picture code to occur there. This same type of scan appears to always work with the ivtv recorder, but it appears to fail sometimes with the wild and wolly streams we get with DTV capture.

Long story short, this isn't something that I can fix before 0.19, this requires properly parsing the stream and not just scanning for magic codes in the stream.

Do I'm pushing this off to 0.20..

comment:6 Changed 14 years ago by smalenfant@…

After the recording of American Idol on Fox (720p) started last night, I started looking at it. The show was 2 hours, I joined about 45 minutes in it. When the recording ended, the length of the show suddenly jumped to exactly 4 hours. I'm not sure this is the same issue as everybody been talking about, but that's running .19 (had the same problem on 0.18).

comment:7 Changed 14 years ago by danielk

Summary: 60fps DTV recordings sometimes show doubled recording lengthDTV recordings sometimes show doubled recording length

Removed "60fps" from the description, this happens 29.97fps recordings as well.

comment:8 Changed 13 years ago by ylee@…

Hi. My #1941 was closed and marked as a duplicate of this bug. However, as I noted in that ticket, I've never seen OSD times doubled. In any case, here's what I wrote there:


*All* HD recordings from the 1080i premium-movie channels I subscribe to (HBO HD, Showtime HD, CineMAX HD, Starz! HD) have incorrect recording lengths. A two-hour recording will typically show a total recording time of about one hour and 40 minutes, although the recording is complete with no missing chunks (jumping to the last minute of the movie's OSD length does properly takes me to the last minute of the actual recording). For example, a snippet of _The Paper_ recorded from Showtime HD that, according to my watch, took 30 seconds to play, will according to the OSD have taken about 26 seconds.

This issue does *not* occur with recordings from any other source, whether 1080i/720p broadcast-network affiliates (including movies they broadcast in HD), 1080i all-HD channels like HDNet/HDNet movies and Discovery HD, or analog cable channels. Even more peculiarly, this also does not occur with other video on the affected premium-movie channels; for example, with a just-recorded recording of _Robin Hood: Prince of Thieves_ (150-minute recording the OSD says is two hours and 16 minutes long), the commercials for other movies ahead of the movie itself, at the top of the recording, all play with proper elapsed time, but the movie itself plays with the aforementioned slow OSD time.

I presume the isue has something to do with the difference between films' 24fps and the NTSC/HD 29.97fps refresh rates, but am puzzled by why this is only an isue with the aforementioned 1080i channels but not the others. I suppose this could be related to #1693 but I have never seen OSD times doubled.

This is an issue I've noticed since first setting up my MythTV box six months ago, on 0.18.1, and has continued through 0.19 and 0.19.1 (all through the ATrpms packages). The recordings are, again, complete, and otherwise play fine at the normal speed. They are *not* sped up in any way; I've tried playing the affected recordings at 0.8X time, approximating the 24/29.97 difference, and that's clearly too slow. (If it matters, I use Bob deinterlacing, but I use it everywhere, including the recordings from the sources without this issue.)

comment:9 Changed 13 years ago by danielk

Milestone: 0.200.21

comment:10 Changed 13 years ago by hamish@…

I've just started seeing this with 0.20. All new recordings made on the ABC channel in Australia (Melbourne specifically) (on DVB-T) have the wrong length. Specifically the time is scaled by 50/60. (50Hz program, 50Hz playback). Old recordings from that channel play fine, and other channels don't seem to be affected. I never saw this before 0.20.

comment:11 Changed 13 years ago by thomas@…

I am seeing the same thing here (PAL, Germany, DVB-C, channel ORF1). It is off by 50/60 (OSD shows real length * 50/60). It only happens on one channel and only with recordings done by 0.20 (old 0.19 recordings are OK). I can provide sample file, if wanted.

comment:12 Changed 13 years ago by thomas@…

This is worse than I thought: Such recordings cannot be transcoded because "No more queue slots!".

comment:13 Changed 13 years ago by cpinkham

Resolution: fixed
Status: newclosed

This issue should have be by [11330] which went in a short while ago. It was related to #2477 also.

comment:14 in reply to:  13 Changed 13 years ago by anonymous

Resolution: fixed
Status: closedreopened

Replying to cpinkham:

This issue should have be by [11330] which went in a short while ago. It was related to #2477 also.

I don't know if the issue initially outlined in this ticket is actually fixed (I presume so, as no one else has replied since), but the issue I describe #1941 (which Isaac marked as a duplicate of this issue) hasn't; it's still there. I am running ATrpms 0.20-fixes r11558. (Let me know if I should just reopen #1941 instead; I'd ahve done so except Isaac was insistent that the two issues were one and the same.)

comment:15 Changed 13 years ago by danielk

Yep, #2477 was a different problem. There are actually two related problems that this ticket is for:

  • Frames are miscounted because we are not parsing the PES packet enough and instead just look for magic byte sequences.
  • MythTV still assumes that the framerate is constant throughout the recording, but this is often not the case with HDTV transmissions.

comment:16 Changed 13 years ago by ylee@…

I just saw this bug pop up with an US ABC HDTV recording. I was surprised because a) I am running ATrpms 0.20-fixes 144, which incorporates SVN changes up to r11683, and b) in almost a year of recording HDTV (including plenty of ABC and FOX) this is the first time. (I am not talking about the issues I reported at #1693 and #1941; as I and others keep noting in each ticket, the issues are perhaps related but not exactly the same.) 'mythtranscode -c -s -b -k -m' did *not* fix the erroneous recording time. The recording itself appears intact, although it seems to stutter a little bit; I *think*, but am not sure, that mythfrontend is mistakenly trying to deinterlace it. I'd have to look at the mythfrontend logs to say more.

As noted, this is an over-the-air recording. Now, it is true that I have only within the past week started recording ABC OTA as opposed to using a cable box with FireWire?, but 1) other ABC OTA recordings have been fine and 2) I've been recording FOX OTA for months without problems.

comment:17 Changed 13 years ago by doug@…

Copied from #2849, which was marked as a duplicate of this one. Some data to help debug.

http://www.parkercat.org/doug/wgbh-weird/ (behind a cable modem, so please go easy):

  • wgbh-weird.ts -- first 200MB of an example bad recording
  • before-commflag.gnumeric -- recordedseek entries for this recording, imported to Gnumeric
  • after-commflag.gnumeric -- recordedseek entries after 'mythcommflag --rebuild'
  • wgbh-weird-gopdump.txt -- slightly-formatted dump of the GOP-containing TS packets, as reported by:
  • tsdump and tsdump.C -- my old program to do minimal parsing on MPEG2-TS files for debug (Linux binary & source)

comment:18 Changed 13 years ago by Janne Grunau

Owner: changed from danielk to Janne Grunau
Status: reopenednew

comment:19 Changed 13 years ago by ryan.goat@…

I just wanted to confirm that I see this problem every week with the FOX show 24. MythTV always displays the length as twice the real length. It also breaks the flagged commercial marks (they don't align up with the commercials). I'm running .20 from the ubuntu repositories.

comment:20 Changed 13 years ago by anonymous

I want to confirm the same problem with Fox 24 show - double lenght, commercial flagged marks incorrectly as well. I'm running MythDora3.2/Fedora Core 5.

comment:21 Changed 13 years ago by james

I have had this problem since day one on recording HD content. Only happens when you start watching an HD recording live / while it is being recorded. The time shows correctly until the time the recording ends at which time the OSD shows double the time. Playback continues as normal.

comment:22 Changed 13 years ago by Janne Grunau

Priority: minormajor
Severity: mediumhigh
Status: newassigned

comment:23 in reply to:  20 Changed 13 years ago by anonymous

Replying to ryan.goat:

I just wanted to confirm that I see this problem every week with the FOX show 24. MythTV always displays the length as twice the real length. It also breaks the flagged commercial marks (they don't align up with the commercials). I'm running .20 from the ubuntu repositories.

and to anonymous:

I want to confirm the same problem with Fox 24 show - double lenght, commercial flagged marks incorrectly as well. I'm running MythDora3.2/Fedora Core 5.

On a happier note, I don't normally watch 24 but tried recording it tonight off HD ATSC. Nothing odd with the episode's displayed length or with the (realtime) commercial flagging.

Also, I haven't seen any recurrences of what I reported in dozens and dozens of subsequent HD recordings from ABC and FOX via both FireWire? and ATSC, so it really does look like a one-time fluke. (#1693 still exists though, but that really is cosmetic.)

I am using 0.20-fixes (ATrpms), r13045.

comment:24 in reply to:  8 ; Changed 13 years ago by anonymous

Replying to ylee@pobox.com:

*All* HD recordings from the 1080i premium-movie channels I subscribe to (HBO HD, Showtime HD, CineMAX HD, Starz! HD) have incorrect recording lengths. A two-hour recording will typically show a total recording time of about one hour and 40 minutes

I wrote the above in mid-2006, with no change since then in terms of this bug's continued existence. Today, I recorded The Lake House, which made its television debut on HBO HD. Surprisingly, the recording's elapsed time is exactly correct. The two previous HBO HD recordings, from a month ago (but also using 0.20-fixes), as well as very-recent recordings from Showtime HD, CineMAX HD, and Starz! HD, all still exhibit the issue. Is there something unusual about the film's technical specs?

comment:25 in reply to:  24 Changed 12 years ago by ylee@…

Replying to anonymous (actually me):

Today, I recorded The Lake House, which made its television debut on HBO HD. Surprisingly, the recording's elapsed time is exactly correct.

Unfortunately, this turned out to be because the seektable had been damaged; once rebuilt, the elapsed time shrank in the same way as with the other recordings. Strange that for the many recordings affected by this issue we have a choice between correct elapsed times and correct seektables, but not both!

comment:26 Changed 12 years ago by Tom Dexter <digitalaudiorock@…>

I've been trying to debug this issue myself (actually using the 0.20-fixes code that I'm running on my frontend) by adding some verbose playback code to NuppelVideoPlayer?.cpp, and have discovered a situation that I simply can't explain. I figured I'd post it in case another set of eyes would see something I missed. Just to be clear, since there seem to have been several different issues discussed here, I'm talking about the following issue: When you're playing a recorded program that's still in the process of recording and recording finishes, the total length displayed is erroneously doubled. If you exit playback and play it again, it displays correctly from the database. Note that in my case I reproduced this with a 720p HD broadcast recording at 59.94 fps.

I changed NuppelVideoPlayer::SetFileLength? as follows:

void NuppelVideoPlayer::SetFileLength(int total, int frames)
{
    totalLength = total;
    totalFrames = frames;
    VERBOSE(VB_PLAYBACK, QString("SetFileLength set: total: %1, frames: %2").arg(total).arg(frames));
}

I also made the following change within NuppelVideoPlayer::calcSliderPos to monitor what's being displayed in the OSD and where it's coming from:

    int playbackLen = totalLength;

    if (livetv && livetvchain)
    {
        posInfo.progBefore = livetvchain->HasPrev();
        posInfo.progAfter = livetvchain->HasNext();
        playbackLen = livetvchain->GetLengthAtCurPos();
    }
    else if (watchingrecording && nvr_enc && nvr_enc->IsValidRecorder()) {
        playbackLen =
            (int)(((float)nvr_enc->GetFramesWritten() / video_frame_rate));
        VERBOSE(VB_PLAYBACK, QString("calcSliderPos: nvr_enc playbackLen: %1, video_frame_rate: %2").arg(playbackLen).arg(video_frame_rate));
    } else {
        VERBOSE(VB_PLAYBACK, QString("calcSliderPos: playbackLen: %1, video_frame_rate: %2").arg(playbackLen).arg(video_frame_rate));
    }

I then reproduced the bug with a recording that, when finished, would be about 27 minutes long and a bit over 96000 frames (at 59.9401 fps). Before it finished recording, the verbose outout when displaying the OSD (by pausing or entering 'i') looked fine:

2007-09-30 10:56:55.605 calcSliderPos: nvr_enc playbackLen: 1432, video_frame_rate: 59.9401

The 1432 seconds (about 24 minutes) was correct at that point.

When the recording finished and it switched from WatchingRecording? to WatchingPreRecorded?, I got the following output:

2007-09-30 11:00:01.104 SyncPositionMap prerecorded, from DB: 3206 entries
2007-09-30 11:00:01.104 SetFileLength set: total: 1604, frames: 96149
2007-09-30 11:00:01.104 SyncPositionMap, new totframes: 96149, new length: 1604, posMap size: 3206

So far, this looked fine as well. The 1604 seconds and the 96149 frames are correct.

Here's where I get stumpted...without stopping playback, bringin up the OSD produced the following:

2007-09-30 11:00:37.111 calcSliderPos: playbackLen: 3235, video_frame_rate: 59.9401
2007-09-30 11:00:37.375 calcSliderPos: playbackLen: 3235, video_frame_rate: 59.9401
2007-09-30 11:00:37.823 calcSliderPos: playbackLen: 3235, video_frame_rate: 59.9401

...and the OSD displayed an erroneous total length of over 53 minutes. First of all, note that the playbackLen variable is in fact doubled at this point. Also note that this output can only come from a situation where the playbackLen is coming directly from the contents of the totalLength member variable.

That's where I hit a brick wall. This appears to indicate that the totalLength member is incorrect at this point, yet there's no sign of SetFileLength? (the only place I can find that should be setting it) setting it incorrectly.

I figured I'd post this in the hopes it would point someone in the right direction to get to the bottom of this old one.

comment:27 Changed 12 years ago by Tom Dexter <digitalaudiorock@…>

For anyone interested, I was informed here:

http://www.gossamer-threads.com/lists/mythtv/dev/293127

...that TV::customEvent within libs/libmythtv/tv_play.cpp calls NuppelVideoPlayer::SetLength?() when it receives the DONE_RECORDING event from the recorder and sets the length to the one reported by the recorder (which can be incorrectly calculated). In my specific situation (DTV recordings only) I found that simply commenting out that call prevents the double length display when recording finishes and has caused no ill effects that I can see:

void TV::customEvent(QCustomEvent *e)
{
    if ((MythEvent::Type)(e->type()) == MythEvent::MythEventMessage)
    {
        MythEvent *me = (MythEvent *)e;
        QString message = me->Message();

        if (recorder && message.left(14) == "DONE_RECORDING")
        {
            if (GetState() == kState_WatchingRecording)
            {
                message = message.simplifyWhiteSpace();
                QStringList tokens = QStringList::split(" ", message);
                int cardnum = tokens[1].toInt();
                int filelen = tokens[2].toInt();

                if (recorder && cardnum == recorder->GetRecorderNumber())
                {
                    nvp->SetWatchingRecording(false);
//                    nvp->SetLength(filelen);
                    ChangeState(kState_WatchingPreRecorded);
                }
            }

This causes it to continue using the length that was calculated from the database and the remote encoder just prior to the end of recording.

comment:28 in reply to:  27 Changed 12 years ago by ylee@…

Replying to Tom Dexter <digitalaudiorock@hotmail.com>:

In my specific situation (DTV recordings only) I found that simply commenting out that call prevents the double length display when recording finishes and has caused no ill effects that I can see:

I can confirm that the patch does indeed fix the problem on 0.20.2. I have not noticed any ill side effects in several days of usage.

comment:29 in reply to:  description ; Changed 12 years ago by anonymous

I thought this problem had all but disappeared since over a year ago, but I have been seeing it frequently in recent weeks. I have been staying fairly close to the HEAD bleeding edge, so I'm not certain if there is a relatively new bug or if something in the broadcast streams has changed. At the moment, I'm running revision 14813. I'm seeing the time doubling described above on some recordings, typically on HD shows that are 720p@60 (really 59.94 fps) on local ABC and Fox stations. Some recordings from those stations have the correct time and some have double of the correct time. The incorrect times are displayed whenever the recording is played, typically after recording is finished.

In addition, some of the recordings from the same sources behave even more strangely. The displayed total times are very large, ranging from 2 to almost 10 hours. They are always much larger than the correct time, but don't seem to be directly related to the correct time. I've seen values like 2:20 and 9:40 for an hour show.

These recordings have severe problems with playback and seeking. Playback is often very uneven, with pauses in video and audio about once a second. If I pause, then unpause, playback is smooth. If I exit playback, then start again, it will be uneven until I pause again. CPU usage during all of this is typically around 60% of one of the two cores.

These recordings have very strange seek behavior, usually skipping by correct amounts, but sometimes skipping large parts of the recording both forward and backward. Playing continuously through the same section works fine and the big skips can be reproduced. Commercial skipping usually works correctly, except it will make the same big skips that manually seeking will.

Some recordings have shown a position of zero at about five minutes into the recording. I can't seek to anything earlier than zero, so the beginning section is inaccessible. Sometimes this problem can be worked around by playing the recording from the beginning again, but as soon as any seek is attempted, the bogus zero position returns.

I've run "mythcommflag --rebuild" on several of the problematic recordings and it only makes things worse. The displayed total time usually increases to a value that's even farther from the truth and seeking problems aren't fixed.

So far, Xine and Mplayer have had no significant trouble playing the affected recordings (except that Mplayer doesn't seem to be able to automatically select an audio stream from a TS and must be told which one to play). I'm wondering if MythTV would benefit from the option to use an external player like Mplayer to work around these apparent deficiencies in the internal player. I already do this in MythVideo??, so why not for regular recordings?

comment:30 in reply to:  29 ; Changed 12 years ago by ylee@…

Replying to anonymous:

I'm seeing the time doubling described above on some recordings, typically on HD shows that are 720p@60 (really 59.94 fps) on local ABC and Fox stations. Some recordings from those stations have the correct time and some have double of the correct time. The incorrect times are displayed whenever the recording is played, typically after recording is finished.

As I noted in my previous message, this issue appears to be fixed by Tom Dexter's patch. It was always a purely-cosmetic issue, anyway (unless it's related in some way to the other bug you describe below, which is possible).

In addition, some of the recordings from the same sources behave even more strangely. The displayed total times are very large, ranging from 2 to almost 10 hours . . . These recordings have severe problems with playback and seeking.

This is another issue with 720p sources that I and others reported earlier. However, I am happy to say that, since that report a year ago, I have never seen the issue recur despite recording many, many ABC and FOX broadcasts. I have never used trunk, though; only 0.19 and now 0.20.2.

comment:31 in reply to:  30 Changed 12 years ago by jonner@…

Replying to ylee@pobox.com:

Replying to anonymous:

I'm seeing the time doubling described above on some recordings, typically on HD shows that are 720p@60 (really 59.94 fps) on local ABC and Fox stations. Some recordings from those stations have the correct time and some have double of the correct time. The incorrect times are displayed whenever the recording is played, typically after recording is finished.

As I noted in my previous message, this issue appears to be fixed by Tom Dexter's patch. It was always a purely-cosmetic issue, anyway (unless it's related in some way to the other bug you describe below, which is possible).

Yeah, well that's what I'm not sure of. There seems to be overlapping incorrect behavior, and I'm not sure what the source is. I wouldn't bother discussing if it were just doubled length reporting, but some of the other possibly related problems are extremely annoying and would easily make a recording unwatchable if someone didn't know how to work around it by using a different player.

In addition, some of the recordings from the same sources behave even more strangely. The displayed total times are very large, ranging from 2 to almost 10 hours . . . These recordings have severe problems with playback and seeking.

This is another issue with 720p sources that I and others reported earlier. However, I am happy to say that, since that report a year ago, I have never seen the issue recur despite recording many, many ABC and FOX broadcasts. I have never used trunk, though; only 0.19 and now 0.20.2.

I used 0.19, then 0.20, then various SVN trunk revisions. I switched to trunk to get some of the newer features like recording groups. This problem hasn't been common until recent weeks, which is why I think it might be a new bug in trunk. It's strange if there's a new bug that behaves like an old one.

comment:32 in reply to:  30 ; Changed 12 years ago by ylee@…

anonymous (actually jonner@) wrote:

I'm seeing the time doubling described above on some recordings, typically on HD shows that are 720p@60 (really 59.94 fps) on local ABC and Fox stations. Some recordings from those stations have the correct time and some have double of the correct time. The incorrect times are displayed whenever the recording is played, typically after recording is finished.

I wrote in reply:

As I noted in my previous message, this issue appears to be fixed by Tom Dexter's patch. It was always a purely-cosmetic issue, anyway (unless it's related in some way to the other bug you describe below, which is possible).

Rereading jonner@'s message, I realize that I likely misinterpreted his bug report. He wrote:

Some recordings from those stations have the correct time and some have double of the correct time. The incorrect times are displayed whenever the recording is played, typically after recording is finished.

jonner@'s report indicates that his problem recordings always display doubled recording times. I've never seen that; the bug that I reported Tom's patch as fixing is what he describes in #comment:26 (also reported at #1693); thus my description of it as "cosmetic."

comment:33 in reply to:  32 ; Changed 12 years ago by jonner@…

Replying to ylee@pobox.com:

jonner@'s report indicates that his problem recordings always display doubled recording times. I've never seen that; the bug that I reported Tom's patch as fixing is what he describes in #comment:26 (also reported at #1693); thus my description of it as "cosmetic."

I have some recordings that show double the correct total time and otherwise behave fine. I also have more problematic recordings that display incorrect total time. Though that incorrect time is usually double of what it should be, it is sometimes even greater than double.

Since I don't know what's going on inside, I can't say what the precise relationships are between these behaviors. I may be seeing the same bug as ylee@… on some recordings and an entirely different bug on others. My guess is that they're somehow related.

comment:34 in reply to:  33 Changed 12 years ago by Tom Dexter <digitalaudiorock@…>

Replying to jonner@teegra.net:

I have some recordings that show double the correct total time and otherwise behave fine. I also have more problematic recordings that display incorrect total time. Though that incorrect time is usually double of what it should be, it is sometimes even greater than double.

Since I don't know what's going on inside, I can't say what the precise relationships are between these behaviors. I may be seeing the same bug as ylee@… on some recordings and an entirely different bug on others. My guess is that they're somehow related.

Actually I don't think they are. The temporary display of doubled length of a recording (when recording completes while you're watching the recording) is caused by the length reported by the recorder, which doesn't know the frame rate at all. If you see a doubled length when playing it back later, that doesn't involve the recorder at all...and I've never seen any such thing myself. I believe that calculates the length based on the frame rate from the file itself and data in the recordedseek table.

The only 'pertinent' incorrect lengths I ever see are one hour shows that display as around 51 minutes. For me these are always dramas recorded off of NBC HD. They are apparently using different frame rates for commercials and myth as yet does not handle that...since it assumes one frame rate, it causes that much of an error...but certainly never doubled or anything like that. By the way...I believe that this is one of the reasons that nobody has addressed the issue of the recorder not knowing the frame rate, as the handling of multiple frame rates is a much more complex issue that's yet to be hashed out.

comment:35 Changed 12 years ago by Janne Grunau

Milestone: 0.21unknown

comment:36 in reply to:  35 ; Changed 12 years ago by jonner@…

Replying to janne: So, does this mean others can't reproduce this problem? A majority of my recordings from one station (the local Fox channel with a 720p@59.94 stream) report that they're twice of what they should be. Some recordings from that station display the correct time.

However, I have not experienced any show-stopping playback problems recently. When the time is incorrect, the playback is usually very choppy until I pause and unpause playback. After resuming, playback is smooth. So, using that simple workaround, the puts my problem in the cosmetic category.

comment:37 in reply to:  36 ; Changed 12 years ago by ylee@…

Replying to jonner@teegra.net:

Replying to janne: So, does this mean others can't reproduce this problem? A majority of my recordings from one station (the local Fox channel with a 720p@59.94 stream) report that they're twice of what they should be. Some recordings from that station display the correct time.

I've never seen this issue in more than two years and hundreds of high-definition recordings from the local FOX and ABC affiliates via OTA and cable on 0.18, 0.19, and 0.20, with only a single exception. I can only conclude that there's some peculiarity with your local FOX affiliate's encoder that is causing issues with MythTV.

comment:38 in reply to:  37 Changed 12 years ago by jonner@…

Replying to ylee@pobox.com:

Replying to jonner@teegra.net:

Replying to janne: So, does this mean others can't reproduce this problem? A majority of my recordings from one station (the local Fox channel with a 720p@59.94 stream) report that they're twice of what they should be. Some recordings from that station display the correct time.

I've never seen this issue in more than two years and hundreds of high-definition recordings from the local FOX and ABC affiliates via OTA and cable on 0.18, 0.19, and 0.20, with only a single exception. I can only conclude that there's some peculiarity with your local FOX affiliate's encoder that is causing issues with MythTV.

Yes, that's entirely possible. I'll have to try recording programs from the ABC station, which is the only other local one broadcasting in 720p, to see if it shows the same behavior.

comment:39 Changed 11 years ago by Dibblah

Possibly fixed by [20311]?

comment:40 Changed 10 years ago by Tom Dexter <digitalaudiorock@…>

I've recently upgraded my 0.21-fixes to rev 20500. Up until now I've always used the work around I described above where the nvp->SetLength? call (now at line 6304) is simply commented out.

I can tell you for sure that the 20312 changeset (the 0.21-fixes backport of 20311) does not correct this. The doubled length display issue always occurred for me when watching any 720p recording (for me, that's OTA Fox or ABC) while it's recording, at the point where recording ends and it switches from WatchingRecording? to WatchingPreRecorded?. With no fix at all, this causes the OSD to show the length as double what it really is. My old work around fixes this. The 20312 change however seems to cause the OSD to show "0:01 of 0:01", which stays that way until I exit and re-enter the recording.

I'm in the process of adding my work around back into my 20500 install.

Note however that up to this point my backend is still on rev 18314 of 0.21-fixes as I haven't had a chance to upgrade it yet. I'll be upgrading it shortly, and if that changes any of this I'll post back.

comment:41 Changed 10 years ago by Tom Dexter <digitalaudiorock@…>

Duh...please ignore my previous comment. I can see that the missing change to 20312 on the backend (in tv_rec.cpp) would clearly cause the results I'm getting. I'll test this again once that's upgraded.

comment:42 Changed 10 years ago by Tom Dexter <digitalaudiorock@…>

Yup...with the 20312 change set on both frontend and backend machines, the change definitely corrects this issue. That is, of course, within the limits of assuming a constant frame rate...but it corrects the doubling of the length for sure.

comment:43 Changed 10 years ago by Tom Dexter <digitalaudiorock@…>

This is odd. While the 20312 change set does prevent the doubled length display, last night I had it update the length of a show incorrectly. This is with rev 20500 on both back and frontend machines. We started watching a recording off of Fox while it still had about 20 minutes to go. After those 20 minutes, it appeared that the nvp->SetLength?() call apparently updated the length to zero. When I noticed it it was about four minutes after the show ended and the display showed 4:03 of 4:03 with both numbers increasing second by second (even though I was 24 minutes into the recording). Exiting and re-entering it of course fixed this.

I have no idea what caused that, but I'm re-installing my change above that comments out the nvp->SetLength?() call. Actually, I've never been clear as to the point of that call when switching from WatchingRecording? to WatchingPreRecorded? anyway, as the existing length at that point of playback is always as accurate as it's going to get anyway.

comment:44 Changed 10 years ago by stuartm

Milestone: unknown0.22
Resolution: fixed
Status: acceptedclosed
Ticket locked: set

Closing this since it's just become a dumping ground for a range of unrelated problems with similar symptoms. If anyone has problems with current trunk then open a new ticket with a fresh set of logs etc.

Note: See TracTickets for help on using tickets.