stationID: string or integer?

[rkulagow]

I'm going to be adding test data for Australia shortly to gauge user interest in feeds for AU and NZ.

However, there's a collision between the existing stationID values and the ones that I would have for those countries. In the API for the JSON service, stationID has always been sent as a string.

Does Sage / the Open Source grabber maintain that stringification? If yes, then I will be able to use "AU18294" and "18294" to make sure that on the server those are unique schedule entities so that I don't need to maintain multiple databases.

If no, then the grabber may need to strip the first two characters if they're not digits (because it's unlikely that a user will is going to use both AU data _and_ data for anywhere else that we currently have lineups and schedules.)

[wnjj]

Looks like int in Channel.java:

    stationID = in.readInt();

[jamesdisco]

Do you think you might look at doing UK data

[rkulagow]

We've had UK data for quite a while on the JSON service. If you PM me your postal code I can let you know which lineups we have and a sample of the data.

Unless the grabber is hardcoded for US/Canada?

[Slugger]

It should work with any country so long as the raw json data is in the same format as US/Canada.

It will definitely not work with any data where the stationid contains non-numeric characters. The Sage client to the data assumes that Interger.parseInt(airing.stationid) will "just work". If that doesn't, boom goes the dynamite.

[rkulagow]

Good to know; I've asked a few other consumers of the JSON data, and they all treat the stationID as a string; Sage seems to be the exception, so if AU/NZ data moves forward then it may be something where the grabber needs to add/remove "AU" or "NZ" prior to sending the request so that it can continue to treat the remainder as an integer.

[Narflex]

Modifying the SageTV internals so that stationID is a String would not be all that complex to do.

[Fuzzy]

Originally Posted by Narflex

Modifying the SageTV internals so that stationID is a String would not be all that complex to do.

Likely the biggest issue would be dealing with the wiz.bin, as I'm guessing StationID is there in the Airings, right?

[wnjj]

Originally Posted by Fuzzy

Likely the biggest issue would be dealing with the wiz.bin, as I'm guessing StationID is there in the Airings, right?

It's in Channel at a minimum. The snippet I posted is from the wiz.bin reading code.

[Narflex]

If there's going to be a limited number of String prefixes on stationIDs; then I'd just recommend creating a mapping of them to some higher values. So for example if it's AU12345, then map AU to be 100000000 and this one becomes 100012345. StationIDs are stored in 32 bit integers...so there's plenty of extra room in that field to encode a set of 2 character prefixes.

[Tiki]

Originally Posted by Narflex

If there's going to be a limited number of String prefixes on stationIDs; then I'd just recommend creating a mapping of them to some higher values. So for example if it's AU12345, then map AU to be 100000000 and this one becomes 100012345. StationIDs are stored in 32 bit integers...so there's plenty of extra room in that field to encode a set of 2 character prefixes.

If the string portion is always 2 letters, you could even consider doing an ascii to int conversion (A = 65, U = 85). This would support future codes without needing more mapping, the downside is it is more limited in the maximum number of characters that would fit into a 32-bit integer (so you might get into trouble if some of the string prefixes were longer than 2 characters).

[Fuzzy]

Originally Posted by Tiki

If the string portion is always 2 letters, you could even consider doing an ascii to int conversion (A = 65, U = 85). This would support future codes without needing more mapping, the downside is it is more limited in the maximum number of characters that would fit into a 32-bit integer (so you might get into trouble if some of the string prefixes were longer than 2 characters).

Since the prefixes are likely all country codes, they could also be converted to 3166-1 numeric codes, which are 3 digit (0-999).