Author Topic: Logfile stored in romaing part of the profile instead of the local part  (Read 3611 times)

achim71

  • Newbie
  • *
  • Posts: 8
Hi,

In my network i store the roaming part of the profile (%AppData%) on the server. Avidemux writes it's logfile to %AppData%\avidemux\admlog.txt and if that file is placed on the server this causes log delays when moving the slider on the timeline. This works fluent if %AppData% resides on an local drive.
Wouldn't %TEMP% or %LocalAppData% whom both reside on an local drive be an better place for the logfile?
Is it possible to disable the logging or pass an different path via command line?

Thanks in advance,
Achim~

mean

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 10974
LocalAppData seems a good idea

achim71

  • Newbie
  • *
  • Posts: 8
Got the cross compiler env working on debian jessie (the qttools mxe package is also required but not mentioned in cross-compiling.txt btw.). Wrote an patch to use LocalAppDir for the admlog.txt file while keeping all config files in AppDir. Works here and using the slider now works fluent with AppData redirected to the server.
« Last Edit: May 06, 2017, 12:28:33 AM by achim71 »

mean

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 10974
applied, thanks !

eumagga0x2a

  • Moderator
  • Hero Member
  • *****
  • Posts: 3672
the qttools mxe package is also required but not mentioned in cross-compiling.txt btw.

At the time of writing qttools package was pulled in by qtwinextras. Wilk recheck and update. Thanks!

achim71

  • Newbie
  • *
  • Posts: 8
Thanks for integrating the patch so quick.  :)

During mxe compilation an error occured witrh the icu4c package. This was fixable with the patch mentioned here https://gist.github.com/starius/8f8693ee4761ed40ffc4

AQUAR

  • Hero Member
  • *****
  • Posts: 1080
I think the OP is the first avidemux user with this roaming program data type issue.
The fix means that, for everyone else, the avidemux specific program data is now spread across two APPDATA folders instead of staying consolidated in the one folder.





eumagga0x2a

  • Moderator
  • Hero Member
  • *****
  • Posts: 3672
the qttools mxe package is also required but not mentioned in cross-compiling.txt btw.

At the time of writing qttools package was pulled in by qtwinextras.

No, I was wrong. I simply didn't have qttools installed in my MXE, i.e. lrelease from the host system got used (without a hitch), so I didn't notice that something was amiss.

eumagga0x2a

  • Moderator
  • Hero Member
  • *****
  • Posts: 3672
During mxe compilation an error occured witrh the icu4c package. This was fixable with the patch mentioned here https://gist.github.com/starius/8f8693ee4761ed40ffc4

This is not needed on Fedora as the host system.

achim71

  • Newbie
  • *
  • Posts: 8
I think the OP is the first avidemux user with this roaming program data type issue.
The fix means that, for everyone else, the avidemux specific program data is now spread across two APPDATA folders instead of staying consolidated in the one folder.
Only the admlog.txt file is now stored on the the local part for the profile and it can be opened  via the avidemux gui so no need to search. Everything else remains in the roaming part With the log on a n network share it takes an long time to open avidemux and afterwards scrolling in the timeline works in ~1 second steps. I guess if you run avidemux portable (rename aviudemux.exe to avidemux_protable.exe) from an network share you can easiy test what i mean.

eumagga0x2a

  • Moderator
  • Hero Member
  • *****
  • Posts: 3672
While the log file itself can be directly opened from the "Help" menu, the folder which contains the file can't be accessed that easily. This is a valid point IMHO.

I'd suggest copying the log file from the local directory to the roaming one and adding timestamp to the file name when a user tries to access the avidemux data folder from the "Help" menu.

achim71

  • Newbie
  • *
  • Posts: 8
It is not unusual under windows to use different locations for profile related data. Usually appdata (%APPDATA%) is used for user specific things and local appdata (%LOCALAPPDATA%) for machine specific files. Logfiles usually are written to the temp folder in local appdata (%TEMP%).
Looking at the local appdata subfolders here it is mainly used for caches but there are alot of application specific logfiles in the %TEMP% folder.
Using %LOCALAPPDATA% or even better %TEMP% for the logfile makes avidemux more windows conform and it thereby improves usabilty with network stored appdata.


eumagga0x2a

  • Moderator
  • Hero Member
  • *****
  • Posts: 3672
We need to have an easy access to log files, not just to the content of log files to provide support and to identify bugs. No matter where the log resides, users should be able to access this location directly to provide the file on request.

achim71

  • Newbie
  • *
  • Posts: 8
During mxe compilation an error occured witrh the icu4c package. This was fixable with the patch mentioned here https://gist.github.com/starius/8f8693ee4761ed40ffc4

This is not needed on Fedora as the host system.
Removed the patch and tried again and it worked here also. Afterwars i pulled mxe again from git and ran make icu4c and it also worked. This is strange looking at my aptitude.log i only installed the xmlto package afterwards.

achim71

  • Newbie
  • *
  • Posts: 8
We need to have an easy access to log files, not just to the content of log files to provide support and to identify bugs. No matter where the log resides, users should be able to access this location directly to provide the file on request.
I see. Modified the patch abit added a few ifdef __WIN32's to avidemux/qt4/ADM_userInterfaces/ui_support.cpp because the ADM_getLogDir function does only exist for the windows build and will therefore cause an error during build on other platforms. For win32 if baseDir and logDir are different, now admlog.txt get's copied from logDir to baseDir. I did not yet append an timestamp to the copied file.