GUI becomes unresponsive when loading files over a network

[DragonQ]

For some reason the GUI becomes unresponsive (the GUI dims and the standard Windows title bar appears at the top of the window) when you try to load a file over the network. The program still works perfectly fine if you wait and let it finish, but I guess Windows assumes the program has crashed because it's taking longer than usual (due to having to load the file over the network rather than from a local HDD).

Mainly cosmetic issue but some inpatient people might assume the program has crashed and doesn't support reading files over networks. Maybe the GUI thread isn't properly separated from the background process (i.e. reading and analysing the file) or something?

[Cypheros]

I will test this with slower networks. I have no issues with Gbit lan and Linux fileservers.

[DragonQ]

I get this every time when using a file on my HTPC (100 Mbps). I sometimes get it when using a file on my Linux server too (1 Gbps). I guess it's more likely to happen with larger files, like HD recordings. PCR check is usually the first step where I see it.

[klabauter]

I have noticed something like this happening on my system, too. The program window dims and says "keine Rückmeldung"/"not responding" in the title bar during PCR-Check, but then continues normally. I´m not using TS-Doctor over a network, but mainly use USB-Drives. I first noticed this a few betas ago, I don´t think i had this with 1.2.29. I will have to check if this happens with my local HDD.

OK, i have just tried a file on my local HDD, GUI said "not responding" for a few seconds during PCR-Check. But it seems like the PCR-check just continues in the background, because when GUI becomes unresponsive, the progress bar has just moved for a few percent. When the GUI becomes responsive again the PCR-check finishes immediately, so something must have happened in between.

[Mam]

Network issues can be tricky, its almost impossible to set up a nearly identical environment, its not even likely that you can simulate the same situation again on the same network.

Anyway, you should begin to find out if things run smooth, fire up task manager, go to the network tab and copy over a large file from the server to your local hd. On 100Mbit lans the usage should be almost constant 100% during the copy. Gb Lan is usually too fast for your pc, you are lucky, if you can get 50-60%, but more important is the question, if it is steady.
Windows has the bad and evil feature to slow down automatically when a problem arises, but never really recover and speed up again afterwards.
And there are many many possible "problems". Dealing with video files, its most likely the RAM that limits the transfer. Even if you have a lot, TSDoc is still a 32bit program, limited to 2Gb memory space. You wont notice TSDoc ever using this amount, but during a copy, the filebuffers are silently assinged and bound to the calling process. And Windows wont ever use more than a process can handle.
So if you transfer a 10Gb file with windows explorer, you might see a strong beginning, but after a while there will be a hard slowdown and from then on, the transfers will zig-zag in intervals. The height of the peaks is somewhat interesting, you wont ever get as high, as at the beginning, but you should be able to go to 20-25% again.
If there are longer "dead line", aka "0 transfer" times, this could be either a problem with your local hard disk, or your server is too slow to serve the data in proper manners.

This kind of problems usually are NEVER bound to the application, you get the "hang" sign for your TSDoc because the 0-transmission times on your lan are too long. Watch it and find (and fix) the issue.

There is also not much the Programmer can do to avoid such situations, the programm is halted at kernel level, thats even below windows already. So the controlling threads on widows just see a stalled application and have no idea what is going on. Thinking bad, they overreact and ask you for killing it (which also would not work instantly in this situation).

I noticed that TSDoc is in some situations a real disk hog, strangely the scanning for ads/ac3 scan seems to take up more ressources than the final "create a new file" (I think because these are only reading at full speed and just process the data in memory, whereas the final stage includes writing to disk too which slows down the reading a bit)

Maybe someday TSDoc comes out as 64bit, this would help you a bit more because it then can use up to 3Gb buffer size. (yeah, evil M$ still does not open the RAM for normal application, you need to pay a lot of money to get more access).

[DragonQ]

When I drag & drop a large file into TS-Doctor, the ethernet utilisation in Task Manager rises steeply then is pretty steady at 25-30% utilisation (over 1 Gbps) until TS-Doctor is finished. TS-Doctor turns "non-responsive" very early on in this process (just after PCR check starts).

[Mam]

is pretty steady at 25-30% utilisation (over 1 Gbps)

Nono, you should copy the file with windows-explorer, not with TSDoc. TsDoc is processing the data and also rewinding the file several times for different stages. This does not allow any assumption about performance.
Just a simple explorer copy lan to disk please.

25-30% is too low for this, a well tuned system should go to 50% and more. And, depending on your RAM, it should stay there for a while then breaking down and zig-zagging (if the file is too small, you probably never reach the breakdown point).

[DragonQ]

Yes, with a simple file copy I get 45-50%. I can get more than this sometimes but my server is being used for some other stuff right now.