Recordings View is blank

[gary201]

I've noticed this bug for a while, and even brought it up once before, but it still exists. If I change the recordings view to sort by original air date, sometimes Sage will not show any recordings. Change the view to something else (e.g. Title, Intelligent, any of the others) and the recordings reappear with that sort order.

The difference between then and now is I think I know what's causing it. One of the recordings has a blank (no entry) for the original air date property. This seems to most often (maybe each time it's occurred) by a scenario where BMT imports a recording as a SageTV recording so it shows up on the TV Recordings menus (e.g. the split pane view when the extras are enabled). These recordings come from PlayOn recording something off of Netflix or Hulu that gets moved to a SageTV import directory and BMT then used to lookup the metadata and flag the imported recording as something SageTV recorded.

So which component is at fault (BMT or Sage)? My guess is that it's likely a little of both (BMT for not putting something in that field and SageTV for getting tripped up on a recording with a blank entry).

[wnjj]

If you look in the SageTV log file after causing one of these blank lists, it’s likely there will be an error which would help identify a bug. The sort algorithm is probably tripping over that blank field.

[gary201]

Sat 6/30 14:04:33.171 [ReProcessHook@45b15bd2] Filtered List size = 4669
Sat 6/30 14:04:33.171 [ReProcessHook@45b15bd2] ===== List Creation Elapsed Time = [2]
Sat 6/30 14:04:33.171 [ReProcessHook@45b15bd2] TotalCategoryFilterList=[]
Sat 6/30 14:04:33.171 [ReProcessHook@45b15bd2] Category Filter Elapsed Time = [0]
Sat 6/30 14:04:33.171 [ReProcessHook@45b15bd2] Other Filter Elapsed Time = [0]
Sat 6/30 14:04:33.171 [ReProcessHook@45b15bd2] FilterChannelsIn=true, FilterChannels=[]
Sat 6/30 14:04:33.171 [ReProcessHook@45b15bd2] Channel Filter Elapsed Time = [0]
Sat 6/30 14:04:33.172 [ReProcessHook@45b15bd2] No duplicates Elapsed Time = [0]
Sat 6/30 14:04:33.190 [ReProcessHook@45b15bd2] java.lang.IllegalArgumentException: Comparison method violates its general contract!
Sat 6/30 14:04:33.190 [ReProcessHook@45b15bd2] at java.util.TimSort.mergeHi(TimSort.java:899)
Sat 6/30 14:04:33.190 [ReProcessHook@45b15bd2] at java.util.TimSort.mergeAt(TimSort.java:516)
Sat 6/30 14:04:33.190 [ReProcessHook@45b15bd2] at java.util.TimSort.mergeCollapse(TimSort.java:439)
Sat 6/30 14:04:33.190 [ReProcessHook@45b15bd2] at java.util.TimSort.sort(TimSort.java:245)
Sat 6/30 14:04:33.190 [ReProcessHook@45b15bd2] at java.util.Arrays.sort(Arrays.java:1438)
Sat 6/30 14:04:33.190 [ReProcessHook@45b15bd2] at sage.api.Database$7.runSafely(Database.java:1575)
Sat 6/30 14:04:33.191 [ReProcessHook@45b15bd2] at sage.PredefinedJEPFunction.run(PredefinedJEPFunction.java:110)
Sat 6/30 14:04:33.191 [ReProcessHook@45b15bd2] at sage.jep.JEP$CommandEvaluator.evaluate(JEP.java:586)
Sat 6/30 14:04:33.191 [ReProcessHook@45b15bd2] at sage.jep.JEP.getValueAsObject(JEP.java:428)
Sat 6/30 14:04:33.191 [ReProcessHook@45b15bd2] at sage.Catbert.evaluateExpression(Catbert.java:641)
Sat 6/30 14:04:33.191 [ReProcessHook@45b15bd2] at sage.ZPseudoComp.processChain(ZPseudoComp.java:4641)
Sat 6/30 14:04:33.191 [ReProcessHook@45b15bd2] at sage.ZPseudoComp.processParentActions(ZPseudoComp.java:5212)
Sat 6/30 14:04:33.191 [ReProcessHook@45b15bd2] at sage.ZDataTable.evaluate(ZDataTable.java:1559)
Sat 6/30 14:04:33.191 [ReProcessHook@45b15bd2] at sage.ZPseudoComp.evaluateTree(ZPseudoComp.java:1154)
Sat 6/30 14:04:33.191 [ReProcessHook@45b15bd2] at sage.ZPseudoComp.evaluate(ZPseudoComp.java:5127)
Sat 6/30 14:04:33.191 [ReProcessHook@45b15bd2] at sage.ZPseudoComp.evaluateTree(ZPseudoComp.java:1154)
Sat 6/30 14:04:33.191 [ReProcessHook@45b15bd2] at sage.ZPseudoComp.evaluate(ZPseudoComp.java:5127)
Sat 6/30 14:04:33.191 [ReProcessHook@45b15bd2] at sage.ZPseudoComp.evaluateTree(ZPseudoComp.java:1154)
Sat 6/30 14:04:33.191 [ReProcessHook@45b15bd2] at sage.ZPseudoComp.evaluate(ZPseudoComp.java:5127)
Sat 6/30 14:04:33.191 [ReProcessHook@45b15bd2] at sage.ZPseudoComp.evaluateTree(ZPseudoComp.java:1154)
Sat 6/30 14:04:33.191 [ReProcessHook@45b15bd2] at sage.ZPseudoComp.evaluate(ZPseudoComp.java:5127)
Sat 6/30 14:04:33.191 [ReProcessHook@45b15bd2] at sage.ZPseudoComp.evaluateTree(ZPseudoComp.java:1154)
Sat 6/30 14:04:33.191 [ReProcessHook@45b15bd2] at sage.ZPseudoComp.evaluate(ZPseudoComp.java:5127)
Sat 6/30 14:04:33.191 [ReProcessHook@45b15bd2] at sage.ZPseudoComp.evaluateTree(ZPseudoComp.java:1154)
Sat 6/30 14:04:33.191 [ReProcessHook@45b15bd2] at sage.ZPseudoComp.evaluate(ZPseudoComp.java:5127)
Sat 6/30 14:04:33.191 [ReProcessHook@45b15bd2] at sage.ZPseudoComp.evaluateTree(ZPseudoComp.java:1154)
Sat 6/30 14:04:33.191 [ReProcessHook@45b15bd2] at sage.PseudoMenu.refresh(PseudoMenu.java:1114)
Sat 6/30 14:04:33.191 [ReProcessHook@45b15bd2] at sage.api.Global$1.runSafely(Global.java:77)
Sat 6/30 14:04:33.191 [ReProcessHook@45b15bd2] at sage.PredefinedJEPFunction.run(PredefinedJEPFunction.java:110)
Sat 6/30 14:04:33.191 [ReProcessHook@45b15bd2] at sage.jep.JEP$CommandEvaluator.evaluate(JEP.java:586)
Sat 6/30 14:04:33.191 [ReProcessHook@45b15bd2] at sage.jep.JEP.getValueAsObject(JEP.java:428)
Sat 6/30 14:04:33.191 [ReProcessHook@45b15bd2] at sage.Catbert.evaluateExpression(Catbert.java:641)
Sat 6/30 14:04:33.191 [ReProcessHook@45b15bd2] at sage.ZPseudoComp.processChain(ZPseudoComp.java:4641)
Sat 6/30 14:04:33.191 [ReProcessHook@45b15bd2] at sage.ZPseudoComp.processChain(ZPseudoComp.java:4680)
Sat 6/30 14:04:33.191 [ReProcessHook@45b15bd2] at sage.ZPseudoComp.processChain(ZPseudoComp.java:4579)
Sat 6/30 14:04:33.191 [ReProcessHook@45b15bd2] at sage.Catbert.processHookDirectly(Catbert.java:493)
Sat 6/30 14:04:33.191 [ReProcessHook@45b15bd2] at sage.Catbert.processUISpecificHook(Catbert.java:465)
Sat 6/30 14:04:33.191 [ReProcessHook@45b15bd2] at sage.Catbert$3.run(Catbert.java:404)
Sat 6/30 14:04:33.191 [ReProcessHook@45b15bd2] at sage.Pooler$PooledThread.run(Pooler.java:254)
Sat 6/30 14:04:33.191 [ReProcessHook@45b15bd2] EXCEPTION in getValueAsObject:sage.jep.ParseException: Error in method reflection of Sort of java.lang.IllegalArgumentException: Comparison method violates its general contract! for:Sort(List, GetProperty(menuname + "_sort_reverse", false), sorting)
Sat 6/30 14:04:33.191 [ReProcessHook@45b15bd2] sage.jep.ParseException: Error in method reflection of Sort of java.lang.IllegalArgumentException: Comparison method violates its general contract!
Sat 6/30 14:04:33.192 [ReProcessHook@45b15bd2] at sage.PredefinedJEPFunction.run(PredefinedJEPFunction.java:119)
Sat 6/30 14:04:33.192 [ReProcessHook@45b15bd2] at sage.jep.JEP$CommandEvaluator.evaluate(JEP.java:586)
Sat 6/30 14:04:33.192 [ReProcessHook@45b15bd2] at sage.jep.JEP.getValueAsObject(JEP.java:428)
Sat 6/30 14:04:33.192 [ReProcessHook@45b15bd2] at sage.Catbert.evaluateExpression(Catbert.java:641)
Sat 6/30 14:04:33.192 [ReProcessHook@45b15bd2] at sage.ZPseudoComp.processChain(ZPseudoComp.java:4641)
Sat 6/30 14:04:33.192 [ReProcessHook@45b15bd2] at sage.ZPseudoComp.processParentActions(ZPseudoComp.java:5212)
Sat 6/30 14:04:33.192 [ReProcessHook@45b15bd2] at sage.ZDataTable.evaluate(ZDataTable.java:1559)
Sat 6/30 14:04:33.192 [ReProcessHook@45b15bd2] at sage.ZPseudoComp.evaluateTree(ZPseudoComp.java:1154)
Sat 6/30 14:04:33.192 [ReProcessHook@45b15bd2] at sage.ZPseudoComp.evaluate(ZPseudoComp.java:5127)
Sat 6/30 14:04:33.192 [ReProcessHook@45b15bd2] at sage.ZPseudoComp.evaluateTree(ZPseudoComp.java:1154)
Sat 6/30 14:04:33.192 [ReProcessHook@45b15bd2] at sage.ZPseudoComp.evaluate(ZPseudoComp.java:5127)
Sat 6/30 14:04:33.192 [ReProcessHook@45b15bd2] at sage.ZPseudoComp.evaluateTree(ZPseudoComp.java:1154)
Sat 6/30 14:04:33.192 [ReProcessHook@45b15bd2] at sage.ZPseudoComp.evaluate(ZPseudoComp.java:5127)
Sat 6/30 14:04:33.192 [ReProcessHook@45b15bd2] at sage.ZPseudoComp.evaluateTree(ZPseudoComp.java:1154)
Sat 6/30 14:04:33.192 [ReProcessHook@45b15bd2] at sage.ZPseudoComp.evaluate(ZPseudoComp.java:5127)
Sat 6/30 14:04:33.192 [ReProcessHook@45b15bd2] at sage.ZPseudoComp.evaluateTree(ZPseudoComp.java:1154)
Sat 6/30 14:04:33.192 [ReProcessHook@45b15bd2] at sage.ZPseudoComp.evaluate(ZPseudoComp.java:5127)
Sat 6/30 14:04:33.192 [ReProcessHook@45b15bd2] at sage.ZPseudoComp.evaluateTree(ZPseudoComp.java:1154)
Sat 6/30 14:04:33.192 [ReProcessHook@45b15bd2] at sage.ZPseudoComp.evaluate(ZPseudoComp.java:5127)
Sat 6/30 14:04:33.192 [ReProcessHook@45b15bd2] at sage.ZPseudoComp.evaluateTree(ZPseudoComp.java:1154)
Sat 6/30 14:04:33.192 [ReProcessHook@45b15bd2] at sage.PseudoMenu.refresh(PseudoMenu.java:1114)
Sat 6/30 14:04:33.192 [ReProcessHook@45b15bd2] at sage.api.Global$1.runSafely(Global.java:77)
Sat 6/30 14:04:33.192 [ReProcessHook@45b15bd2] at sage.PredefinedJEPFunction.run(PredefinedJEPFunction.java:110)
Sat 6/30 14:04:33.192 [ReProcessHook@45b15bd2] at sage.jep.JEP$CommandEvaluator.evaluate(JEP.java:586)
Sat 6/30 14:04:33.192 [ReProcessHook@45b15bd2] at sage.jep.JEP.getValueAsObject(JEP.java:428)
Sat 6/30 14:04:33.192 [ReProcessHook@45b15bd2] at sage.Catbert.evaluateExpression(Catbert.java:641)
Sat 6/30 14:04:33.192 [ReProcessHook@45b15bd2] at sage.ZPseudoComp.processChain(ZPseudoComp.java:4641)
Sat 6/30 14:04:33.192 [ReProcessHook@45b15bd2] at sage.ZPseudoComp.processChain(ZPseudoComp.java:4680)
Sat 6/30 14:04:33.192 [ReProcessHook@45b15bd2] at sage.ZPseudoComp.processChain(ZPseudoComp.java:4579)
Sat 6/30 14:04:33.192 [ReProcessHook@45b15bd2] at sage.Catbert.processHookDirectly(Catbert.java:493)
Sat 6/30 14:04:33.192 [ReProcessHook@45b15bd2] at sage.Catbert.processUISpecificHook(Catbert.java:465)
Sat 6/30 14:04:33.192 [ReProcessHook@45b15bd2] at sage.Catbert$3.run(Catbert.java:404)
Sat 6/30 14:04:33.192 [ReProcessHook@45b15bd2] at sage.Pooler$PooledThread.run(Pooler.java:254)
Sat 6/30 14:04:33.192 [ReProcessHook@45b15bd2] Caused by: java.lang.IllegalArgumentException: Comparison method violates its general contract!
Sat 6/30 14:04:33.192 [ReProcessHook@45b15bd2] at java.util.TimSort.mergeHi(TimSort.java:899)
Sat 6/30 14:04:33.192 [ReProcessHook@45b15bd2] at java.util.TimSort.mergeAt(TimSort.java:516)
Sat 6/30 14:04:33.192 [ReProcessHook@45b15bd2] at java.util.TimSort.mergeCollapse(TimSort.java:439)
Sat 6/30 14:04:33.192 [ReProcessHook@45b15bd2] at java.util.TimSort.sort(TimSort.java:245)
Sat 6/30 14:04:33.192 [ReProcessHook@45b15bd2] at java.util.Arrays.sort(Arrays.java:1438)
Sat 6/30 14:04:33.192 [ReProcessHook@45b15bd2] at sage.api.Database$7.runSafely(Database.java:1575)
Sat 6/30 14:04:33.192 [ReProcessHook@45b15bd2] at sage.PredefinedJEPFunction.run(PredefinedJEPFunction.java:110)
Sat 6/30 14:04:33.192 [ReProcessHook@45b15bd2] ... 32 more
Sat 6/30 14:04:33.192 [ReProcessHook@45b15bd2] Sorting Elapsed Time = [20]
Sat 6/30 14:04:33.192 [ReProcessHook@45b15bd2] Grouping Elapsed Time = [0]
Sat 6/30 14:04:33.192 [ReProcessHook@45b15bd2] ===== Overall Group Creation Elapsed Time = [23]

[gary201]

I used BMT to re-lookup/save the metadata on a bunch of SageTV actual recorded shows (not imports), then happen to recheck and the view content returned and the log now contains the following when the view content is populated:

Sat 6/30 14:27:11.014 [ReProcessHook@440d2dd7] Filtered List size = 4668
Sat 6/30 14:27:11.014 [ReProcessHook@440d2dd7] ===== List Creation Elapsed Time = [175]
Sat 6/30 14:27:11.014 [ReProcessHook@440d2dd7] TotalCategoryFilterList=[]
Sat 6/30 14:27:11.015 [ReProcessHook@440d2dd7] Category Filter Elapsed Time = [1]
Sat 6/30 14:27:11.015 [ReProcessHook@440d2dd7] Other Filter Elapsed Time = [0]
Sat 6/30 14:27:11.015 [ReProcessHook@440d2dd7] FilterChannelsIn=true, FilterChannels=[]
Sat 6/30 14:27:11.015 [ReProcessHook@440d2dd7] Channel Filter Elapsed Time = [0]
Sat 6/30 14:27:11.015 [ReProcessHook@440d2dd7] No duplicates Elapsed Time = [0]
Sat 6/30 14:27:11.037 [ReProcessHook@440d2dd7] Sorting Elapsed Time = [22]
Sat 6/30 14:27:11.045 [ReProcessHook@440d2dd7] Grouping Elapsed Time = [7]
Sat 6/30 14:27:11.045 [ReProcessHook@440d2dd7] ===== Overall Group Creation Elapsed Time = [206]

I never really did find the specific show entry that caused the problem.

[gary201]

The problem continues to appear and dissapear. Does the exception error above mean anything to anyone?

[stuckless]

from what I can tell, from googling, the Java Sort implementation changed between 6 and 7, and whereas the v6 sort implementation was a little more fogiving, the v7 implementation is not. This ultimately is a problem in the code, in the item being sorted has an equals or compare method that is not implemented correctly. I don't know what is being sorted here, so I can't really tell where the problem really exists.

[gary201]

Originally Posted by stuckless

from what I can tell, from googling, the Java Sort implementation changed between 6 and 7, and whereas the v6 sort implementation was a little more fogiving, the v7 implementation is not. This ultimately is a problem in the code, in the item being sorted has an equals or compare method that is not implemented correctly. I don't know what is being sorted here, so I can't really tell where the problem really exists.

So how would we collectively find out? The view I'm seeing this happen on has a grouping of "Title" (from the options menu), then has a sort based on "Orig. Air Date". If I enable the "Reverse Sort Order", the contents return within the view, remove the checkbox for Reverse Sort Order and everything disappears from the view.

[wnjj]

The Orig Air Date sorting comparator is here:

https://github.com/google/sagetv/blo...ase.java#L1606

When reverse sort order is on I believe it wraps the comparator with an invert here:

https://github.com/google/sagetv/blo...ase.java#L1550

The only thing that seems a little weird is when one of the shows has a 0 for season or episode number, the algorithm reverts to using the Airing instead of just letting one come before the other. Maybe that’s ok though. Nevertheless, I don’t know why inverting the same comparator function would correct a violated contract.

With this, now do you have any ideas Sean?

[stuckless]

Originally Posted by wnjj

The Orig Air Date sorting comparator is here:

https://github.com/google/sagetv/blo...ase.java#L1606

When reverse sort order is on I believe it wraps the comparator with an invert here:

https://github.com/google/sagetv/blo...ase.java#L1550

The only thing that seems a little weird is when one of the shows has a 0 for season or episode number, the algorithm reverts to using the Airing instead of just letting one come before the other. Maybe that’s ok though. Nevertheless, I don’t know why inverting the same comparator function would correct a violated contract.

With this, now do you have any ideas Sean?

While I agree that the comparator should not check for 0 in the season or episode and use use it, I can't see any real issues with the code. It seems correct to me. And the reverse does what you'd expect.

[wnjj]

Actually, by reading a bit about compare contracts here https://stackoverflow.com/questions/...-general-contr, I think there could be an issue with this one.

With those checks for null shows, it leaves the possibility that two non-null shows (A and Bj will have an inconsistent compare result with a third show (C) that is null since different compare schemes are used as a fallback. Based upon the secondary compare (airing), A could be less than C and B could be greater than C but by using the actual air date for comparing A may be greater than B. This violates the transitive property. Again, I can’t see how reversing the sort would correct this since all it does is multiply by -1.

I also think the season number is sorted wrong. If you consider that a higher season number on the same airing date is actually an older show, it should return -1.

EDIT: Now I’m not sure that my A B C scenario can happen since null shows are always less than non-null.

[wnjj]

Reading on the interwebs further, it seems doing the following can be problematic:

              int x = n1 - n2;
              if (x != 0 && n1 != 0 && n2 != 0)
                return x;

While simply subtracting integers should work in theory, if either of them is near MIN/MAX_VALUE the result can over/underflow which will affect the results. Normally numbers in Sage shouldn't near those limits but this is a case where something isn't normal. It may also explain why the reverse sort that multiplies the function by -1 works since -MIN_VALUE != MAX_VALUE.

[stuckless]

Originally Posted by wnjj

Reading on the interwebs further, it seems doing the following can be problematic:

              int x = n1 - n2;
              if (x != 0 && n1 != 0 && n2 != 0)
                return x;

While simply subtracting integers should work in theory, if either of them is near MIN/MAX_VALUE the result can over/underflow which will affect the results. Normally numbers in Sage shouldn't near those limits but this is a case where something isn't normal. It may also explain why the reverse sort that multiplies the function by -1 works since -MIN_VALUE != MAX_VALUE.

That's a good point. And this is a common implementation. Since Java 7, I tend to use the static Iteger.compare(x1,x2) method that does the compare logic for you.

[gary201]

So I'm curious. Does this suggest there is a potential to use a native sorting function rather than hand-craft that function?

One thing I've also observed a couple times now, and I've no idea if this is related or not, I was watching a recording w/the sort as I've been trying to use and after watching the recording, the failure occurred and the recording display was again blank. This lasts for a good part of a day or so and then it reappears (I presume after recordings were either added/removed).

My setup is rather simple. I only use two dual-tuner HomeRun devices for OTA recordings (e.g. no cable TV). I also use PlayOn to record shows off Netflix/Hulu, then move those recorded shows into a SageTV "Import" directory. I then use BMT to enable the "Recorded by Sage" setting so they appear in the Sage recordings display.

[wnjj]

Most of the hand crafting involves the cascade sorting from original air date to season number to episode number. If the first category is identical, it uses the next, etc. The only "fragile" part is in comparing two the integers. There's an easy fix, even without the .compare() method. I patched a copy of the sage.jar file if you want to give it a shot. I changed the compare/returns to this (which is how the non-int compares are done anyway):

              int x = n1 - n2;
              if (x != 0 && n1 != 0 && n2 != 0)
                return (n1 < n2) ? -1 : ((n1 > n2) ? 1 : 0);

It's shared here: https://www.dropbox.com/s/h761q3pbbz...ring_sort?dl=0

Ideally your system will be in a failing state when you shut it down, back up wiz.bin & your current sage.jar, then put this one in its place. This jar has 2 other patches in it I was doing for others that shouldn't affect you. One for NULLs in SeriesInfo people and an added API function.

I can't think of why the integers would be so far out of range to cause the original code to break down but it's the only thing I see to try.

[gary201]

Wow. Thanks!

I've downloaded the test .jar. Sage has been in this state now for a few days, and for the moment even the Reverse isn't changing anything. Sage is currently recording, and there's a queue of things lined up well into the night. Tomorrow morning I'll check sage, shut it down, backup the wiz.bin and existing .jar file, copy this test .jar in and see how it goes then report back.

This does, however, lead me to a question. If the suspicion is that there's an integer value that's either invalid or out of the expected bounds, maybe an offline wiz.bin file checker would be useful (e.g. something folks could run that checks for invalid data fields, etc.) Just a thought.

[wnjj]

I made this standalone wiz.bin reader 3 years ago in C++. It could be modded to check for valid numbers in any of the data fields, once you can define what valid means.

If the temporary jar fixes your issue, I could maybe add some debug logging into the sort call to search the list for bad data first, just to help track down its source or maybe come up with something to log either way. If bad data turns out to be the cause, I suspect it’s something to do with the imported shows/BMT. My setup is a lot like yours (OTA HDHR) but I don’t import anything. I’ve never seen a blank list.

[gary201]

Originally Posted by wnjj

I made this standalone wiz.bin reader 3 years ago in C++. It could be modded to check for valid numbers in any of the data fields, once you can define what valid means.

If the temporary jar fixes your issue, I could maybe add some debug logging into the sort call to search the list for bad data first, just to help track down its source or maybe come up with something to log either way. If bad data turns out to be the cause, I suspect it’s something to do with the imported shows/BMT. My setup is a lot like yours (OTA HDHR) but I don’t import anything. I’ve never seen a blank list.

This morning, I verified that Sage was not displaying anything w/the desired sort, then stopped sage, backed up the existing jar and wiz files, copied over the test jar file and restarted sage. The recordings display now shows content when sorting by Orign. Air Date. I can't thank you enough!

I certainly wouldn't rule out BMT. There are a number of little quirks/bugs I've noticed with it, but it's such a nice tool for importing PlayOn recorded content so that it gets added to the Sage recordings display. Since cutting the [cable tv] cord, I have more recorded content now than I ever had (like over 80 days of 24x7 content). LOL.

The only question that remains is will this newer jar affect doing the next update? I'm running on Linux, and every time there's an update (which isn't often) I have to research how it's done. I'm primarily a Windows person (my daytime slave labor).

[wnjj]

Excellent!

I’ll see about getting the changes officially submitted so they will get into the next build. I’ve never submitted a pull request before but will figure it out. Just don’t update to a new version until it’s in there though those are infrequent enough that it likely won’t happen. Worst case you can put the jar back after updating if you do one.

I use Linux at work but am pretty clueless about running Sage on it.

[gary201]

Originally Posted by wnjj

Excellent!

I’ll see about getting the changes officially submitted so they will get into the next build.

Well, to my surprise the problem returned this evening. It was working, then I watched a show, and when it was over the problem reappeared. Reversing the sort for Original Air Date did result in the content being displayed.

Just for kicks I followed the steps for your wiz.bin exporter. Could this be related to the discussion over here? https://forums.sagetv.com/forums/sho...6&postcount=30

[wnjj]

Looking more at the comparator code, I think I see a flaw now:

          {
            Show s1 = getShowObj(o1);
            Show s2 = getShowObj(o2);
            long l1 = (s1 == null) ? 0 : s1.getOriginalAirDate();
            long l2 = (s2 == null) ? 0 : s2.getOriginalAirDate();
            if (l1 < l2)
              return -1;
            else if (l1 > l2)
              return 1;
            if (s1 != null && s2 != null)
            {
              int n1 = s1.getSeasonNumber();
              int n2 = s2.getSeasonNumber();
              int x = n1 - n2;
              if (x != 0 && n1 != 0 && n2 != 0)
                return x;
              n1 = s1.getEpisodeNumber();
              n2 = s2.getEpisodeNumber();
              x = n1 - n2;
              if (x != 0 && n1 != 0 && n2 != 0)
                return x;
            }
            Airing a1 = getAirObj(o1);
            Airing a2 = getAirObj(o2);
            l1 = (a1 == null) ? 0 : a1.getStartTime();
            l2 = (a2 == null) ? 0 : a2.getStartTime();
            return (l1 < l2) ? -1 : ((l1 > l2) ? 1 : 0);
          }

Consider 3 shows that have the same original airing date (the first l1=l2). Show A has a valid season number (non 0), show B has a valid episode number and show C has both valid. Since the code above requires both compared shows to have valid seasons or episodes to compare, the following triangle happens:

A and B are compared by Airing start time.
B and C are compared by episode.
C and A are compared by season.

It’s therfore possible for A < B < C < A which violates the contract.

I think the code needs changed so that if either show has a valid (non 0) episode or season it should sort by it. This is what the original date already does since it allows a time of 0 to be compared.

It doesn’t directly explain why reverse works, other than it likely changes the order of the objects as they sort so may not trigger the problem.

I’ll try another round of code when I get some time.

Also, I’m convinced season is backwards since a lower numbered season with the same original airing date is a newer show and should therfore be considered “greater” than the other.