Xrecord wacky behavior- repetitive entries

[XJW]

Great solution. XRECORD is a superb tool - essential as it provides the ability to record shows based on a partial string. But I too was seeing many duplicate recordings of the same show in the same timeslot. Adding "DeleteSchedule.exe" before "PriorityRecording.exe" in the PostUpdateEPG.bat file fixed it. Is this something that could be added to the installation instructions in the WIKI ? It took me a while to find this fix.

[fla]

I never use DeleteSchedule.exe and never get duplicates. I think that's a workaround hiding a possible bug. Attached is a RecordingUtils.dll that prints more debug information to the console. Save the original RecordingUtils.dll and put this one in the gbpvr directory and run PriorityRecording.exe.

The first time I run PriorityRecording.exe with no pending recordings the pAddProgramList debug message says "adding".

Code:

C:\Program Files\devnz\gbpvr>PriorityRecording.exe
CDK Priority Recording Scheduler.
Version 1.0.1
...using System.Data.SQLite.SQLiteFactory DB Provider Factory
60 minutes has 1 potential recording(s).
getScheduleMatch: searching for programOID 3988 in 0 recordings
getScheduleMatch: not found, returning new recording
pAddProgramList: adding new "60 minutes" recording to list
60 Minutes is being recorded from 1/25/2009 7:00:00 PM to 1/25/2009 8:00:00 PM on capture source 1

The subsequent PriorityRecording.exe runs have pAddProgramList debug message saying "replacing".

Code:

C:\Program Files\devnz\gbpvr>PriorityRecording.exe
CDK Priority Recording Scheduler.
Version 1.0.1
...using System.Data.SQLite.SQLiteFactory DB Provider Factory
getScheduleMatch: searching for programOID 3988 in 0 recordings
getScheduleMatch: not found, returning new recording
pAddScheduled: adding new recording to list
60 minutes has 1 potential recording(s).
getScheduleMatch: searching for programOID 3988 in 1 recordings
getScheduleMatch: comparing 3988 to 3988
getScheduleMatch: found! Has scheduleOID = 6
pAddProgramList: replacing existing "60 minutes" recording in list
60 Minutes is being recorded from 1/25/2009 7:00:00 PM to 1/25/2009 8:00:00 PM on capture source 1

It would be great if you could run PriorityRecording.exe a few times and reproduce this "bug" and post the output. Sharing the PriorityRecordings.xml and the Config.xml would help me reproduce the problem here.

Thanks.

PS. I also found the CDK Scheduler portion of XSuite to be a hidden jewel of gbpvr use. All the credit goes to KingArgyle, I'm just keeping it alive since it would be a shame to let a cool tool like this die.

[XJW]

Fla,

Many thanks for your time and continued support for this tool. And yes - thanks to KingArgyle for CDK Scheduler. I have attached the files as requested and confirmed that each time priorityrecording is run it adds more duplicate entries to the pending list.

Regards
XJW

[fla]

Thanks for the excellent logs. It's definitely a bug(s) in RecordingUtils while loading the recording_schedule table. I found that if one record had an empty programme_oid field the entire table loading was skipped. I've changed it so that only those particular records are skipped.

I've attached the fixed RecordingUtils.dll. Please let me know if that fixes the problem. If not, there could be another bug. I'd need the same output as last time but also gbpvr.db3. I'll pm you my email address so you could send it through http://www.transferbigfiles.com/ or something. Instead of sending gbpvr.db3, if you're the technical type what I really need to see is the output of mysql query:

Code:

select * from recording_schedule where status = 0 or status = 5 order by status

Thanks again for helping get to the bottom of this. If the loading of the database is not working, you're not getting the full CDK Scheduler functionalty so it's worth solving this.

Oh if it does work let us know, I'll remove the debug messages and post a new version with the fix.

[XJW]

Fla,

Many thanks.

I ran PriorityRecording 3 times and confirmed that I was still getting duplicates. Then I ran deleteschedule and replaced RecordingUtils.dll with the one in your attachment and then repeated the test. No duplicates ! It works nicely.

Again many thanks for your continued support of this great tool !

[fla]

Terrific! This issue has been around for over three years. The wiki version now includes the database loading fix without all the debug messages. Note that some users with poor EPG data may still need DeleteSchedule.exe.

Thanks for your help in getting this fixed.