Issue 124 in mp4v2: mp4track changes fail on MP4 files >2 GByte on Certain Systems

[mp...@googlecode.com]

Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 124 by CarlEd...@gmail.com: mp4track changes fail on MP4 files >2
GByte on Certain Systems
http://code.google.com/p/mp4v2/issues/detail?id=124

What steps will reproduce the problem?
1. Pull r479 source from server to ReadyNAS Ultra (running Linux on Intel®
Pentium Dual-core CPU)
2. Compile sources according to instructions
3. Use mp4track to enable/disable certain audio tracks on long list of files

What is the expected output? What do you see instead?
I just ran an auto-generated script to disable all but to the primary audio
track on a list of a few hundred mp4s (stupid Apple iTunes/iPod/iWhatever
will play *all* audio tracks unless you disable them, spoiling the
experience for the kids with director voiceovers in alternate tracks--other
software/hardware allows you just to select one track to play).

It worked fine on almost all files. On a handful of files I got error
messages that tracks could not be enabled/disabled. The set of these files
corresponds exactly to the files larger than 2 GBytes (mostly HD encodes,
but smaller HD encodes worked fine).

What version of the product are you using? On what operating system?
See above.

Please provide any additional information below.
Looks like ye-olde signed-32-bit-int lseek bug. Any way around that on a
32-bit Linux as that ReadyNAS appears to be running?

[mp...@googlecode.com]

Comment #1 on issue 124 by jnor...@logitech.com: mp4track changes fail on

MP4 files >2 GByte on Certain Systems
http://code.google.com/p/mp4v2/issues/detail?id=124

any wan you can provide a small program and file that reproduces the bug?

[mp...@googlecode.com]

Comment #2 on issue 124 by CarlEd...@gmail.com: mp4track changes fail on

MP4 files >2 GByte on Certain Systems
http://code.google.com/p/mp4v2/issues/detail?id=124

There's the rub... a small program is easy, mp4track and I suspect most
other mp4v2 tools provide examples. But as the bug manifests itself
exclusively on mp4 files larger than 2 GByte (and not on all
architectures), providing an example file is well-nigh impossible.

Perhaps a simple grep on use of lseek (rather than lseek64) on 32-bit
architectures would uncover the problem?