Wanting to port SuperDateTime to Touch - need help

[erland]

I'm not sure you'll have to go the poll route. Basically the plugin updates everything in one batch. If you subscribe to a notification on the data state you can update whenever you're notified a data refresh of everything is complete.

Sounds good

There's a link to an example of the Sports output for MLB on the API URL above. It's basically raw currently active game data. You'll probably want another API call to retrieve all the teams for each sport so that a user can pick which ones they want displayed. I can add that if desired.

How are sports handled for Classic/Boom/Transporter players ?

I can see that in the SDT settings page in server settings you can select a team but there doesn't seem to be any sports related settings in the player settings ?

Is sports separate %* keywords in players settings ?
Or does the player switch between showing sports information selected in server settings and the weather information selected in player settings ?

If team is only selected in server settings, the Custom Clock should be able to use that setting to know which sports information it should display.

[GoCubs]

Sounds good
How are sports handled for Classic/Boom/Transporter players ?

I can see that in the SDT settings page in server settings you can select a team but there doesn't seem to be any sports related settings in the player settings ?

Currently users specify the teams they're interested at the plugin-level. All players show the same teams.

Is sports separate %* keywords in players settings ?
Or does the player switch between showing sports information selected in server settings and the weather information selected in player settings ?

Sports do not have custom %* macros. Basically the plugin shows weather-related for x seconds that include the %* macros and then shows each sports score/etc. for y seconds cycling one after each other.

At the player-level the user can specify what they want their weather screens to look like via the %* macros. They can actually specify multiple views that they can cycle between via the up/down remote buttons. They can also immediately cycle the sports/etc info by using the right/left remote buttons.

If team is only selected in server settings, the Custom Clock should be able to use that setting to know which sports information it should display.

True! I didn't think of that. Each selected team is stored as an array. In some cases 'All' is also a valid choice.

[plympton]

There's a few things about the code that I think needs some attention to make it more robust. First, for each line of text or image, it makes a separate request, and each of these requests is done in parallel (assync, right?). I think they can step on each other if there's some lag, or an error, and that's probably not good. We could easily send SDT an array/table of request strings and have it process them all at once. [Edit: I saw some weirdness in the logs when it was fetching data every second, but after switching to 10 second polling, I haven't seen that problem generally]

Might be tricky to do in CustomClock, since it's geared towards reading in the config data and getting results right away. But you could have it building up the request array, and then have it go to a function that:
1. Checks to see if the data is updated, if not, use cached information.
2. Sends the appropriate request, gets results, and parses them for all strings.

Also, this block of text doesn't process if the player is in play mode. Is there a reason for that? It looks like the playerStatus.mode isn't necessary, since it will never (?) call this routine unless the ScreenSaver timeout has occurred, right?

function _getLocalizedWeatherInfo(self,time,text,no)

local player = appletManager:callService("getCurrentPlayer")
local playerStatus = player:getPlayerStatus()
log:debug("Received text: "..text)

if playerStatus.mode ~= 'play' or self:getSettings()["nowplaying"] == false then
...
end

-Dan

[erland]

There's a few things about the code that I think needs some attention to make it more robust. First, for each line of text or image, it makes a separate request, and each of these requests is done in parallel (assync, right?). I think they can step on each other if there's some lag, or an error, and that's probably not good. We could easily send SDT an array/table of request strings and have it process them all at once. [Edit: I saw some weirdness in the logs when it was fetching data every second, but after switching to 10 second polling, I haven't seen that problem generally]

Might be tricky to do in CustomClock, since it's geared towards reading in the config data and getting results right away. But you could have it building up the request array, and then have it go to a function that:
1. Checks to see if the data is updated, if not, use cached information.
2. Sends the appropriate request, gets results, and parses them for all strings.

I think it should be doable to handle this in Custom Clock, it's just a matter of collecting all sdttext items before requesting them. If you could implement the JSON command on the plugin side that would be a good start.

We basically just need some code that iterates through all items in self.configItems and finds all items of stdtext and gets their formatting string and create the request to the server. The response would have modify the text in the self.items structure for all corresponding items.

Do you think users will have a lot of sdt items on the same screen ?
Would the different items have to be synchronized so they switch to new values simultaneously ?

If there are just a few items and they doesn't have to be completely synchronized, it might not be worth to combine them into a single request.

Also, this block of text doesn't process if the player is in play mode. Is there a reason for that? It looks like the playerStatus.mode isn't necessary, since it will never (?) call this routine unless the ScreenSaver timeout has occurred, right?

I'll have to check your code updates to know for sure, but it sounds like it shouldn't check playserStatus.mode in this case. I've been busy with some comboxbox implementations for color attributes in web ui and the spectrummeter item during the last days, so I haven't had the chance to look into SDT in detail yet. Hopefully I should get some time later in the week.

One more question, how are the sdt weather images handled in your implementation. Does it only get the image for the current day or is it possible to configure if it should get the image for today, tomorrow or the day after that.

What about the sdt weather text items, do they only look at current day or can you show weather for the next days too ?

Regarding sport/game scores I'm starting to think they would be best to handle as a separate item type so I think we can ignore them for now, it's better to get something up and running for the weather info.

[plympton]

Do you think users will have a lot of sdt items on the same screen ?
Would the different items have to be synchronized so they switch to new values simultaneously ?

I think most people will only have 4-10 (max) items on the screen at once. Who knows, with a slate squeezebox..iSqueezeBox.. whatever. :-)

I'll have to check your code updates to know for sure, but it sounds like it shouldn't check playserStatus.mode in this case.

I changed it, and it's fine. I think it's just an artifact of example code.

One more question, how are the sdt weather images handled in your implementation. Does it only get the image for the current day or is it possible to configure if it should get the image for today, tomorrow or the day after that.

Right now, it just fetches the current image, but I'm going to make changes and create a new icon request. Let me think on this one - make it fetch all at once (get a table back). I might use the power of automatic parameter loading on the plugin side to make it flexible on the LUA side.

What about the sdt weather text items, do they only look at current day or can you show weather for the next days too ?

You should be able to look at anything you want - any combo. I can easily see creating a row of 3 icons on the bottom for tonight->tomorrow->next day, or a sidebar of temps for the next few days. Heck, maybe get funky and create a graph out of the text data, but that's a next step. :-)

Regarding sport/game scores I'm starting to think they would be best to handle as a separate item type so I think we can ignore them for now, it's better to get something up and running for the weather info.

agreed.

Thanks!

-Dan

[erland]

You should be able to look at anything you want - any combo. I can easily see creating a row of 3 icons on the bottom for tonight->tomorrow->next day, or a sidebar of temps for the next few days. Heck, maybe get funky and create a graph out of the text data, but that's a next step. :-)

How does the formatting string look like if I like to show the weather for tomorrow ?
The %* keywords posted earlier only seemed to be tied to the current day.

Feels like I'm missing something obvious ?
Or do I need the "all" request to get this kind of data ?

[plympton]

How does the formatting string look like if I like to show the weather for tomorrow ?
The %* keywords posted earlier only seemed to be tied to the current day.

Feels like I'm missing something obvious ?
Or do I need the "all" request to get this kind of data ?

Yes, you need to do the all request to get that specific data. Basically, there are 2 types of requests:
1. Send a macroString request with a %* keyword string and get back an answer (though I think I saw a method to create your own %* keyword). This evolved from my SDTstring before.
2. Request a set of data and get back an answer. The requests are:

wassup (a test set) == currentF,current, and currentIcon
weather == wetData, the whole wetData structure
sports == sportsData, the whole sportsData structure (don't have that handy)
misc == miscData, the whole wetData structure (probably should be the whole miscData structure)
display == displayLine1, and displayLine2, what the SB2,3,boom, transporter display
all == wetData, sportsData, miscData structures

-Dan

[erland]

Attached is my modified code to get a reasonable approximation of SuperDateTime using CustomClock.

Included is my:
Modified SuperDateTime plugin (I had to un-par it)
Changes include:
- added a JSON SDTstring method. This accepts a SDT string and returns parsed values (%h -> 78% for humidity)
- added a JSON SDTicon method. This only returns current conditions icon value (26 -> 26.png, the cloudy icon)

I took some time and looked into this and have some questions ?
1. Shouldn't the SDTicon take the period parameter into account instead of always getting the data from the -1 period ?
2. Is there a reason why you just want to return the icon id (forecastIcon) and not the complete path (forecastIconURLSmall) ? Are you thinking about custom icon sets or is there some other reason ? Maybe the command should return both to make it more generic ?

Greg:
Is it safe for me to trust that these new commands will be implemented as SDTstring and SDTicon in a future official SDT release ?
I'm asking because in that case I can check for these commands in my code to decide if the SDT support should be enabled or not.

[plympton]

I took some time and looked into this and have some questions ?
1. Shouldn't the SDTicon take the period parameter into account instead of always getting the data from the -1 period ?

Yes, it should. SDTicon is gone. You should just do a 'weather' request, and parse the 'wetData' return table - you can pretty easily get anything you want out of there.

[quote]2. Is there a reason why you just want to return the icon id (forecastIcon) and not the complete path (forecastIconURLSmall) ? Are you thinking about custom icon sets or is there some other reason ? Maybe the command should return both to make it more generic ?

No reason, really. It was just a few keys easier for me, and forecastIcon was implemented in the 'wassup' test method when I started this whole process. :-)

Greg:
Is it safe for me to trust that these new commands will be implemented as SDTstring and SDTicon in a future official SDT release ?
I'm asking because in that case I can check for these commands in my code to decide if the SDT support should be enabled or not.

My answer - SDTstring is now 'macroString', SDTicon is gone, use 'weather' instead and parse the 'wetData' return table.

Thanks!

-Dan

[erland]

Dan, when you handled the answer from SDTstring (macroString) in your version of the applet you had this code:

local text = os.date(chunk.data.SDTstring,time)
self.items[no]:setWidgetValue("itemno",text)
log:debug("Result from SDTString: "..text)

Is there a reason why you call os.date here ?

Won't this collide with the %H (wu_humidity) and %M (wu_dewpointC) replaced by the plugin ?

It feels like we should have a separate syntax if we like to be able to mix os.date keywords with SDT keywords in the same formatting string. Maybe we could use %%M and let the applet replace %% with % before it pass it to os.date ?