PotPlayer playlist displays incorrect duration time after TagEditor saves an MP4 file.

[David-Maisonave]

After modifying any MP4 file with TagEditor, PotPlayer playlist duration time is increased by a factor of 90. A 56 minute video becomes a 85 hour video.

On PotPlayer the [File Information] windows still shows the correct duration time, and it shows the correct duration time at the bottom of the screen. But the sliding bar at the bottom is way off, and the playlist duration time is also way off. I looked at the modified files using a program called MediaInfo, and I see an mdhd_Duration value which is not in the original files.

For a 56 minute and 28 seconds video, the mdhd_Duration value is 3388689. I believe that number should be 3388, which would equal the total number of seconds. I'm not sure if that's what's causing the issue, but that's the only thing that stood out.

I've attached a screen shot of a 1 minute and 57 seconds video which has been modified by TagEditor, and now the playlist is listing the duration as 1 hour, 26 minutes, and 2 seconds. Notice the slide bar is almost all the way to the left, but the play time is 1:54 out of 1:57. With 3 seconds remaining, the slide bar should be to the far right.

MediaInfo shows 117075 for mdhd_Duration.

I tested this with tageditor-qt6-3.6.0-x86_64-w64-mingw32 and tageditor-3.6.0-i686-w64-mingw32.exe I got the same results. PotPlayer version 220106. See attached file image.

[Martchus]

I'll have a look. Note that the duration within the mdhd atom is actually not necessarily the number of seconds. It might be multiplied by a "time scale" factor and the Tag Editor is actually simply using the factor which is already present in the file. However, there might be some bug.

[Martchus]

GitHub closed this due to the referenced commit. It might fix the issue, indeed. I couldn't really reproduce the problem (and I also don't use that proprietary player) but noticed some rounding errors. I simply changed the code so the tag editor doesn't tamper with the timing values at all (just keeps the raw values within the files as-is).

Note that MediaInfo's mdhd_Duration seems to be in milliseconds (or possible even some other unit depending on the time scale). So no, I don't think it is necessarily in seconds. And it is only displayed in the processed files due to the mentioned rounding errors as they cause inconsistencies. (MP4 files store the duration of each track in two different places for some reason.)

I suppose I'll create a new release soon because even alone the inconsistencies due to rounding are quite annoying. It would be great if you could help me testing. I've created new Windows binaries which are available here: https://martchus.no-ip.biz/repo/arch/ownstuff-experimental/os/x86_64/ (Just grab the static binary from mingw-w64-tageditor-*.pkg.tar.zst files.)

[David-Maisonave]

The new binary works great! I tested it with original file, and after saving the file, PotPlayer playlist displays correct duration time. Much to my surprise, the new binary is even able to fix the files which where modified by TagEditor-3.6.0.

This is fantastic, because I had already deleted the backups before I realized the issue.

Thank you very much!

[David-Maisonave]

FYI: I would have responded sooner, but I didn't know what a zst file was, so I wasn't sure what to do with it. Moreover, I use 7zip, and it didn't recognize it as a compress file, so I though it was some type of self updating file that had to be dropped in same folder as the binary. When that didn't work, I googled it, and found a free archiving app PeaZip. ZST is not as will known as zip and tar. You might want to include a PeaZip or ZST link with the post.

[Martchus]

Glad to hear it works. I've created a new release. The binaries in the release section are zip files. Only the builds in my experimental development repository use zst (because it is one of the best compression algorithms currently available). I would recommend bsdtar (compiled with zst support) to unpack these archives.

[David-Maisonave]

I do see a minor issue, which is not specific to the update, and not related to PotPlayer. When I click save, the file size changes on TagEditor [File Selection] window. However, the physical file size does not change, and another file is save, the previous file changes back to original size on the list. Here's snapshot of original file list before saving:

Here's snapshot when I select TestCopy2 and click save:

Here's snapshot when I selected TestCopy3 and clicked [Open next file].

I thought it would update the list with correct size if I clicked the close button, but it didn't.

[Martchus]

That's the tree view within the Tag Editor GUI, right? And it is only a display issue? Then I'm already aware of it. I'm afraid it is almost certainly an upstream Qt bug but neither me or Qt devs took the effort to fix it yet. The bug should actually easy to work around at least but I never bothered.

[David-Maisonave]

Yes, it's within Tag Editor GUI.