Incorrect program duration

[paul49]

I've recently upgraded my media server to an i7, upgraded Mezzmo to v5 and retired Windows Media Centre in favour of Media Portal TV Server.
The previous server was too slow to transcode on the fly so I wrote a C++ utility to interrogate WMC every hour and repackage any new recordings from .wmv to MPEG program streams so that my Sony devices could play them natively. This worked well for years.

The new server is quick enough to transcode the transport streams coming from MediaPortal in real time so I've retired the utility. This is generally working very well.

However, I've noticed that occasionally Mezzmo is reporting incorrect program durations. I had a closer look at one of them and found that ffmpeg reports the correct duration (in this case 1 hr 17 min), VideoRedo reports correctly as does Windows Explorer and Windows Media Player. Mezzmo however, displays the duration as 15 minutes. When I try to play the program, the TV also reports 15 minutes and plays erratically. If I manually run up VideoRedo and do a Quickstream Fix on the recording, all is OK.

I've also noticed some other programs reporting as over 10 hours in Mezzmo when, in fact, they're only an hour or so.

It's only a minor issue but has anyone else noticed this behaviour with MPEG transport streams recorded from TV?

Thanks,
Paul.

[paulsalter]

Hi,

I have also had this occasionaly, along with ffmpeg not being able to detect the video width so the show fails to add

I have put it down to slight corruption in the file while the recording is in place, i tested mine on another dlna server that uses ffmpeg and it shows the same problem

Like you, playback of the file is fine when using local apps, just ffmpeg cant detect the info, a quick mpeg fix program corrects it

I can go weeks without seeing it, then get this a few times in a few days

[jbinkley60]

I've recently upgraded my media server to an i7, upgraded Mezzmo to v5 and retired Windows Media Centre in favour of Media Portal TV Server.
The previous server was too slow to transcode on the fly so I wrote a C++ utility to interrogate WMC every hour and repackage any new recordings from .wmv to MPEG program streams so that my Sony devices could play them natively. This worked well for years.

The new server is quick enough to transcode the transport streams coming from MediaPortal in real time so I've retired the utility. This is generally working very well.

However, I've noticed that occasionally Mezzmo is reporting incorrect program durations. I had a closer look at one of them and found that ffmpeg reports the correct duration (in this case 1 hr 17 min), VideoRedo reports correctly as does Windows Explorer and Windows Media Player. Mezzmo however, displays the duration as 15 minutes. When I try to play the program, the TV also reports 15 minutes and plays erratically. If I manually run up VideoRedo and do a Quickstream Fix on the recording, all is OK.

I've also noticed some other programs reporting as over 10 hours in Mezzmo when, in fact, they're only an hour or so.

It's only a minor issue but has anyone else noticed this behaviour with MPEG transport streams recorded from TV?

Thanks,
Paul.

If you go into the Mezzmo GUI and then look at Properties --> Video does it show the correct values there ? If not try the Get Properties from File option. If that fixes it then a likely culprit is that Mezzmo tried to discover the file automatically while it was still being copied or transcoded.

[paul49]

I can go weeks without seeing it, then get this a few times in a few days
That's my experience as well.

[paul49]

If you go into the Mezzmo GUI and then look at Properties --> Video does it show the correct values there ? If not try the Get Properties from File option. If that fixes it then a likely culprit is that Mezzmo tried to discover the file automatically while it was still being copied or transcoded.
Thanks jbinkley60. That fixed the file which Mezzmo reported as 15 minutes but not the ones which it reported as over 10 hours. Interestingly ffmpeg shows the incorrect duration for these as well but the other programs are correct.

[jbinkley60]

Thanks jbinkley60. That fixed the file which Mezzmo reported as 15 minutes but not the ones which it reported as over 10 hours. Interestingly ffmpeg shows the incorrect duration for these as well but the other programs are correct.

So for the 10 hour ones the Mezzmo Properties show the file length as 10 hrs ? If so the Mezzmo folks will need to help here.

[paul49]

So for the 10 hour ones the Mezzmo Properties show the file length as 10 hrs ? If so the Mezzmo folks will need to help here.
I suspect the problem lies with ffmpeg rather than Mezzmo. I assume that Mezzmo uses ffmpeg to read the program duration and ffmpeg is reporting it incorrectly. All my other tools (including plain old Windows Explorer) report it correctly.

There are quite a few tickets (one is recent) opened against ffmpeg regarding similar issues. When I get a chance, I'll do some reading and testing. I quickly ran ffmpeg with -analyzeduration and it's still wrong.

Hardly a show stopper - I can manually fix it in a couple of minutes. Thank you for your suggestions - as you said, it seems likely that Mezzmo might have added the (15 minute file) while it was still recording. That's easy to fix if it happens again.

[paul49]

I just had a look though my various Mezzmo folders and found quite a large number of programs all with around 10 hours reported and they're all from the same TV channel. But not all programs are wrong and even when there are multiple episodes of the same series, some are correct and some are not. The recordings from the other channels are correct in each case.

The channel in question has comparatively poor signal strength and quality and the recordings on this channel experience dropouts quite frequently.


I have put it down to slight corruption in the file while the recording is in place
Agree - maybe it's just corrupt timestamps and, for whatever reason, ffmpeg can't recover? I've never really had a reason to study ffmpeg's command line options in any great detail. If I get bored one day, I'll do some further research. :)

[paulsalter]

Just been looking back from when i was looking into this before

Here is an example of one of mine with issues (this data was taken from Mediainfo program)
From what i could gather (thought dont fully understand) is that the ones with problems have this GOP setting, the ones that work have Variable for this
Not sure if this is somehow the broadcaster sending data slightly differently to reduce bitrates, or the bitrates are reduced automatically for some reason (less frames per second) which is throwing ffmeg off

This is one that looks ok at 30 mins, but Mezzmo (and tested on Serviio which uses ffmeg also), both of these the show is reported as 5 mins
Unfortunately i have long since deleted this file so cannot do any more test with it

Video
ID : 101 (0x65)
Menu ID : 4169 (0x1049)
Format : MPEG Video
Format version : Version 2
Format profile : Main@Main
Format settings, BVOP : Yes
Format settings, Matrix : Custom
Format settings, GOP : M=3, N=24
Format settings, picture structure : Frame
Codec ID : 2
Duration : 29 min 58 s
Bit rate mode : Variable
Bit rate : 2 333 kb/s
Maximum bit rate : 15.0 Mb/s
Width : 704 pixels
Height : 576 pixels
Display aspect ratio : 16:9
Active Format Description : Letterbox 16:9 image, with alternative 14:9 center
Frame rate : 25.000 FPS
Standard : PAL
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Interlaced
Scan order : Top Field First
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.230
Stream size : 500 MiB (80%)

[paul49]

is that the ones with problems have this GOP setting, the ones that work have Variable for this
I just checked a series I recorded where 5 episodes had the incorrect duration and 2 were correct and, unfortunately, there is no correlation with the GOP information.

I know a lot more about (still) image compression and formats (it used to be my job) than I do about video but GOP looks like it roughly corresponds (in a much more complex way) to what happens in a CCITT Group 3-2D image - individual frames in a GOP are used to store "difference" data referring to previous frames (saving on data) and there is a fully encoded frame at the beginning of each GOP.

I'm becoming more interested in finding out what's happening here, even though we couldn't do much if an answer is found. Perhaps someone from Mezzmo may wish to comment after the weekend.

[Peter]

Hi,
we recently encountered a similar problem using using merged vob files, sometimes the timestamps are restarted in one of the vob files and this results in the incorrect duration being detected. So for vob 1 and 2 the duration is correct but in vob 3 the timestamps restart and when ffmpeg tries to get the duration it reads the last packet from the stream to get the timestamp and subtracts the timestamp in the first packet to get the duration. This can result in a rollover if the last timestamp is very large and result in a value like 10 hours or if the value is very small it can show 5 minutes, either way it is wrong. I suspect that when recording the stream the timestamps may be reset at some point and this is causing the problem, re-encoding the file will correct the timestamps. We made a change in Mezzmo 5.1 for multi-file DVDs to fix the timestamps on the fly when streaming, if you can send us one of the files with the bad timestamps we can possibly do the same procedure when streaming the file. Please upload a sample file to a sharing site like dropbox or google drive and send us a download link to support [at] conceiva [dot] com

[paul49]

Hi Peter,

Thanks for the response. I suspected a timestamp issue which was perhaps a result of the occasionally poor signal quality of the channel in question. I haven't been using MediaPortal to record TV for very long - perhaps it disturbs/resets the timestamps when a significant loss of signal occurs. Previously I was using WMC but, since I always ran every recording through VideoRedo before it was offered to Mezzmo, I have no idea if the issue occurred in that environment as well.

The only curious thing is that ffmpeg is reporting slightly more than 10 hours for all the corrupt files. I might have expected a more random spread of (incorrectly calculated) durations.

As I said, it's no more than a curiosity. If it becomes an annoyance, I'll just write some code to fix it. :)

[Peter]

I expect the 10 hour issue would be due to a rollover of the value where the end value minus the start value results in a negative number.