Author Topic: A few Queue problems/bugs  (Read 976 times)

Bearbear

  • Newbie
  • *
  • Posts: 15
Re: A few Queue problems/bugs
« Reply #15 on: October 05, 2019, 09:16:27 AM »
Quote from: eumagga0x2a
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.

Quote from: eumagga0x2a
Should be fixed now by commits
Thanks again for all the hard work, I very much appreciate it!
« Last Edit: October 05, 2019, 09:19:34 AM by Bearbear »

eumagga0x2a

  • Moderator
  • Hero Member
  • *****
  • Posts: 3389
Re: A few Queue problems/bugs
« Reply #16 on: October 05, 2019, 09:27:55 AM »
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

  • Newbie
  • *
  • Posts: 15
Re: A few Queue problems/bugs
« Reply #17 on: October 05, 2019, 09:40:56 AM »
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

  • Moderator
  • Hero Member
  • *****
  • Posts: 3389
Re: A few Queue problems/bugs
« Reply #18 on: October 05, 2019, 09:45:07 AM »
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

  • Newbie
  • *
  • Posts: 15
Re: A few Queue problems/bugs
« Reply #19 on: October 05, 2019, 04:53:13 PM »
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.
« Last Edit: October 05, 2019, 05:00:57 PM by Bearbear »

eumagga0x2a

  • Moderator
  • Hero Member
  • *****
  • Posts: 3389
Re: A few Queue problems/bugs
« Reply #20 on: October 05, 2019, 07:35:47 PM »
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.

Quote
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

  • Newbie
  • *
  • Posts: 15
Re: A few Queue problems/bugs
« Reply #21 on: October 06, 2019, 11:54:33 AM »
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.

Quote from: eumagga0x2a
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.

Quote from: eumagga0x2a
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 :)
« Last Edit: October 06, 2019, 12:09:15 PM by Bearbear »

eumagga0x2a

  • Moderator
  • Hero Member
  • *****
  • Posts: 3389
Re: A few Queue problems/bugs
« Reply #22 on: October 06, 2019, 12:28:59 PM »
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

  • Newbie
  • *
  • Posts: 15
Re: A few Queue problems/bugs
« Reply #23 on: October 06, 2019, 01:13:44 PM »
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.
« Last Edit: October 06, 2019, 01:19:04 PM by Bearbear »

eumagga0x2a

  • Moderator
  • Hero Member
  • *****
  • Posts: 3389
Re: A few Queue problems/bugs
« Reply #24 on: October 06, 2019, 02:18:34 PM »
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

  • Moderator
  • Hero Member
  • *****
  • Posts: 3389
Re: A few Queue problems/bugs
« Reply #25 on: October 06, 2019, 02:55:14 PM »
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

  • Newbie
  • *
  • Posts: 15
Re: A few Queue problems/bugs
« Reply #26 on: October 06, 2019, 04:23:58 PM »
It certainly does look like the problem has been fully resolved, I sound like a broken record, but thanks again! ;D

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

  • Newbie
  • *
  • Posts: 15
Re: A few Queue problems/bugs
« Reply #27 on: October 13, 2019, 10:20:27 PM »
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?
« Last Edit: October 13, 2019, 10:30:01 PM by Bearbear »

eumagga0x2a

  • Moderator
  • Hero Member
  • *****
  • Posts: 3389
Re: A few Queue problems/bugs
« Reply #28 on: October 13, 2019, 10:54:59 PM »
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

  • Newbie
  • *
  • Posts: 15
Re: A few Queue problems/bugs
« Reply #29 on: October 13, 2019, 11:00:30 PM »
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.
« Last Edit: October 13, 2019, 11:24:37 PM by Bearbear »