Followup of https://github.com/kaixxx/noScribe/issues/105 now with NoScribe 0.6

[phb911]

Kaixxx,
The new version 0.6 indeed reduces the time it needs to process my reference file from 30min down to 4min30sec. Great.
Thank you. However there is always an aber.
If I right click the window title and lock it to "move window" the file will be done within 1min40sec.
So, there is still room for improvments available, if you sit idle at your desk and desperately need something to work on.

best regards and thank you for maintaining noScribe.

[kaixxx]

Thank you for testing. This is driving me crazy. I thought that we had found the culprit, the now removed progress bar.
Last time, I was able to reproduce the issue to some extent on my own system. But now, I see no difference. I think it must be related to CUDA (which I cannot test on my machine).

Can you run noScribe from source and perform some tests?
First thing to try would be if it has to do with the logging on screen. Go to line 787 in noScribe.py and add a return as the first line of the log function:

    def log(self, txt: str = '', tags: list = [], where: str = 'both', link: str = '') -> None:
        """ Log to main window (where can be 'screen', 'file', or 'both') """
        return # <-- add this here

This will disable any screen messages.

---

For reference, the previous issue: #105

[phb911]

Hi Kai,
It took a little while to build a system where I can use the Nvidia card concurrently with multiple virtual machines using paravirtualization - I have only on card and noScribe has to be available for the users. But this is working now nicely.

If I just run noScribe 0.6 from the source time will be: 2:46 (downloaded yesterday)
If I add your suggested change the time will be 2:10
If I add your change and do the right click on the window and then select the move option time will be 1:25
I then did again a run of the ready-to run noscribe release with the same file, still 4:30
Again with the "trick" with the move window: 1:44
Those two VMs differ a little: the one where I run the noScribe release is windows 22H2 (client)
The one where I did run noScript from source is 21H2 (windows Server)
I would think this should not make a difference, but this is of course only a guess.

I have not timed the time for diarization seperately. I will do this next.
Anyway, the version 0.6 is still a big improvement regarding this special problem.

[kaixxx]

User @Evenzotesten made in interesting video showcasing what happens (source: #133 (comment)). He triggers the behavior by clicking "cancel" and leaving the following message box unanswered, which leads to a significant speed increase:

cancelbuttonfastercuda.mp4

The video shows that the curve for cuda usage flattens out after the cancel message box is opened. Before, the cuda usage was jumping up and down all the time. I think the more continuous, uninterrupted cuda usage is the cause for the speed increase.

[kaixxx]

@phb911 Thank you for all the testing. Let's concentrate on the differences between running noScribe from source with and without the right click on the window and then selecting the move option.
It's obviously not the logging on screen which causes the lag, the difference in your test is marginal. You can revert my suggested change in the log function.

Next thing to test: I run the complete transcription process in a background thread so that the user interface does not freeze during the process. I am wondering if this has an influence on how cuda is used.

You can test the following. Please go to around line 1627 in noScribe.py and change the button_start_event like so (adding the first two lines):

    def button_start_event(self):
        self.transcription_worker()
        return
        
        wkr = Thread(target=self.transcription_worker)
        wkr.start()
        while wkr.is_alive():
            self.update()
            time.sleep(0.1)

This will run the transcription process not in the background. The problem will be, that the app seems to freeze until the transcription is finished. Just wait, and the screen will finally be updated again. Try it without your trick with the 'move window' and see what time you can achieve. Thank's a lot!

[phb911]

with this modfication it takes 1:37

[kaixxx]

with this modfication it takes 1:37

Interesting. This is very close to the 1:25 you got before. It seems that the background thread might be the issue here. Now, I have to find a different way to keep the user interface responsive. I have no idea yet. I will come back to you if I have something to test. Thank you for all your help with this issue.

[gernophil]

I wonder, if this could be circumvented by using a different GUI framework. Isn't there a possibility to spawn the process in foreground without freezing the main window? Like on a different core?

[kaixxx]

Maybe we have a simple solution. @phb911, could you please test this version of the button_start_event? It's the original version, but the last three lines are commented out (not executed) by adding a # in front.

    def button_start_event(self):        
        wkr = Thread(target=self.transcription_worker)
        wkr.start()
        # while wkr.is_alive():
        #    self.update()
        #    time.sleep(0.1) 

Background information: I don't remember exactly, but it seems that I've added this while loop to update the screen while the transcription is running. But looking at this now, it seems totally unnecessary since the transcription is running in a background thread anyway. Let's see if this solves the interrupted cuda process that we can see in the video above.

[phb911]

I dont know if this helps, but I tried what happens, if I run a tail program which displays the log from localappdata/noscribe.
It works without slowing down the operation.

[phb911]

Yes!
def button_start_event(self):
wkr = Thread(target=self.transcription_worker)
wkr.start()
# while wkr.is_alive():
# self.update()
# time.sleep(0.1)

This fixes the slowdown. 1:34

[kaixxx]

Yes!

Ah, finally. What a stupid thing I did there back in the day. Don't know what I was thinking...

Anyhow, I will update the cuda installer and probably also generate a new version number so that people get notified about the update.

[Lod3]

Thank you, I will wait for the new version I have a couple of long material I wanted to transcribe :)