Plugin: Sage Recording Extender (SREv3)

[Slugger]

Yeah, ok, the bug is fixed, but Google Code is having some problems preventing me from committing the changes. Once I can, a new build will be in the repository that contains the fix.

[cat6man]

got the latest update this morning, but won't have a test until tomorrow (sox are travelling to arizona on a day off)..............i did note that the download was brutally slow, like where you can count 1-2-3 (or more) in between % changes in download............something was slowing down this am......but it did seem to install ok

[Slugger]

This is a heads up that livepvrdata.com will be doing some testing on the cloud over the next couple weeks. They will be testing OAuth authentication with the web app and to do all of the required testing requires them to switch the production version of the app from the current one to the test version. SRE currently does not support this new version of livepvrdata.com so when they switch the web app, SRE will be broken.

I've been guaranteed that they will only switch during the day time and will switch it back by 6pm EDT daily, which means this should not affect most SRE users. The only side effect will be that pre game checks of events may fail during the day, but should recover by the start of recordings. With that said, anything could happen and SRE may be broken on some evenings. Should that happen, your recordings may not be extended. This is the price of volunteering my user base as test subjects.

Depending on their test results, they may upgrade to OAuth sooner rather than later, which means SRE will be immediately broken until I get OAuth support in. I'm pushing for them to hold off on the upgrades until the MLB All Star break, but I don't think they want to wait that long. Time will tell.

The move to OAuth is actually a good thing - it means I will no longer have to ask for nor store your Google Account id/pwd in SRE. You will simply authorize Live PVR Data to use your Google Account and SRE only has to store and maintain the authorization token received from Google. It also removes a lot of the hacked authentication mechanisms currently in use. So this change is actually welcomed, but it will require a new version of SRE to support it. Changes aren't huge, but will take some time so if they upgrade before the All Star break then I'm afraid SRE will be useless for a few days+.

livepvrdata.com will start testing OAuth on the cloud this week (as early as tomorrow afternoon).

I'll provide updates in this thread as they become available.

[cat6man]

Originally Posted by Slugger

This is the price of volunteering my user base as test subjects.

we are all lab rats

[skiingwiz]

The manual flag is not being unset for me. I've tracked it down to the log section below. Two weird things are happening. (Which may or may not be related.)

1) The AiringMonitor seems to be kicking off twice. Every 2 minutes there are 2 runs (16 seconds apart in my log) of the AiringMonitor.
2) Somehow, the recording is ending before SRE thinks that it should.

Looking at the AiringMonitor code, it seems that the flag isn't unset because the next to last check determines that the event it over and sets isMonitored to false. The last check then determines that the airing is not recording, but doesn't change isMonitored. So in the finally block, the unsetManualFlag method is never called.

Any help figuring out how to fix this would be appreciated.

2010-06-24 23:10:04,912 INFO  [AiringMonitor]: 'MLB Baseball: Pittsburgh Pirates at Texas Rangers': Event not over; recording extended! [312ms]
2010-06-24 23:10:04,912 INFO  [AiringMonitor]: 'MLB Baseball: Pittsburgh Pirates at Texas Rangers': Next check in 2 minutes...
2010-06-24 23:10:20,850 INFO  [AiringMonitor]: 'MLB Baseball: Pittsburgh Pirates at Texas Rangers': Event not over; nothing to be done! [172ms]
2010-06-24 23:10:20,850 INFO  [AiringMonitor]: 'MLB Baseball: Pittsburgh Pirates at Texas Rangers': Next check in 2 minutes...
2010-06-24 23:12:04,897 INFO  [AiringMonitor]: 'MLB Baseball: Pittsburgh Pirates at Texas Rangers': Event not over; recording extended! [297ms]
2010-06-24 23:12:04,897 INFO  [AiringMonitor]: 'MLB Baseball: Pittsburgh Pirates at Texas Rangers': Next check in 2 minutes...
2010-06-24 23:12:20,850 INFO  [AiringMonitor]: 'MLB Baseball: Pittsburgh Pirates at Texas Rangers': Event not over; nothing to be done! [172ms]
2010-06-24 23:12:20,850 INFO  [AiringMonitor]: 'MLB Baseball: Pittsburgh Pirates at Texas Rangers': Next check in 2 minutes...
2010-06-24 23:14:04,787 INFO  [AiringMonitor]: 'MLB Baseball: Pittsburgh Pirates at Texas Rangers': Event not over; recording extended! [187ms]
2010-06-24 23:14:04,787 INFO  [AiringMonitor]: 'MLB Baseball: Pittsburgh Pirates at Texas Rangers': Next check in 2 minutes...
2010-06-24 23:14:20,881 INFO  [AiringMonitor]: 'MLB Baseball: Pittsburgh Pirates at Texas Rangers': Event not over; nothing to be done! [203ms]
2010-06-24 23:14:20,881 INFO  [AiringMonitor]: 'MLB Baseball: Pittsburgh Pirates at Texas Rangers': Next check in 2 minutes...
2010-06-24 23:16:04,803 INFO  [AiringMonitor]: 'MLB Baseball: Pittsburgh Pirates at Texas Rangers': Event is over; recording will end at Thu Jun 24 23:18:00 EDT 2010 [203ms]
2010-06-24 23:16:04,803 INFO  [AiringMonitor]: 'MLB Baseball: Pittsburgh Pirates at Texas Rangers': Next check in 2 minutes...
2010-06-24 23:16:20,678 INFO  [AiringMonitor]: 'MLB Baseball: Pittsburgh Pirates at Texas Rangers': Airing is not recording; stopping monitor thread! [0ms]

[Slugger]

Are you running 3.0.0.872?

[skiingwiz]

Originally Posted by Slugger

Are you running 3.0.0.872?

Yes, I am. I have been for a few days prior to the log that I posted.

[Slugger]

Now that I'm actually awake and alert this morning, I studied this a little closer.

Originally Posted by skiingwiz

The manual flag is not being unset for me. I've tracked it down to the log section below. Two weird things are happening. (Which may or may not be related.)

1) The AiringMonitor seems to be kicking off twice. Every 2 minutes there are 2 runs (16 seconds apart in my log) of the AiringMonitor.

This was a regression bug introduced. It's been fixed. Now, only one airing monitor can ever be invoked for the same airing id.

2) Somehow, the recording is ending before SRE thinks that it should.

Fixed - I think. You'll have to let me know. I believe there is a delay between me (SRE) resetting the end time of the recording and the Sage airing object actually reflecting that time on subsequent calls to read it. Should be fixed. It was just a display bug, the recording should have ended when it was ending - no logic problems, but it should obviously print when it actually is going to stop the recording.

Looking at the AiringMonitor code, it seems that the flag isn't unset because the next to last check determines that the event it over and sets isMonitored to false. The last check then determines that the airing is not recording, but doesn't change isMonitored. So in the finally block, the unsetManualFlag method is never called.

Excellent... a Java programmer! You found the cause of issue 132. Don't be shy about submitting patches because I'm more than willing to apply them.

Anyway, this has been fixed. A new build will appear in the repository shortly.

[skiingwiz]

Originally Posted by Slugger

Excellent... a Java programmer! You found the cause of issue 132. Don't be shy about submitting patches because I'm more than willing to apply them.

Guilty Glad I could help. Next time, I'll look to submit a patch and save you some work.

Originally Posted by Slugger

Anyway, this has been fixed. A new build will appear in the repository shortly.

Awesome. Thanks for the quick turn around. I'll upgrade today and check out the changes.

[cat6man]

discussion of manual flag made me wonder:

what is the purpose of the config option regarding manual flag and favorites?
can you explain why i would turn it either on or off?

tx

p.s. it was so cool to have SRE record the entire 4:30 hour game in arizona the other
night............i appreciate SRE even more when night games are on the left coast and time
zones away!

[skiingwiz]

Originally Posted by cat6man

discussion of manual flag made me wonder:

what is the purpose of the config option regarding manual flag and favorites?
can you explain why i would turn it either on or off?

When SRE extends a recording that is a favorite, it has to convert it to a manual recording. (That's just the way Sage works.) If the config option is on, it will remove the manual recording flag once the recording is over. (Basically, setting it back to a favorite.)

I recommend turning it on. I don't see any disadvantage to having it on. If it is turned off and you have your favorite set to "Keep at most x recordings" (like I do), the recordings marked as manual won't count against that total, so they won't be automatically deleted.

[cat6man]

thanks..........sounds like a non-issue for me, so i'll just leave it on
(i archive all recordings each night from Sage's PC hard drive to an NAS)

[Slugger]

The Live PVR Data team has went ahead with its latest update, which moves the entire service to OAuth authentication. This change immediately breaks all versions of SRE.

Good news: I have an initial update for SRE that adds OAuth support. It is very, very rough around the edges, but is functional.

Basically, after upgrading you will get a system message telling you that SRE needs a google access token and will tell you to visit /sre/ in Jetty. Load the SRE web GUI and it will immediately present the Google authorization window. You have to click the first button (I know it's ugly/cut off, but I have to head out for the day by 1pm ) to bring up the Google site. Login to Google as directed and grant livepvrdata.com access to your Google account. Google will respond with a verification code. Feed that code back into SRE and click the second button. All goes well and SRE will proceed. That's it, everything else is the same except SRE no longer (directly) asks for nor stores your Google credentials.

Undoubtedly there will be some problems, I've only been able to do some basic initial testing. But without this update, SRE has a 0% chance of working. Hopefully just a few minor patches to address any issues that arise. Please report any problems and I'll get them addressed ASAP.

The updated SRE will appear in the repository shortly.

[cat6man]

that explains the sre message yesterday and today.........since the sox
play at 1pm today, the game has already started and since sre update requires a re-start, i'll wait until tonight to start testing it out.

let me know if there is anything other than the above you want me/us to check out

[cat6man]

update procedure went fine here (note: needed to close and reopen browser since cached SRE page was old one)

testing with ray/twins game now to see if it gets monitored

pretty quick turn around there slugger!

[Slugger]

Originally Posted by cat6man

pretty quick turn around there slugger!

I was given plenty of warning about this change and have been working on this here and there for a couple of weeks. Admittedly, the changes shouldn't be as rough as they are, but then again, it's way too nice to be sitting in front of a laptop at this time of the year hashing out UI issues. Hell, it's too nice out right now to be doing any kind of coding that doesn't pay the bills! (Now back to the bbq to finish up dinner... )

[cat6man]

didn't seem rough around the edges at all............and i can report that sre.log
shows it worked correctly on the rays/twins game i picked as a test recording

looks fine from here (just back from the family bbq)

[Slugger]

I disabled monitoring via an override b/c I knew that it can't be monitored via livepvrdata.com, but I wish I hadn't b/c now I want to know how SRE handles it. Can someone fill me in on how SRE handles this? Is the default padding applied? My review of the source code suggests that it won't apply default padding because it is a valid event type ("MLB Baseball"), but SRE will be told the event details are invalid (i.e. SRE is asking livepvrdata for details on an invalid event for a valid event type so it's a client error). What do you think SRE should do in this case? The current logic (assuming default padding isn't applied) is that since the event is not valid and was never valid then SRE should just do nothing with the recording. Now I'm wondering if default padding should be applied in this case? Either way, I wouldn't expect any kind of padding to be applied to recordings of the derby tonight.

Either way, if someone could fill me in on what happens I'd appreciated it. Appropriate portions of your sre.log file will also be helpful.

FYI: livepvrdata.com won't be changing data sources for MLB anytime soon (though they eventually will be moving to mlb.com) so we won't know if the all star game can be monitored until espn.com updates their feed tomorrow afternoon. If espn.com is not providing the feed for the all star game then SRE will not be able to monitor the all star game either. The last few all star events (NBA, Pro Bowl) were not carried in the espn.com feed so I'm not too hopeful at this point. Since livepvrdata.com is still in closed beta, they aren't rushing to change the data sources just yet so we're stuck with whatever espn.com decides to do. I'll add another post once I know tomorrow.

EDIT: Today's SRE update (884) claimed to fix a bug with handling overrides that disable the monitor for the recording. The fix isn't quite right and doesn't work. I've since fixed it and checked in the fix, but won't be rushing to post a new build.

[skiingwiz]

You are correct, no default padding was applied. I've attached a portion of my log, though I'm not sure it will tell you anything that you don't know.

As for what SRE should do, I am not sure where I fall on this. I can understand the logic that is currently being used. At the same time, I'd hate to miss something because it couldn't be monitored. I guess I'd rather the default padding be applied. Of course, that could get you into the situation where that causes conflicts with other recordings... It's a complicated issue.

[Slugger]

Unfortunately, the all star game is not in the ESPN Bottom Line feed for today so therefore livepvrdata.com will not be able to monitor tonight's game. After last night's results, it is clear that the current version of SRE will not apply default padding in this scenario so you may wish to add padding manually. I'm still not sure whether or not SRE should be applying default padding in this case, but either way I will not have time to make such a change and properly test it before tonight so you'll have to manually pad the recording, if desired.

Eventually, livepvrdata.com will be moving to the mlb.com feed for baseball, but there is no eta for that change at this time.