Avidemux Forum

Quote from: mozbug on May 30, 2026, 08:11:22 PMAny particular reason why the executable module is named avidemux3 in the build avidemux2 directory?

The idea was probably to allow coexistence of Avidemux 2.6.x with legacy Avidemux 2.5.x applications where the Linux executable had "avidemux2" in its name back then, more than 15 years ago as Avidemux 2.6.x was created, long before I started to contribute to the project. Avidemux 2.8.x continues the 2.6 line, 2.5 was a very different application under the hood.

I can confirm building avidemux from the updated source on both Ubuntu 2604 and Linux Mint 22.3 correctly opens and handles .ts and .m2t files. Nice work quick fix!

Any particular reason why the executable module is named avidemux3 in the build avidemux2 directory? Big changes coming needed a version upgrade?

Thanks again. This problem is closed. (and I will delete my linked files)

Quote from: mozbug on May 29, 2026, 05:44:45 PMchanging Index Files to Enable did not work for me - same error.

Correct, my first cursory assessment of the effects of that typo (and one leftover I missed back then) was incomplete.

Quote from: mozbug on May 29, 2026, 05:44:45 PMI will patiently wait for the next Nightly and will report when I test that one.

I would very much recommend not to depend on anyone to provide binaries as building Avidemux from source on Linux is very easy (on Ubuntu 26.04, just please install qt6-base-private-dev package manually, it had been added to build requirements recently, but not yet to the convenience script createDebFromSourceUbuntu.bash).

Thank you for your report.

Yes, the files are on a system with write access, but changing Index Files to Enable did not work for me - same error. I will patiently wait for the next Nightly and will report when I test that one. Thank you for your help!

Typo of doom fixed, please build from source off the latest git master or wait for a future nightly, my apologies for the inconvenience.

Oops, if the files are located on a filesystem with write access, please switch indexing mode for MPEG-TS in the Preferences -> "Import" tab -> "Index files" to "Enable". In-memory indexing just for MPEG-TS with MPEG2 video must have got broken by demuxers/MpegTS: obey indexing preferences, remove a few redundant std::string ctors, reorder tsHeader class members for legibility. Will try to look into this regression ASAP.

Regular x86_64 and legacy x86_64 AppImages from 20260414 through the current 20260516 fail on open of recorded TV files .ts and .m2t. Regular AppImages were tested on Ubuntu 2604. Legacy AppImages were tested on Linux Mint 22.3 (Ubuntu 2404 base).

I have been recording television programs for years on my Hauppauge HVR2255 (creates .ts) and Hauppauge WinTV-quadHD (creates .m2t). AppImage 20260411 is the last to successfully open these files.

I can provide a sample 1 minute recorded TV file and a terminal log of the failure on my website, but it is 100% reproducible ... what else do you need?

https://sanfransysco.com/pub/avidemux/test_20260524_2107.m2t 95MB
https://sanfransysco.com/pub/avidemux/avidemux_terminal_log 47kB

You cannot view this attachment.
You cannot view this attachment.

Worked for me on my MacBook Air M5 16GB, Tahoe 26.5
Very simple and straightforward.
Thank you very much!!

thanks too, this was interesting to know .

Does Avidemux log these kinds of "EXCEPTION_ACCESS_VIOLATION" errors anywhere? I had a series of them before I finally figured out the culprit(s) and the fix(es), but I did not think to make a note of the details of the Error for future reference.
Any chance they got logged somewhere?