incomplete UHD conversion

[Trevbams]

I'm using the latest version of Fastflix to convert UHD file converted with makemkv using the default Fastflix settings, however regularly I find that the encode finishes early creating part of the movie with the Fastflix GUI window close but the CMD window still open but static at the last time it converted the video. I have had some success converting using medium speed but slow always seems to stop midway. I've checked the PC settings to ensure its not going to sleep or anything stupid.

[cdgriffith]

I have come across issues with the graphics library bindings (PySide2 for QT) where it will randomly segfault with no way for me to really identify what is going wrong or where the issue is happening.

For safety I would suggest copying the command to the command line and running it from there (will have to manually replace the path to ffmpeg and output name for now)

If you ever get an error message associated with this please send it my way so I can investigate this further. The long term (painful) answer may be the need to move away from QT, as it also has been causing issues with pyinstaller to make it into an exe.

[cdgriffith]

I have updated FastFlix to use qtpy as of 2.4.0, and built with PyQT5 for Windows by default instead of PySide2 now. It is also built with Python 3.8 instead of 3.6.

I do not know if this will fix that issue, so I am leaving this open, but if it was directly related to the issues I experienced with PySide2 it hopefully is fixed.

[Trevbams]

I'm afraid on the first copy it failed, again without any error message the Fastflix GUI window just closed and the CMD window stayed open but stopped any further processing. Previously this seemed to happen around the 53 mins mark of a film, regardless of how long it took to get there but on this occasion it was 31 min 55 secs of the film (I'm not sure how long it had been processing for).

[TGMais]

I had this happen on 2 runs recently.

The first one was on version 2.5.0 and happened about 50% of the way through a 2 hour long source material. The settings were HEVC/Slower/CRF-20 with an Tune set to animation. The command window continued to update for a while, but eventually that stopped as well. However, the encoding completed successfully in the background about 13 hours later.

The second one was on 2.6.0 and it happened very quickly - the last entry in the log is for frame 2287. Again the GUI crashed away, but this time the terminal stopped updating immediately. Settings for this one were HEVC/Slow/CRF-20. Again, the encode completed successfully in the background. flix_2020-09-11T01.44.28.252365.txt flix_2020-09-15T11.10.03.304207.txt

[cdgriffith]

I am currently working on a major UI overhaul for 3.0, and one of the things that is happening is decoupling the GUI (QT) and the background runner for the conversions, as well as logging.

It will hopefully make the GUI at lot more stable, but even if it does not, it ensures the current encoding process will still be completed properly before fully exiting the console (and not just disappearing in the background!)

I did a quick test conversion with current build just now to make sure HEVC seems to be working, but just be aware it's a work in progress. https://ci.appveyor.com/project/cdgriffith/fastflix/builds/35283829/artifacts

[TGMais]

I am currently working on a major UI overhaul for 3.0, and one of the things that is happening is decoupling the GUI (QT) and the background runner for the conversions, as well as logging.

It will hopefully make the GUI at lot more stable, but even if it does not, it ensures the current encoding process will still be completed properly before fully exiting the console (and not just disappearing in the background!)

I did a quick test conversion with current build just now to make sure HEVC seems to be working, but just be aware it's a work in progress. https://ci.appveyor.com/project/cdgriffith/fastflix/builds/35283829/artifacts

Looks great! The changelog is very substantial. I ran a quick test and forced the GUI to crash by entering a non-integer in one of the crop fields. The console handled it smoothly at first, but died eventually (though FFMPEG kept running in the background). If I have another UHD conversion to make before you release a stable version, I'll run this build and let you know how it goes.

2020-09-18 12:30:34 TODD-DESKTOP fastflix-core[20216] INFO frame= 6892 fps= 46 q=26.8 size= 240128kB time=00:04:48.10 bitrate=6827.8kbits/s speed=1.94x 2020-09-18 12:30:34 TODD-DESKTOP fastflix-core[20216] INFO frame= 6918 fps= 46 q=25.3 size= 240128kB time=00:04:49.12 bitrate=6803.6kbits/s speed=1.94x 2020-09-18 12:30:34 TODD-DESKTOP fastflix-core[20216] WARNING The GUI might have died, but I'm going to keep converting! 2020-09-18 12:30:35 TODD-DESKTOP fastflix-core[20216] INFO frame= 6940 fps= 46 q=24.3 size= 240128kB time=00:04:50.06 bitrate=6781.6kbits/s speed=1.94x 2020-09-18 12:30:35 TODD-DESKTOP fastflix-core[20216] INFO frame= 6957 fps= 46 q=26.2 size= 244736kB time=00:04:50.79 bitrate=6894.5kbits/s speed=1.93x 2020-09-18 12:30:36 TODD-DESKTOP fastflix-core[20216] INFO frame= 6975 fps= 46 q=26.7 size= 244736kB time=00:04:51.52 bitrate=6877.1kbits/s speed=1.93x 2020-09-18 12:30:36 TODD-DESKTOP fastflix-core[20216] INFO frame= 6994 fps= 46 q=23.9 size= 244736kB time=00:04:52.36 bitrate=6857.5kbits/s speed=1.93x 2020-09-18 12:30:37 TODD-DESKTOP fastflix-core[20216] INFO frame= 7012 fps= 46 q=24.5 size= 244736kB time=00:04:53.10 bitrate=6840.1kbits/s speed=1.93x 2020-09-18 12:30:37 TODD-DESKTOP fastflix-core[20216] INFO frame= 7026 fps= 46 q=26.9 size= 244736kB time=00:04:53.68 bitrate=6826.6kbits/s speed=1.93x 2020-09-18 12:30:38 TODD-DESKTOP fastflix-core[20216] INFO frame= 7040 fps= 46 q=23.7 size= 244736kB time=00:04:54.22 bitrate=6814.0kbits/s speed=1.92x 2020-09-18 12:30:38 TODD-DESKTOP fastflix-core[20216] INFO frame= 7058 fps= 46 q=23.7 size= 244736kB time=00:04:54.96 bitrate=6797.0kbits/s speed=1.92x

Console output stops here.

[cdgriffith]

The fact the console died and it kept running shouldn't really be possible in this release.... (I don't doubt it did, I'm just trying to puzzle together the "how")

If you check the flix_conversion*.log in the logs directory (open FastFlix -> Help Menu -> Open log directory) does it also stop at the same place?

[Trevbams]

interestingly I identified the same thing today using version 2.6. I had a conversion close the gui window whilst the cmd window remained open, however as before it stopped providing any updates. CPU usage was still very high so I left it to carry on until eventually stopping it and finding that despite the last confirmed timestamp of 1:04:00 the video had got to 1:40:00 so it had definitely continued to process in the background. I'll try and check the logs you mention above tomorrow.

(@TGMais in a strange way I'm glad its not just me who has had this, I was beginning to think it was my setup)

[cdgriffith]

@Trevbams thanks you for confirming you are having the issue as well. The logs probably won't show anything useful with 2.6, only if using the 3.0.0a build as a heads up. https://ci.appveyor.com/project/cdgriffith/fastflix/builds/35283829/artifacts

[cdgriffith]

@TGMais @Trevbams After thinking about this some more, I think this has to due with Python's handling of PIPEs for output (basically they get filled up). So I'm trying a new approach with latest build here: https://ci.appveyor.com/project/cdgriffith/fastflix/builds/35288139/artifacts

[cdgriffith]

I just did a 10 hour long convert on slow of a 2 hour video file, making sure it had a lot of output. Using the new version of 3.0 without issue. So I am optimistic these issues will go away in 3.0 😄

[cdgriffith]

Due to the new way the commands and no longer using memory PIPEs in 3.0.0 this should no longer be an issue! Please let me know if you see any other issues!

[Trevbams]

Due to the new way the commands and no longer using memory PIPEs in 3.0.0 this should no longer be an issue! Please let me know if you see any other issues!

Looks good so far, thank you and good work