fontEngine.log does not respect custom log path (1 Viewer)


Portal Pro
October 7, 2008
Home Country
United States of America United States of America
TV-Server Version:
MediaPortal Version: 1.0.1 SVN
MediaPortal Skin: Streamed MP Beta
Windows Version: WinXP SP3
CPU Type: Intel E6600 Core 2 Duo
HDD: 500GB Western Digital
Memory: 2GB Corsair 5400C4
Motherboard: Intel DG965OT
Video Card: Asus 8600GT Silent
Video Card Driver: Latest Nvidia Reference Drivers
Sound Card: Intel HD
Sound Card AC3: Optical Out
Sound Card Driver:
1. TV Card:
1. TV Card Type:
1. TV Card Driver:
2. TV Card:
2. TV Card Type:
2. TV Card Driver:
3. TV Card:
3. TV Card Type:
3. TV Card Driver:
4. TV Card:
4. TV Card Type:
4. TV Card Driver:
MPEG2 Video Codec: ffdshow (Latest Beta)
MPEG2 Audio Codec: ffdshow (Latest Beta)
h.264 Video Codec:
Satelite/CableTV Provider:
HTPC Case: Antec Fusion
Power Supply: Antec 550W
Remote: Harmony One
TV: Sony Bravia 46X2000
TV - HTPC Connection: HDMI

1. Set a custom path for the Logs directory in MediaPortalDirs.xml e.g. c:\logs
2. Start MediaPortal

Result: All logs except for fontEngine.log are created in custom path

Reposted from

This problem persists in 1.0.1.

For people that use 'Log' folder redirection, please make sure you do NOT delete the original 'Log' folder from the default location (C:\ProgramData\Team MediaPortal\MediaPortal\). If you do, you may get a random "MediaPortal has stopped working" crash when using MediaPortal, most often in TVSeries plugin when you constantly browsing through the series. In Windows Event Viewer, you will see an error caused by fontengine.dll.

Once the 'Log' folder is recreated and FontEngine.dll can write the FontEngine.log file, the error goes away.



Retired Team Member
  • Premium Supporter
  • January 7, 2005
    True issue indeed. C++ side code doesn't have any way (currently) to parse the XML files for logging path information. This affects as well all the directshow filters.

    Non-proper way to fix this is just to make sure that fontEngine.dll is not crashing when the logging path is not available. Better way to fix this would be to allow C# side to provide the logging path for the C++ components. Anyone interested to provide a proper patch? I'm too lazy to fix the issue properly as it requires some work with no real benefits to myself :p

    Users who are viewing this thread

    Top Bottom