Access violation at address .... wms.dat

[ajuga]

Allmost every day I find the following error dialog on the screen when I logon to my media server (running mediaportal and wms):

File:C:\Documents and Settings\All Users.WINDOWS\Application Data\Wild Media Server\wms.dat
Fout laden:Access violation at address 00405A04 in module 'wms.exe'. Read of address FFFFFFFA.
Load Back-up?

No entry to be found in the log book, so no clue as to what is the reason and at what time it occured.

Version 1.08.3 (and all versions before that)

Extra information (not sure if it's of any importance): The following script runs every 10 minutes because wms doesn't allways read the properties of all recordings. Yesterday I disabled the statement WmsDatabaseAutoSave in a desperate attempt to find the source of the problem. But this didn't make any difference.

Code: Select all

var
  i: Integer;
  AllVideoFolder: TWmsScriptMediaItem;
begin
  AllVideoFolder := WmsFindMediaFolder(mfVideoAllMoviesItemID);
  if (AllVideoFolder <> nil) then 
    for i := 0 to AllVideoFolder.ChildCount - 1 do
    begin
      if VarToStr(AllVideoFolder.ChildItems[i].Properties[mpiTimeLength]) > '1' then try
      AllVideoFolder.ChildItems[i].Properties[mpiTimeLength]:='01:00:00.000';
      except end;
      if VarToStr(AllVideoFolder.ChildItems[i].Properties[mpiTimeLength]) = '' then try 
        AllVideoFolder.ChildItems[i].RetrieveProperties;                                       
      except end;      
    end;    
  WmsLogMessage(mtiInfo,"read properties"); 
  //WmsDatabaseAutoSave; 
  ProcessMediaResult := True      
end.

[Eugene]

Allmost every day I get the following error

File:C:\Documents and Settings\All Users.WINDOWS\Application Data\Wild Media Server\wms.dat
Fout laden:Access violation at address 00405A04 in module 'wms.exe'. Read of address FFFFFFFA.
Load Back-up?

No entry to be found in log book, so no clue as to what is the reason.

Version 1.08.3 (and all version before that)

Extra information: The following script runs every 10 minutes because wms sometimes doesn't allways read the properties of all recorded file. Yesterday I disabled the statement WmsDatabaseAutoSave but this didn't make any difference.

var
i: Integer;
AllVideoFolder: TWmsScriptMediaItem;
begin
AllVideoFolder := WmsFindMediaFolder(mfVideoAllMoviesItemID);
if (AllVideoFolder <> nil) then
for i := 0 to AllVideoFolder.ChildCount - 1 do
begin
if VarToStr(AllVideoFolder.ChildItems.Properties[mpiTimeLength]) > '1' then try
AllVideoFolder.ChildItems.Properties[mpiTimeLength]:='01:00:00.000';
except end;
if VarToStr(AllVideoFolder.ChildItems.Properties[mpiTimeLength]) = '' then try
AllVideoFolder.ChildItems.RetrieveProperties;
except end;
end;
WmsLogMessage(mtiInfo,"read properties");
//WmsDatabaseAutoSave;
ProcessMediaResult := True
end.

Try disable the script, properties will be read during preparation of list of media resources.

[ajuga]

Try disable the script, properties will be read during preparation of list of media resources.

No they are NOT read allways. That's exactly the reason I implemented this script. This was your own suggestion. See your reply on topic

http://www.wildmediaserver.com/forum/vi ... 1982#p1982 (Fri Apr 30, 2010 3:58 pm)

To be short: The script is needed as long as the wms-doesnt-always-read-properties bug isn't fixed. By the way: Regardless of the fact that you can't reproduce the behaviour that wms doesn't always read the properties you should certainly be able to detect it and log it. The second reason I need this script is because of some files the length is wrong (see http://www.wildmediaserver.com/forum/vi ... 5394#p5394). I don't blame wms for this (allthough mediainfo has no problems with these files) but I DO have to take care of it, so I just force a length of 1 hour).

I have to accept the fact that wms is closed source, otherwise I could fix these problems myself. I have no problems with workarounds. But I just hate non-robustness. Whatever the cause is: Such an access violation should never occur and should be dealt by the developer and not by the user.

[Eugene]

Try disable the script, properties will be read during preparation of list of media resources.

No they are NOT read allways. That's exactly the reason I implemented this script. This was your own suggestion. See your reply on topic

http://www.wildmediaserver.com/forum/vi ... 1982#p1982 (Fri Apr 30, 2010 3:58 pm)

To be short: The script is needed as long as the wms-doesnt-always-read-properties bug isn't fixed. By the way: Regardless of the fact that you can't reproduce the behaviour that wms doesn't always read the properties you should certainly be able to detect it and log it. The second reason I need this script is because of some files the length is wrong (see http://www.wildmediaserver.com/forum/vi ... 5394#p5394). I don't blame wms for this (allthough mediainfo has no problems with these files) but I DO have to take care of it, so I just force a length of 1 hour).

I have to accept the fact that wms is closed source, otherwise I could fix these problems myself. I have no problems with workarounds. But I just hate non-robustness. Whatever the cause is: Such an access violation should never occur and should be dealt by the developer and not by the user.

The program have processing for http://www.wildmediaserver.com/forum/vi ... 1982#p1982.

FFMPeg is open-source, so

otherwise I could fix these problems myself.

You will help yourself and FFMPEG-developers

[ajuga]

Forget the issue with wrong length. We are getting further away from the real issue. Which is: access violation reading wms.dat in wms.exe. This is a robustness problem which you have to solve in wms (exception handlers).

[Eugene]

Forget the issue with wrong length. We are getting further away from the real issue. Which is: access violation reading wms.dat in wms.exe. This is a robustness problem which you have to solve in wms (exception handlers).

Can you provide wms.dat ? (eg to support@wildmediaserver.com)

[ajuga]

You mean NOW or the next time the error occurs?

[Eugene]

You mean NOW or the next time the error occurs?

At your convenience

[ajuga]

version 1.09.1 resolved the access violation