Sage 9.0.9 Released

[stuckless]

You can see the release notes here...
https://github.com/google/sagetv/blo...r/CHANGELOG.md

Fix: GetSeriesID wasn't always returning a valid series ID
New: Added logic to Schedules Direct program categories to ensure Movie is the first category for programs that start with MV
Fix: Cleaned up the logic for determining when images from Schedules Direct should be in a Show or SeriesInfo object
Fix: Clarified in logging when we can't process anything currently because Schedules Direct is offline
Fix: Added random timeout when Schedules Direct token expires before getting a new token in case there are multiple SageTV servers using the same account

[jusjoken]

Windows installer also now updated.

Also removed the EPG License key field from the installer as it is now available directly during EPG setup in the UI.

k

[egeller]

@Admins - Please move this if it should be posted elsewhere.

I use Eclipse on Windows, with Gradle, because I like to build my own JAR file. I pulled the current code base and I am seeing a failure in the compile. Can someone tell me if this is my issue or not?


Gradle suite > Gradle test > sage.IOUtilsTest.testGetUrlAsString FAILED
java.lang.AssertionError at IOUtilsTest.java:17

Gradle suite > Gradle test > sage.IOUtilsTest.testReadFileAsString FAILED
java.lang.AssertionError at IOUtilsTest.java:24

108 tests completed, 2 failed
:test FAILED

In the meantime I'll use the JAR posted at the link elsewhere.

[jusjoken]

Originally Posted by egeller

@Admins - Please move this if it should be posted elsewhere.

I use Eclipse on Windows, with Gradle, because I like to build my own JAR file. I pulled the current code base and I am seeing a failure in the compile. Can someone tell me if this is my issue or not?


Gradle suite > Gradle test > sage.IOUtilsTest.testGetUrlAsString FAILED
java.lang.AssertionError at IOUtilsTest.java:17

Gradle suite > Gradle test > sage.IOUtilsTest.testReadFileAsString FAILED
java.lang.AssertionError at IOUtilsTest.java:24

108 tests completed, 2 failed
:test FAILED

In the meantime I'll use the JAR posted at the link elsewhere.

I am not doing any java development right now but I did do the builds on my windows dev box this morning to include the new jars in the windows installer...I had no errors.

I just run....

• gradlew.bat sageJar
• gradlew.bat miniclientJar

No issues.

k

[stuckless]

Originally Posted by egeller

@Admins - Please move this if it should be posted elsewhere.

I use Eclipse on Windows, with Gradle, because I like to build my own JAR file. I pulled the current code base and I am seeing a failure in the compile. Can someone tell me if this is my issue or not?


Gradle suite > Gradle test > sage.IOUtilsTest.testGetUrlAsString FAILED
java.lang.AssertionError at IOUtilsTest.java:17

Gradle suite > Gradle test > sage.IOUtilsTest.testReadFileAsString FAILED
java.lang.AssertionError at IOUtilsTest.java:24

108 tests completed, 2 failed
:test FAILED

In the meantime I'll use the JAR posted at the link elsewhere.

Are you sure you have the latest code? There was an issue with this test, but it was fixed.

[KarylFStein]

Originally Posted by stuckless

Are you sure you have the latest code? There was an issue with this test, but it was fixed.

FYI, I cloned the repository a while ago and have been able to "sync" and build using gradlew.bat up until a couple weeks ago. Then doing a "sync" didn't pull any new commits, (and I was getting a couple branches--master from May and google/master--when before it was just one). I just did a wipe and re-clone, and it seems to be back to normal...

[egeller]

Thanks for the confirmations that it is something on my side. I will keep digging into it and figured it out. It's strange. I deleted the local copy and redownloaded the project. I ran gradle with the --debug option and the log tells me

13:30:33.402 [DEBUG] [TestEventLogger] Gradle suite > Gradle test > sage.IOUtilsTest.testGetUrlAsString FAILED
13:30:33.402 [DEBUG] [TestEventLogger]     java.lang.AssertionError: expected:<beec1608cf997d3acb42f0ab772b143f
13:30:33.402 [DEBUG] [TestEventLogger]     > but was:<beec1608cf997d3acb42f0ab772b143f
13:30:33.402 [DEBUG] [TestEventLogger]     >
13:30:33.402 [DEBUG] [TestEventLogger]         at org.testng.Assert.fail(Assert.java:89)
13:30:33.402 [DEBUG] [TestEventLogger]         at org.testng.Assert.failNotEquals(Assert.java:489)
13:30:33.402 [DEBUG] [TestEventLogger]         at org.testng.Assert.assertEquals(Assert.java:118)

Expected looks identical to calculated to me. I have a second computer I can test this out on to figure out where I screwed up.

[EnterNoEscape]

Originally Posted by egeller

Thanks for the confirmations that it is something on my side. I will keep digging into it and figured it out. It's strange. I deleted the local copy and redownloaded the project. I ran gradle with the --debug option and the log tells me

13:30:33.402 [DEBUG] [TestEventLogger] Gradle suite > Gradle test > sage.IOUtilsTest.testGetUrlAsString FAILED
13:30:33.402 [DEBUG] [TestEventLogger]     java.lang.AssertionError: expected:<beec1608cf997d3acb42f0ab772b143f
13:30:33.402 [DEBUG] [TestEventLogger]     > but was:<beec1608cf997d3acb42f0ab772b143f
13:30:33.402 [DEBUG] [TestEventLogger]     >
13:30:33.402 [DEBUG] [TestEventLogger]         at org.testng.Assert.fail(Assert.java:89)
13:30:33.402 [DEBUG] [TestEventLogger]         at org.testng.Assert.failNotEquals(Assert.java:489)
13:30:33.402 [DEBUG] [TestEventLogger]         at org.testng.Assert.assertEquals(Assert.java:118)

Expected looks identical to calculated to me. I have a second computer I can test this out on to figure out where I screwed up.

I can tell you the issue is likely to do with line endings. I had to push an update a little while ago for this test to work on Windows. Ensure that the version you have downloaded has the following in sage/IOUtilsTest.java on line 17:

assertEquals(md5, "beec1608cf997d3acb42f0ab772b143f" + System.lineSeparator());

[egeller]

It does. That is why it confuses me, as it looks like the line endings are in both the calculated and the expected.... Unless it's a unicode vs. not-Unicode sort of things (we had one of those at work, when I was working earlier this year).

I tried it with the line ending code removed and it also failed. When I commented out the two tests entirely, the compile succeeded. BTW - I don't know much Java. I am more of a Python and Oracle SQL guy (newly retired).

[EnterNoEscape]

Originally Posted by egeller

It does. That is why it confuses me, as it looks like the line endings are in both the calculated and the expected.... Unless it's a unicode vs. not-Unicode sort of things (we had one of those at work, when I was working earlier this year).

I tried it with the line ending code removed and it also failed. When I commented out the two tests entirely, the compile succeeded. BTW - I don't know much Java. I am more of a Python and Oracle SQL guy (newly retired).

I think I know what the problem is. It has to do with how you have git configured. On Windows platforms, it often will convert \n to \r\n in files thinking it's helping you and this is also the default behavior. I recall needing to do some special handling of scripts for Linux in OpenDCT to make sure the way someone configured git didn't break the scripts when I was building the packages. The test just needs to be re-written to accept either line ending as ok. I bet if you remove the appended line separator and add \n to the end of the string instead, the test will pass. I will push a fix for this later today.

[stuckless]

Originally Posted by EnterNoEscape

I think I know what the problem is. It has to do with how you have git configured. On Windows platforms, it often will convert \n to \r\n in files thinking it's helping you and this is also the default behavior. I recall needing to do some special handling of scripts for Linux in OpenDCT to make sure the way someone configured git didn't break the scripts when I was building the packages. The test just needs to be re-written to accept either line ending as ok. I bet if you remove the appended line separator and add \n to the end of the string instead, the test will pass. I will push a fix for this later today.

Maybe the easier fix is just to trim() the compares and ignore the line endings. (I realize this is actually my test )

[EnterNoEscape]

Originally Posted by stuckless

Maybe the easier fix is just to trim() the compares and ignore the line endings. (I realize this is actually my test )

It would be, but if something unexpected got appended and it happened to be a whitespace character, we would never know it. I made the test was specific to the expected situations. It likely will never matter, but why chance a hard to track down issue.

[egeller]

The fix works for me. Thanks for the help.