A few Queue problems/bugs

[Bearbear]

the timestamp in the job name, provided by ADM_getTimeDateAsString() is returned as UNKNOWN which means that something is wrong either with ADM_getSecondsSinceEpoch(), with localtime() or with strftime().

The current download for Avidemux 2.7.5 Final 64 bits (MD5: 56110c8050ec01c8690567830240e290) does not have this problem, so there's some sort of magical code there that works. All other current nightlies (avidemux_2.7.5 r191003_win32, avidemux_2.7.5 r191003_win64.exe, avidemux_r191003_win64Qt5_65) and the 2.7.4 32 bits version on Fosshub however, does have this timestamp bug.

Should be fixed now by commits

Thanks again for all the hard work, I very much appreciate it!

[eumagga0x2a]

Just to clarify: I haven't tried to investigate the timestamp issue because I don't have access to the necessary build env at the moment. The issue is limited to MinGW builds, maybe even only to official MinGW builds, the VC++ builds like the official release build use a different code path and are not affected.

[Bearbear]

I see, thanks for the clarification.

Could I also ask if the problem found in this topic with Avidemux not appearing in the "Open With" context menu when using the VC++ builds can be fixed or not (other than using MinGW builds which have a NSIS installer) or is it just an inherent problem with the installer?

Apologies for all the requests

[eumagga0x2a]

A fresh 64 bits MinGW nightly (191005) has been uploaded --> https://avidemux.org/nightly/win64/

Can't help with the "Open With" annoyance, I'm sorry.

[Bearbear]

That's great, thanks ever so much, I really do appreciate it!

From some quick tests, the new nightly build works great and for some reason only 2 progress dialogs appear, so that's something I guess?

Also not to worry about the Open With issue, it's relatively minor and as a workaround I add a shortcut to Avidemux in Windows' SendTo folder (C:\Users\[username]\AppData\Roaming\Microsoft\Windows\SendTo) which gives virtually the same functionality as the Open With menu (see attachment).

May I ask another question, I'm not sure if this is intended functionality or not, but the .py jobs that are created (in \AppData\Roaming\avidemux\jobs) and added to the queue, do they ever get automatically deleted? The "Cleanup" button or right click > Delete on a job in the Avidemux Jobs window doesn't seem to delete the .py files.

[eumagga0x2a]

for some reason only 2 progress dialogs appear, so that's something I guess?

Do you get this only with number of jobs being greater than one?

I'll try to reproduce later, for now just a purely theoretical polishing action with [Qt/jobs] Open progress dialog only once there are jobs to run, check that it has not yet been created when trying to run a job from context menu to reduce dialog resizing and to avoid a possible crash when trying to use "Run now" context menu item while other jobs are running.

Please provide a new jobslog.txt from such a multiple progress dialog run.

I'm not sure if this is intended functionality or not, but the .py jobs that are created (in \AppData\Roaming\avidemux\jobs) and added to the queue, do they ever get automatically deleted?

No, it is up to the user to remove them manually. This is a known feature / limitation / shortcoming of the existing implementation.

[Bearbear]

Do you get this only with number of jobs being greater than one?

No, 2 progress dialogs appear even if I only run 1 job. I've tried testing 1, 2, 3 jobs, encoding to x265/mkv, to x264/mp4 and to xvid4/avi, and it always produces 2 progress dialogs.

Edit:- One thing I have noticed however, if I right click > "Run Now" on a job in the job queue, only 1 progress dialog appears, so the problem is specifically to do with the "Run jobs" button itself.

Please provide a new jobslog.txt from such a multiple progress dialog run.

I've attached jobslog.txt (and screenshots) from doing only 1 job and 3 jobs via the Run jobs button.

No, it is up to the user to remove them manually. This is a known feature / limitation / shortcoming of the existing implementation.

I suspected as much and again, it's only a minor quibble

[eumagga0x2a]

Thank you, I've just tried it with the latest nightly (i.e. without the last patch) and can confirm the puzzling behavior on Windows (puzzling because even with the last patch reverted, I don't get two progress dialogs created on macOS when clicking on "Run jobs").

[Bearbear]

I've tried testing a single job in the queue and continuously doing a cycle of clicking Run jobs, letting it finish, forcing it to ready and clicking Run jobs again. It seems every few tries or so I do get 1 progress dialog, but often it's still 2, as seen in this video: https://streamable.com/tkdmi

I have yet to deduce why this is, I thought it was the speed between when I hovered over the Run job and the actual mouse click at first, or maybe there's a lingering CLI process or connection in the background, but honestly it seems completely random.

I've attached a jobslog.txt if that helps.

[eumagga0x2a]

Thank you, so this should be some race condition. Let's wait until there is a new nightly which includes the patch which moved the open() call out of the progress dialog constructor.

[eumagga0x2a]

A fresh MinGW nightly (191006) has been uploaded to https://avidemux.org/nightly/win64/, the issue with multiple progress dialogs seems to be fixed.

[Bearbear]

It certainly does look like the problem has been fully resolved, I sound like a broken record, but thanks again!

I guess the only remaining thing is the jobs timestamp issue with MinGW builds, but as you said earlier you don't have the build environment to debug, plus I can always wait for the next VC++ stable.

[Bearbear]

I've run into a new problem with the Queue, I believe it's tied with problematic video files that give the question "This video contains B-frames, but presentation time stamps (PTS) are either missing or monotonically increasing. Avidemux can try to reconstruct correct PTS by decoding the entire video. This may take a lot of time. Proceed?" when opening in Avidemux.

I select "No" as it pops up in Avidemux, edit and then add the file to the Queue. However whilst running the job from the Queue, it always silently selects "Yes". I think this causes a discrepancy between the times it is looking for and the adm.addSegment times that are listed in the .py job file.

I'm not 100% sure that's the reason why the job is failing, but that's my deduction anyway.

I've attached the jobslog.txt and here's cmd.exe Avidemux CLI output when running the same .py job manually without the slave option (too big for attachment):

https://paste.ee/p/moNuI

Would it be possible for the Queue to honour whatever answer you chose for the initial question and parse that rather than always defaulting to Yes?

[eumagga0x2a]

The only operation which has a chance to succeed without reconstructing the right display order and thus PTS of all frames is plainly re-encoding the entire video, so if you want to edit it, you MUST let the reconstruction complete.

The internal way to perform the task should be improved (we don't need to decode macroblocks, just parsing the slice headers would be enough, but all we have just now is a hammer, so everything must be a nail), this is true, of course.

[Bearbear]

Sorry maybe I'm not following, but if I load the same problematic .py job (see attachment) with the GUI, select "No" to the aforementioned question, and save through there (as opposed to using the Queue), the video saves fine. There doesn't seem to be a need for reconstructing the correct PTS, in my case at least.

To clarify, by editing I mean I cut portions out, sometimes scale down to 720p, re-encode the video to HEVC in a mkv container, but leave the audio to Copy.