[quote=“guessed, post:699, topic:169644”]I’ve added some logic to [tt]I_Sonos1.xml[/tt] to “cache” the results of the call (successful, or non-successful) for 30 minutes. This will greatly cut down on the number of URL calls being made against TuneIn (1/120th # calls)
This change has been checked into trunk.
This cache operates per-device. If you have 2 Sonos devices, then you’ll see the calls 2x as often (assuming you’re listening to TuneIn Radio stations on both). In the cache, you’ll see one call every 30 mins that “goes through”, and then just the successive calls that are all getting cache hits. If the channel is changed, then you’ll see another call “go through”.[/quote]
And why not avoiding to call it when the Sonos is not playing the radio (stop) ? When I don’t use my Sonos, it is a little stupid to get this page from the tunein web site.
Hopefully the bans are done by a bot, and will go away once we slow the rate of calls down. The next step will be to eliminate [tt]luup.inet.wget[/tt] calls, converting them over to LuaSocket HTTP calls, and putting in all the logic to "look more like" they're coming from a Sonos unit.
If we’re not using the data, I’m more than happy for it to be completely removed from the code.
I thought you were thinking of a more conditional execution type item, so I must have misread your intent.
Along the same lines, before we push to apps.mios.com, should we “obsolete” all the stuff that’s using AVMISC_OBSOLETE as well? There are counterparts in the standard set of variables, and this will likely lead to confusion.
Why not setting the force cache refresh even higher, something like one time per day ? I am even not sure that there is a real need to force a refresh. Suppressing it would reduce again the wget (only done when tuning to a new radio station) and so avoid to be detected by “tunein police”.
Sure, go for it. I added the one that was best compartmentalized, but there will likely be others. My Sonos units are “off” overnight, so I probably don’t see the same issues that others will.
I hope too. How much time shall we wait ?
You should apply the code change now, since that will slow the calls that are currently erroring out. If they have a bot on their end, it'll see less calls and might put you back into the "good" bucket.
It all depends upon how they’re setup, IDS, etc.
If it’s a perm ban, then you might need to reset your DSL (etc) unit to get you a new [external] IP Address.
Go for it, it’s just a constant. I wasn’t sure how much people would feel about “1” failed URL call causing the image not to appear for the whole day (since I use the same Cache-timer for both successful and non-successful calls)
[quote=“guessed, post:703, topic:169644”]Along the same lines, before we push to apps.mios.com, should we “obsolete” all the stuff that’s using AVMISC_OBSOLETE as well? There are counterparts in the standard set of variables, and this will likely lead to confusion.
Thoughts?[/quote]
IMHO yes. That should be clearly advertised when releasing the new version.
Go for it, it’s just a constant. I wasn’t sure how much people would feel about “1” failed URL call causing the image not to appear for the whole day (since I use the same Cache-timer for both successful and non-successful calls)[/quote]
Ah ok, I did not think about that case. So I just hope that 30 minutes will be enough to not be “banished” !
You should apply the code change now, since that will slow the calls that are currently erroring out. If they have a bot on their end, it’ll see less calls and might put you back into the “good” bucket.
It all depends upon how they’re setup, IDS, etc.[/quote]
That’s done. To be continued.
If it's a perm ban, then you might need to reset your DSL (etc) unit to get you a new [external] IP Address.
I am not sure that my DSL provider assigns a new external IP when I reboot my box.
I try immediately…
I installed Wireshark and made my first captures. I am not yet at all familiar with this software but I was able to spy commands sends by my Sonos application (on the PC) to the Sonos.
I can confirm that when I open “Line-In”, the software calls Browse with “AI:” as parameter. So I does not understand why it does not work for you.
Second interesting point, I think I know how the application is retrieving the tuniein radio station logo. It is through a HTTP GET /getaa?s=1&u=
I just committed the change for the album art. This code could potentially work for other services than tunein.
The URL is now a HTTP call to the Sonos, not to tunein web site. So I think there is no risk to be banished from tunein anymore.
Let’s try this new code during few days. If it is ok, we will have to clean up the code to delete getTuneInStationLogo function.
I am proud to have found that ;D My first steps with Wireshark.
I tried to analyse what happens when the Sonos control application (PC) is started. Unfortunately I did not really learn new things that could help us.
PlayURI is no more workiong to play a tunein radio (TR:xxx). I don’t know what was changed but I get an error at line 779 in a sub function call. @guessed: did you change something in this function since this week-end ?
[quote=“lolodomo, post:718, topic:169644”]PlayURI is no more workiong to play a tunein radio (TR:xxx). I don’t know what was changed but I get an error at line 779 in a sub function call. @guessed: did you change something in this function since this week-end ?[/quote]
Same thing here. The scenes I set up for TuneIn stations are no longer working.