Re: WMC crashes on attempting new recording
Posted: Thu Mar 15, 2018 2:41 pm
This looks to me to be a corrupted database and using the [Rebuild WMC Database] button in the client should fix it for you.
Two things:
1) The errors you see in the log right after the " Entering importMxfFile()..." line are generated by the loadmxf.exe utility which is part of WMC. At this point, the only way epg123 could cause a failure is if there are structural errors in the MXF file which would be identified in the error text. This is not the case and is actually database errors.
2) By default, epg123 will not perform the import while there is an active recording. This was instituted quite a few versions ago. Could you provide more of your trace log to show updates during a recording?
When epg123 goes to import the MXF file into the database using loadmxf.exe, it checks for active recordings. If there are recordings active, it will query the scheduled end times of the recordings and wait until after they are complete to try again. If there are more/different active recordings at that point it will repeat and keep waiting for up to 5 hours before aborting completely. Because of this logic, I don't think the initial database corruption could have been due to an import during a recording. That's not to say a bad import did not cause the corruption in the first place, just that it wasn't during a recording.
Two things:
1) The errors you see in the log right after the " Entering importMxfFile()..." line are generated by the loadmxf.exe utility which is part of WMC. At this point, the only way epg123 could cause a failure is if there are structural errors in the MXF file which would be identified in the error text. This is not the case and is actually database errors.
2) By default, epg123 will not perform the import while there is an active recording. This was instituted quite a few versions ago. Could you provide more of your trace log to show updates during a recording?
When epg123 goes to import the MXF file into the database using loadmxf.exe, it checks for active recordings. If there are recordings active, it will query the scheduled end times of the recordings and wait until after they are complete to try again. If there are more/different active recordings at that point it will repeat and keep waiting for up to 5 hours before aborting completely. Because of this logic, I don't think the initial database corruption could have been due to an import during a recording. That's not to say a bad import did not cause the corruption in the first place, just that it wasn't during a recording.