SlimmGBPVR - replacement for GBPVRTray

[aurora]

Does this always happen or does it occur when you have one or more recordings following the same number of recordings?

I think it always happens, but not sure. Just saw this last night. NOt sure what you mean by having one or more recordings following the same recording? DO you men back to back of the same show?

Is GB-PVR operating over a network of any kind?

No, GBPVR and tray are running locally on the same machine.

However, you mentioning this does bring to mind an area I might have overlooked when I recently adjusted the green light code in my program and an item where I might improve. Thank you for your time.

No problem, appreciate your support. Please let me know if I can be of any assistance.

[Mister Slimm]

I think it always happens, but not sure. Just saw this last night. NOt sure what you mean by having one or more recordings following the same recording? DO you men back to back of the same show?

Sort of. For example, if you have one tuner and are recording something back-to-back. Or two tuners and one is recording a back-to-back item and the other a long item that overlaps the end/start time of the other tuner.

With regard to the in-progress recordings not showing up, that seems pretty strange and is not a problem I'm having here. If you load GB-PVR and wait for the dynamic display, does that list the in-progress recordings correctly?

All I do is ask GB-PVR for the recordings which are in-progress. Being able to turn the light off by getting the balloon up and not getting a list of in-progress recordings are the same problem.

The light in SlimmGBPVR operates in much the same way as in GBPVRTray (I believe) but when the balloon is opened, it attempts to list in-progress recordings and if it does't find any, it overrides the normal light routine and turns the light off. This is also the moment that the Stop Recording menu is populated.

Could you post the SlimmGBPVR.exe.log?

[aurora]

Yes, will post. Might not be able to get to it until Saturday though. Sorry for the delay but end of the week is always tight for time.

[aurora]

Included is log, covers problems yesterday and further playing today. I am running slimm and GBPVR tray in parallel.

Observations from today:

I have back to back recordings scheduled on my single tuner at 7:00 AM and 7:30 AM every weekday, sat through both this morning. 7:00 AM Recording overlaps the EPG disconnect so some of this behavior might be expected.

1) 7:00 AM GBPVR indicates recording in progress. Slimm does not recognize. From 7:00 to 7:10 slimm periodically triggers "Hold on a sec" ballon and displays status without prompting from me. CLI returns no recodings in progress.

2) 7:10 - 7:29, GBPVR tray continues reporting recording, neither slimm tray or CLI report an inprogress recording. Periodic "Hold on a sec" stops, I assume because EPG disconnect is over.

3) 7:30 slimm tray correctly indicates that 7:00 AM recording is done and indicates 7:30 recording is starting. Slimm and cli continue correct behavior through entire recording.

4) 8:00 AM both slimm and gbpvr indicate that no further recordings are in progress

So answer to your question earlier, is no. This problem does not occur all the time.

At this point I do not know what triggers the problem. Will keep looking.

Thank you once again for all your time and effort on this.

[Mister Slimm]

Included is log, covers problems yesterday and further playing today. I am running slimm and GBPVR tray in parallel.

Observations from today:

I have back to back recordings scheduled on my single tuner at 7:00 AM and 7:30 AM every weekday, sat through both this morning. 7:00 AM Recording overlaps the EPG disconnect so some of this behavior might be expected.

1) 7:00 AM GBPVR indicates recording in progress. Slimm does not recognize. From 7:00 to 7:10 slimm periodically triggers "Hold on a sec" ballon and displays status without prompting from me. CLI returns no recodings in progress.

2) 7:10 - 7:29, GBPVR tray continues reporting recording, neither slimm tray or CLI report an inprogress recording. Periodic "Hold on a sec" stops, I assume because EPG disconnect is over.

3) 7:30 slimm tray correctly indicates that 7:00 AM recording is done and indicates 7:30 recording is starting. Slimm and cli continue correct behavior through entire recording.

4) 8:00 AM both slimm and gbpvr indicate that no further recordings are in progress

So answer to your question earlier, is no. This problem does not occur all the time.

At this point I do not know what triggers the problem. Will keep looking.

Thank you once again for all your time and effort on this.

Thanks, but um. No real clue.

One thing is you are not using the latest available version.
The other is you have database disconnect turned on (I think!). As you are now on SQLite that option is no longer needed and you can turn it off in the Advanced tab of Tray Configuration.

The database disconnect exits SlimmGBPVR a couple of minutes before 7:00AM and reloads it telling it to wait for a few minutes before doing anything. When SlimmGBPVR wakes up after these few minutes, if GBPVR is recording it automatically shows the balloon. So that could be one of the random balloon guest appearances.

Presumably the balloon never contains the name of in-progress recordings? As to this and the non-listing of in-progress items in GBPVRcli, I am really stumped.

If GBPVRcli is creating an error it should be noted in "GBPVRcli.error.log" and/or "GBPVRcli.exe.log". Also, it would be helpful if you post all the Slimm logs (there will probably be 4 of each called SlimmGBPVR.exe.log, SlimmGBPVR.exe-1.log and so on).

Sorry 'bout this bother. Yours truly.

[aurora]

Thanks, but um. No real clue.

One thing is you are not using the latest available version.
The other is you have database disconnect turned on (I think!). As you are now on SQLite that option is no longer needed and you can turn it off in the Advanced tab of Tray Configuration.

Yes, knew I was a version back, will upgrade. Will turn off disconnect, did not realize that it was not needed with SQLite. As a side note, I am using the version of the native utilities which fixes the "cannot delete failed recording bug". Just an FYI in case that may have something to do with it.

The database disconnect exits SlimmGBPVR a couple of minutes before 7:00AM and reloads it telling it to wait for a few minutes before doing anything. When SlimmGBPVR wakes up after these few minutes, if GBPVR is recording it automatically shows the balloon. So that could be one of the random balloon guest appearances.

That is what I assumed. Sine the disconnect is between 6:58 and 7:10 AM. The time span appears to correlate to behavior.

Presumably the balloon never contains the name of in-progress recordings? As to this and the non-listing of in-progress items in GBPVRcli, I am really stumped.

When the cli returns correctly, then the ballon has the correct name, otherwise no.

If GBPVRcli is creating an error it should be noted in "GBPVRcli.error.log" and/or "GBPVRcli.exe.log". Also, it would be helpful if you post all the Slimm logs (there will probably be 4 of each called SlimmGBPVR.exe.log, SlimmGBPVR.exe-1.log and so on).

Sorry 'bout this bother. Yours truly.

No bother, will post as soon as I get a chance. I really appreciate you looking into this.

[Mister Slimm]

Note: this version is not compatible with GBPVR v0.96.12 or earlier. There is a legacy link in the first post on this topic.

Version 1.4.2408.36462 beta (direct download link)

As always, this is a beta, comments, suggestions and bugs report are welcomed.

Features:

• Added Conflicts menu.
  
• Added conflict resolution code to Conflicts menu.
  
• Added /priority command-line switch.
  
• Added documentation for SlimmGBPVR command-line switches.
  

Bug fix

• Text in Cancel Pending dialog box was the wrong way around and did the opposite of what it said.
  

[Mister Slimm]

Just noticed that I broke the command-line arguments for the system tray component SlimmGBPVR. Will be fixed in next version. Sorry.

[Mister Slimm]

Note: this version is not compatible with GBPVR v0.96.12 or earlier. There is a legacy link in the first post on this topic.

Version 1.5.2410.3341 beta (direct download link)

As always, this is a beta, comments, suggestions and bugs report are welcomed.

Features:

• Added error reporting and auto-zipping of GB-PVR log files.
  

Bug fix

• Couple-a bugs fixed.
  

[aurora]

Hi Mr. Slimm,

Here are the complete logs for the problem I posted the other day as requested. Sorry for the delay. Now that logs are posted, I am going to update and disable database disconnect. Hope to play around tomorrow morning before work to explore issue some more. Will let you know if I find anything.

Thanks for all your effort on this. Have a hard time keeping up with your updates. Can not wait to see how conflicts came out.