rick at timeforabrew
May 11, 2012, 1:33 PM
Post #4 of 6
On May 3, 2012 10:58 AM, "John Veness" <John.Veness.mythtv [at] pelago>
Re: UK DVB-T radio timing problems since 0.25
[In reply to]
> On 02/05/2012 15:12, John Veness wrote:
>> I've just updated to MythTV 0.25 (previously 0.24) using the Mythbuntu
>> packages, on Ubuntu 11.10. I didn't change the underlying Ubuntu version
>> at the same time.
>> Since 0.25, playing back programs on UK DVB-T (Freeview) radio channels
>> shows screwy timecode problems. For example, a 35 minute recording plays
>> as a 29 min 11 seconds recording. That is, the total length shows as 35
>> minutes, but the current position marker will change from zero to
>> 29min11 before stopping. During that time it will play the entire 35
>> minute recording at normal speed. In other words, the current position
>> marker is lagging behind real time.
>> Also, when skipping forward or backward, e.g. by 30 seconds or by 10
>> minutes, there is a noticeable delay of a second or so before the skip
>> takes place and before the OSD pops up. Doing lots of skipping feels a
>> bit like wading through treacle, like it is having problems finding the
>> position in the file to seek to.
>> Both of these things were fine on identical hardware and identical
>> underlying Ubuntu version with MythTV 0.24. Note that these problems
>> occur both with new recordings made with 0.25 and old recordings made in
>> Before I report this as a bug, I wondered if anyone else had seen these
>> problems or knew of a fix?
> Since I wrote the above, I've realised I haven't described the problem
correctly. The second paragraph should be:
> Since 0.25, playing back programs on UK DVB-T (Freeview) radio channels
shows screwy timecode problems. For example, a 35 minute recording plays as
a 29 min 10 seconds recording. That is, the total length shows as 35
minutes, but the current position marker will change from zero to 29min10
before stopping. The last almost 5 minutes 50 seconds of the recording will
not play in Myth.
> Note that if I watch the filesystem as the program is recording, I do see
the filesize increasing during the last six minutes of the recording. Also,
if I play back the file with something else, e.g. ffplay, it will play the
full 35 minutes. So this is a problem with playback in Myth, not with
> I notice with interest that 35 minutes is 2100 seconds, and 29 minutes 10
seconds is 1750 seconds. 2100/1750 is 1.2, or the same as 60/50. Is this
some kind of 60fps vs 50fps mismatch?
> These recordings have no video, just audio and MHEG. Maybe because they
have no video, Myth is making a guess at 60 frames per second rather than
(as it should be in UK) 50 frames per second. It then does some kind of
calculation and plays what it thinks is the correct length but stops early.
I haven't checked the code, so this is just a guess. Note that as far as I
can tell, the recording is playing back at correct speed and pitch.
> Does anyone want a sample file?
> John Veness, MythTV user, UK, DVB-T
> mythtv-users mailing list
> mythtv-users [at] mythtv
I'm also seeing this. Usually my radio recordings are just extracted to mp3
rather than listened to directly on a mythfrontend so I hadn't noticed it.
I've played back a couple of recordings via the frontend and see the same
thing. One recording is 38.00 minutes and the internal player stops at
31.38. Another recording of 19.00 exits at 15.53. MHEG being disabled makes
If its relevant, I took a look at the 'playback data' available via the
playback menu and compared a radio broadcast to a normal one. The normal
one displays FPS: 25.06±0.01, video: 720x576 [at] 25, while the radio
broadcast displays FPS:30.03±0.01, video: 0x0 [at] 29