GetShowSeriesInfo issue with V9

[jusjoken]

Jeff (or others),

I have run into an issue with "GetShowSeriesInfo" where it returns null in V9 but a valid SeriesInfo in V7. I chased it around for awhile but eventually I tried a V7 install where I get Info, change only the Sage.jar (and added Lucene) and then it no longer gets the series info.

Interestingly enough, "GetAllSeriesInfo()" does return a list of SeriesInfo including the SeriesInfo for the MediaFile I am looking for....

So the SeriesInfo exists... V7 will pull it using GetShowSeriesInfo, but V9 will not.

Do you have some thoughts on where I can look to correct this or suggestions on fixing it

k

[Narflex]

Well that's odd. We tested that pretty extensively when we converted over to a more extendable way of doing SeriesInfo lookups; but apparently something isn't completely correct.

If you look at Show.getSeriesInfo() that's where it'll do the lookup. Since the DB is coming from V7, then the seriesID and showcardID should both end up being zero in the Show object. This means it'll then end up generating a legacySeriesID based on the externalID (Tribune ID) and then using that for a lookup. The legacySeriesID is an identifier in the SeriesInfo object and should remain unchanged from V7 to V9.

What I'd do is figure out what those fields are in the Show object in question; and then also figure out what the legacySeriesID is in the SeriesInfo object in question...and then why the two don't properly matchup (or somehow it's a failure in the lookup in Wizard.getSeriesInfoByLegacySeriesID method, but I highly doubt that...unless somehow that index for it isn't properly sorted). Let me know what you find at that point.

[jusjoken]

Originally Posted by Narflex

Well that's odd. We tested that pretty extensively when we converted over to a more extendable way of doing SeriesInfo lookups; but apparently something isn't completely correct.

If you look at Show.getSeriesInfo() that's where it'll do the lookup. Since the DB is coming from V7, then the seriesID and showcardID should both end up being zero in the Show object. This means it'll then end up generating a legacySeriesID based on the externalID (Tribune ID) and then using that for a lookup. The legacySeriesID is an identifier in the SeriesInfo object and should remain unchanged from V7 to V9.

What I'd do is figure out what those fields are in the Show object in question; and then also figure out what the legacySeriesID is in the SeriesInfo object in question...and then why the two don't properly matchup (or somehow it's a failure in the lookup in Wizard.getSeriesInfoByLegacySeriesID method, but I highly doubt that...unless somehow that index for it isn't properly sorted). Let me know what you find at that point.

seriesID and showcardID are both 0 as you expected.

The call to getSeriesInfo returns null after this part....

// Add the 'MI' & 'IE' prefix for plugins to be able to link series info to imported media items
if ((externalID[0] != 'E' || externalID[1] != 'P') && (externalID[0] != 'S' || externalID[1] != 'H') && (externalID[0] != 'M' || externalID[1] != 'I') &&
    (externalID[0] != 'I' || externalID[1] != 'E'))

externalID.toString returns = '[B@89fb43'
externalID[0] = 77
externalID[1] = 70
externalID.length = 7

Does this help any

k

[jusjoken]

BTW...I exported properties for the specific media file and it shows...

ExternalID=MF24190

So there seems to be a valid externalID.

Let me know if I need to gather more info of if I am pulling the info above wrong.

k

[Narflex]

The externalID starting with 'MF' means that there was no real linkage with the Tribune metadata..so no linkage to a SeriesInfo object (and it uses the MF prefix when it imports a MediaFile, but if there's a Tribune ID in that metadata, then it will get changed to be that). But that exact same code block was there in V7 as well. And upgrading from V7 to V9 should not change the external ID in a Show object.

I'd be very curious what the ExternalID is in V7 from that same Show object (there's an API call to get that). And if for the same object ID, you're getting different ExternalID values across the 2 versions...then I'd also like to see your log file for when you run V9 against that DB the first time and do that query (it may be remapping the IDs).

[wnjj]

This looks like something my wiz DB to SQL program could help with. Run it on both the V7 and V9 wiz.bin and you can just use a text editor or grep to track down all of these ID's.

http://forums.sagetv.com/forums/showthread.php?t=62512

[jusjoken]

The ExternalID is the same for V7 and V9....I retested it using calls to GetShowExternalID within the STV and both output the same MFxxxx ID.

However, I think I have narrowed down the issue in Show.java.

Show.java declares externalID as "byte[] externalID;"

When it returns a value from getExternalID which is what GetShowExternalID calls it does the following...

return new String(externalID, Sage.I18N_CHARSET);

This converts the Byte Array to a valid String.

However, in the getSeriesInfo (and other parts of Show.java, it trys to directly check the value of externalID[0] and externalID[1] to string values such as "M" and "F" etc. These compares all fail as externalID[0] as the first byte of the array = "70" (in my case).

So if I am on the right track then either the declare needs to not use a Byte[] or the checks need to be changed to first convert the value of externalID to a String and then do the positional checks.

There are a number of areas in the class that would need changing depending on the approach so before taking a stab at it I thought I would check if you had a suggested direction to tackle this.

k

[jusjoken]

Originally Posted by wnjj

This looks like something my wiz DB to SQL program could help with. Run it on both the V7 and V9 wiz.bin and you can just use a text editor or grep to track down all of these ID's.

http://forums.sagetv.com/forums/showthread.php?t=62512

Just found the issue as you were typing and it's in the java code not the database so not needed this time....but I will check out this tool.

Thanks
k

[wnjj]

I'm not sure if it's the byte vs string issue. What's causing your NULL is this:

    // Legacy Show object handling...
    if (externalID.length < 8)
      return null;

Your externalID is "MF24190" which is not 8 or more chars. When I looked in my DB, all of the externalIDs for shows that are associated with a series look more like this: "MV0376610000" or "EP0191100097". This is why the code to extract the legacyID starts at byte 2 and drops 6 bytes and must be at least 8. It removes the "MV" or "EP" and the last 4 digits. For the first one, the legacyID is 37661 and there is no seriesinfo data (MV=movie). In the second case the legacyID is 19110 and I can find that in the seriesinfo data in my DB.

So like Jeff was pointing out, something seems to be wrong with your externalID.

For what it's worth, all of my photos and music have "MF" ID's like your show does because they aren't linked to any guide data.

[jusjoken]

Originally Posted by wnjj

I'm not sure if it's the byte vs string issue. What's causing your NULL is this:

    // Legacy Show object handling...
    if (externalID.length < 8)
      return null;

Your externalID is "MF24190" which is not 8 or more chars. When I looked in my DB, all of the externalIDs for shows that are associated with a series look more like this: "MV0376610000" or "EP0191100097". This is why the code to extract the legacyID starts at byte 2 and drops 6 bytes and must be at least 8. It removes the "MV" or "EP" and the last 4 digits. For the first one, the legacyID is 37661 and there is no seriesinfo data (MV=movie). In the second case the legacyID is 19110 and I can find that in the seriesinfo data in my DB.

So like Jeff was pointing out, something seems to be wrong with your externalID.

For what it's worth, all of my photos and music have "MF" ID's like your show does because they aren't linked to any guide data.

if the code ever got that far it would return null there, however it does fail prior to that immediately after the check i mentioned above.

i actually don't expect it to pass originally as there is no linkage as Jeff points out however, phoenix will then create a linkage using the metadata and from then on there will be SeriesInfo for the imported media file. This part works in v7.

you may also be on to something if the external id needs to be >8 in length as on a fresh machine i found it starts at MF1.

k

[wnjj]

Originally Posted by jusjoken

if the code ever got that far it would return null there, however it does fail prior to that immediately after the check i mentioned above.

i actually don't expect it to pass originally as there is no linkage as Jeff points out however, phoenix will then create a linkage using the metadata and from then on there will be SeriesInfo for the imported media file. This part works in v7.

you may also be on to something if the external id needs to be >8 in length as on a fresh machine i found it starts at MF1.

k

After looking closer, you're right about the first check. The real issue is that only 'EP', 'SH', 'MI' and 'IE' ID's are linkable. So starting at MF1 isn't the issue so much as the fact that it is an 'MF' type.

[Narflex]

The byte[] vs. String is not a problem. Those values will match what's in the byte array because they are in the 7 bit ASCII range, so even though those bytes represent a UTF-8 String, it'll be fine.

I don't see any way that it can be returning you a SeriesInfo object in V7 if that's the externalID. So the question now is...how are you accessing the SeriesInfo data? Is it using the standard V7 UI...or at least through the GetSeriesInfo API call? (I expect not, as that shouldn't give you anything)

You mentioned using Phoenix...and that may be the key piece of information I'm missing here...if Phoenix is doing something else special to get the SeriesInfo in it's code when the core doesn't return one; then I'm not aware at all of what it's doing and I'd need details on that to help further.

[jusjoken]

I will dig through the code further and see if I can discern what is happening and you are correct, it may be the phoenix call needs updating as it works with V7 and not with V9. I will also talk with stuckless.

As for the externalID numbering.... it does look like the code expects these to be at least 8 characters yet mine are considerably smaller...is that expected for MF type externalID's?

Thanks
k

[wnjj]

Originally Posted by jusjoken

I will dig through the code further and see if I can discern what is happening and you are correct, it may be the phoenix call needs updating as it works with V7 and not with V9. I will also talk with stuckless.

As for the externalID numbering.... it does look like the code expects these to be at least 8 characters yet mine are considerably smaller...is that expected for MF type externalID's?

Thanks
k

It expects lengths greater than 8 but also only expects types 'EP', 'SH', 'MI' and 'IE'. So your 'show' cannot have linked seriesinfo unless it's one of those types (i.e. starts with those chars).