1.12.0 Redirected log path: some files created in standard path (4 Viewers)

[Owlsroost]

This is what the C++ code looks like:

LONG LogWriteRegistryKeyString(HKEY hKey, LPCTSTR& lpSubKey, LPCTSTR& data)
{
  LONG result = RegSetValueEx(hKey, lpSubKey, 0, REG_SZ, (LPBYTE)data, _tcslen(data) * sizeof(TCHAR));

  return result;
}

LONG LogReadRegistryKeyString(HKEY hKey, LPCTSTR& lpSubKey, LPCTSTR& data)
{
  DWORD dwSize = MAX_PATH * sizeof(TCHAR);
  DWORD dwType = REG_SZ;
  LONG result = RegQueryValueEx(hKey, lpSubKey, NULL, &dwType, (PBYTE)data, &dwSize);

  if (result != ERROR_SUCCESS)
  {
    if (result == ERROR_FILE_NOT_FOUND)
    {
      //create default value
      result = LogWriteRegistryKeyString(hKey, lpSubKey, data);
    }
  }

  return result;
}

void LogPath(TCHAR* dest, TCHAR* name)
{
  CAutoLock lock(&m_logFileLock);
  HKEY hKey;
  //Try to read logging folder path from registry
  LONG result = RegCreateKeyEx(HKEY_CURRENT_USER, _T("Software\\Team MediaPortal\\Client Common"), 0, NULL,
                                    REG_OPTION_NON_VOLATILE, KEY_ALL_ACCESS, NULL, &hKey, NULL);                                
  if (result == ERROR_SUCCESS)
  {
    //Get default log folder path
    TCHAR folder[MAX_PATH];
    SHGetSpecialFolderPath(NULL,folder,CSIDL_COMMON_APPDATA,FALSE);
    TCHAR logFolder[MAX_PATH];
    _stprintf(logFolder, _T("%s\\Team Mediaportal\\MediaPortal\\log"), folder);

    //Read log folder path from registry (or write default path into registry if key doesn't exist)
    LPCTSTR logFolderC = logFolder; 
    LPCTSTR logFolderPath = _T("LogFolderPath");
    result = LogReadRegistryKeyString(hKey, logFolderPath, logFolderC);
 
    if (result == ERROR_SUCCESS)
    {
      //Get full log file path
      _stprintf(dest, _T("%s\\TsReader.%s"), logFolderC, name);
    }
  }
 
  if (result != ERROR_SUCCESS)
  {
    //Fall back to default log folder path
    TCHAR folder[MAX_PATH];
    SHGetSpecialFolderPath(NULL,folder,CSIDL_COMMON_APPDATA,FALSE);
    //Get full log file path
    _stprintf(dest, _T("%s\\Team Mediaportal\\MediaPortal\\log\\TsReader.%s"), folder, name);
  }
}

Basically it calls 'RegCreateKeyEx' to find out if the key 'HKEY_CURRENT_USER\Software\Team MediaPortal\Client Common' exists and create it if it doesn't.

Then it calls 'RegQueryValueEx' to get the 'LogFolderPath' value - if that value doesn't exist it creates it using 'RegSetValueEx' (with the default path value).

So I guess doing something similar on the C# should work, except that since MP is going to be the 'master' here, it can just overwrite the 'LogFolderPath' value with whatever is in MediaPortalDirs.xml each time (on MP startup ?)

(Ignoring the problem of accessing the registry from .NET of course - http://stackoverflow.com/questions/1470770/accessing-the-windows-registry-using-net )

 

[regeszter]

Can the watchdog.exe use any non default log source path?

 

[Sebastiii]

Can the watchdog.exe use any non default log source path?

That a good question that's need to be tested or maybe already written in wiki

 

[morpheus_xx]

Just found this thread. We already have a different solution for dealing with config/log folders for DirectShow filters, which doesn't depend on registry, but a config next to the filter. It was implemented by @FreakyJ for some (if not all?) TVE related filters.

The reason to avoid registry was, that the filter can be used in both MP1 and MP2. MP2 loads it from filename and doesn't require registration. Avoiding registry entries also avoids conflicts between different configuration for MP1 and MP2. So I suggest to look at the solution, it's maybe not 100% complete, but works very well already. @FreakyJ can you point to the commit for the changes, please?

 

[FreakyJ]

can you point to the commit for the changes, please?

Sure
https://github.com/MediaPortal/MediaPortal-1/tree/EXP-TVE3.5-MP1-MP2_FilterSettingsmanager

 

[HTPCSourcer]

Can the watchdog.exe use any non default log source path?

Yes. Option 3 correctly pulls the client logs from the redirected path.

 

[HTPCSourcer]

Regarding restart.vbs, if I read this code correctly then the logpath definition should be replaced by the respective "Skin" information from mediaportaldirs.xml

Set Shell         = CreateObject("WScript.Shell")
Set Shell2        = CreateObject("Shell.Application")
Set objFolder     = Shell2.Namespace(ssfCOMMONAPPDATA)
Set objFolderItem = objFolder.Self

logpath           = objFolderItem.Path & "\Team MediaPortal\MediaPortal\log\"
lognew            = logpath + "\" + Wscript.ScriptName + ".log"
logold            = logpath + "\" + Wscript.ScriptName + ".bak"

Any other change required? If not, I will start making my first steps towards Powershell processing of XML files...

 

[regeszter]

Any other change required? If not, I will start making my first steps towards Powershell processing of XML files...

Do not forget that this file is in Program Files\Team MediaPortal, and it needs elevated rights to change any files in that directory.

If you have any c# skill, you may try to create a section in the configure.exe to changing the log directories (a GUI for the mediaportaldirs.xml).

 

[HTPCSourcer]

Do not forget that this file is in Program Files\Team MediaPortal, and it needs elevated rights to change any files in that directory.

I think there is a misunderstanding. I don't plan to change any files in the protected path but I would just redirect the output that the script creates when triggered by the Watchdog.

I would check for the existence of mediaportaldirs.xml in the user's local "Documents/Team MediaPortal" directory, and if there read the path in the xml to define "logpath" in the vbs script.

If you have any c# skill

Not specially, nothing but general knowledge of several languages

 

[HTPCSourcer]

One other thing that I noticed is that MediaPortal will crash if the skin folder is not immediately available after resume.

The server is running LightsOut and a resuming client will also wake the server from its standby state. Depending on how long this lasts, MP will not find the redirected skin folder and "folds". Interestingly, shared paths such as music and pictures are no problem as there seems to be in-built logic to just discard those unavailable shares.

ONe can of course delay the MP startup after resume but it would be more elegant to wait for the remote path to become available.