when playing large recording via UPnP, seek causes playback to end

[p-fbsd-bugs@…]

When I play back some of my recordings via UPnP, any attempt to fast-forward causes the playback to exit. It's highly annoying.

The problem exists for both of my (independent) backends:

• backend p: Ubuntu 11.10, mythtv 0.24.0+fixes.20110908.1de0431-0ubuntu1
• backend h: FreeBSD 8.2-STABLE, mythtv-0.25.2

It occurs when I play back from either of my UPnP frontends:

• frontend w: WD TV Live plus
• frontend h: FreeBSD 8.2-STABLE, xbmc-11.0_5

but NOT when I play back via mythfrontend 0.25.2 (no UPnP).

The file size of the recording seems to affect the behavior. I experimented on the 0.25.2 backend by copying the recording file to the "Videos" directory and truncating it to various lengths. The problem did not occur until I got past a threshold length.

The original recording file:

% ls -ls 1071_20120818195600.mpg
 8545440 -rw-rw-r--  2 mythtv  video  8746232444 Sep  9 01:18 1071_20120818195600.mpg

My test procedure iteration was:

rm sample.mpg
mythutil --scanvideos
dd if=1071_20120818195600.mpg of=sample.mpg bs=1024k count=<N>
mythutil --scanvideos
mythcommflag --rebuild --video `pwd`/sample.mpg

For N <= 6600, seeking seemed to work OK. For N>= 6700, the problem appeared. I did not try values between 6600 and 6700.

I looked at the old patch in ticket:1591 and applied it to av_gen_search(), but it didn't seem to make any difference.

Since the threshold size is in the neighborhod of 7GB, I do not have a good place to host this file. If anyone would like a copy, I can put it on my home server (128kbit/s uplink) or I can upload it somewhere.

[Raymond Wagner]

The concept of a "threshold" is awfully reminiscent of 32-bit issues in the past, however those have always been encountered at multiples of 2GB or 4GB for obvious reasons. A brief test in Windows Media Player against MythTV 0.26rc using several recordings between 5GB and 12GB in length did not exhibit any such seeking issues.

MythTV records using the MPEG TS container, which many players have poor or incomplete support for. Is it possible there was an error in the recording you are using, or something strange in the timecodes, that MythTV's internal player can handle but these other players cannot? Have you tried playing the file in question in XBMC directly off the filesystem, to rule it out as your source of error?

[p-fbsd-bugs@…]

Well, _that_ was an interesting test. When I had xbmc play this recording from the local filesystem, it exhibited the same problem at the same threshold. I might get time tomorrow to see if I can get the WDTV box to play the file via NFS.

So maybe there _is_ something in the file that triggers the bad behavior, both for xbmc as well as the WDTV Live Plus. Are there tools I can run against the recording file to check for invalid or uncommon elements?

I don't know enough about video formats or how the UPnP frontends work to even speculate on a workaround. Is there anything mythbackend could do to clean up the mpeg file? (I'm thinking some user job, but no idea what to try).

[Raymond Wagner]

Mythtranscode will output an MPEG PS when performing a lossless transcode, which may be more compatible with your players. Alternatively, you could use mkvmerge or mp4box to remultiplex into an mkv or mp4, respectively.