CPU load when deleting physically folder mapped as library
CPU load when deleting physically folder mapped as library
Hi Bernd.
When PF is running and I make physical changes to folder based libraries through windows explorer (like clearing one folder and deleting it) PF suddenly starts to consume around 90-95% of CPU. I understand it could cause a problem if I delete physically folder which is mapped as library but anyway, if this is a bug, could you have a look at it?
Thank you.
When PF is running and I make physical changes to folder based libraries through windows explorer (like clearing one folder and deleting it) PF suddenly starts to consume around 90-95% of CPU. I understand it could cause a problem if I delete physically folder which is mapped as library but anyway, if this is a bug, could you have a look at it?
Thank you.
Peter
Re: CPU load when deleting physically folder mapped as libra
So the workaround would be:
1. move tracks from that directory to another desired
2. after folder is empty delete this library from libraries (in settings)
3. delete folder physically
Right?
1. move tracks from that directory to another desired
2. after folder is empty delete this library from libraries (in settings)
3. delete folder physically
Right?
Peter
Re: CPU load when deleting physically folder mapped as libra
Yes, or more simple:
Turn off the 'Auto Watch' option for the moment you are doing such heavy delete/rename/copy folder operations on your folder-based media lib...
and when done perform a 'Rescan' for that media lib and turn 'Auto Watch' back on again.
Turn off the 'Auto Watch' option for the moment you are doing such heavy delete/rename/copy folder operations on your folder-based media lib...
and when done perform a 'Rescan' for that media lib and turn 'Auto Watch' back on again.
Bernd - radio42
ProppFrexx ONAIR - The Playout and Broadcast Automation Solution
ProppFrexx ONAIR - The Playout and Broadcast Automation Solution
Re: CPU load when deleting physically folder mapped as libra
Sounds like this is NOT a bug, but rather a feature you have selected within ProppFrexx.
I assume you have the 'Auto Watch' option selected with such folder based media library.
In such case the Windows operating system reports all changes to that 'monitored' folder (incl. all changes to any sub-folder or files within any sub-folder) to ProppFrexx.
This in order to let ProppFrexx know about these changes and make appropriate changes directly within its related media library.
As outlines in the docs, this is might be (depending on your changes and your underlying hardware) a quite heavy operation (both from an I/O as well as an CPU point of view - note that heavy I/O operations also use CPU resources).
So I guess what you are observing is just this.
I assume you have the 'Auto Watch' option selected with such folder based media library.
In such case the Windows operating system reports all changes to that 'monitored' folder (incl. all changes to any sub-folder or files within any sub-folder) to ProppFrexx.
This in order to let ProppFrexx know about these changes and make appropriate changes directly within its related media library.
As outlines in the docs, this is might be (depending on your changes and your underlying hardware) a quite heavy operation (both from an I/O as well as an CPU point of view - note that heavy I/O operations also use CPU resources).
So I guess what you are observing is just this.
Bernd - radio42
ProppFrexx ONAIR - The Playout and Broadcast Automation Solution
ProppFrexx ONAIR - The Playout and Broadcast Automation Solution