2012-09-08, 21:20
I said may in bold to show that I was not thinking like that
The problem is not about requesting thumbs or not in Json list but fetching the data in Xbmc while the user just want to have the data if it present or not.
Even for first data get it does not seems reliable to do this scan from an synchronous http call, this would lead to timeouts.
When I did update the test machine and going in Audio I get a big popup warning telling me to scan thumbs or I won't get them, so the user is well aware that until he does that thumbs won't be present.
The current implementation to correct the fact that the user will eventually do Json first before going in interface have so many performance impact on 100% of the users (remember the 20 times ratio for RPI) that it can reach final stage.
If first access from JSON lock further generation of thumbs from interface I suppose this should be corrected but if further access will correctly generate those then this is not really a problem.
The problem is not about requesting thumbs or not in Json list but fetching the data in Xbmc while the user just want to have the data if it present or not.
Even for first data get it does not seems reliable to do this scan from an synchronous http call, this would lead to timeouts.
When I did update the test machine and going in Audio I get a big popup warning telling me to scan thumbs or I won't get them, so the user is well aware that until he does that thumbs won't be present.
The current implementation to correct the fact that the user will eventually do Json first before going in interface have so many performance impact on 100% of the users (remember the 20 times ratio for RPI) that it can reach final stage.
If first access from JSON lock further generation of thumbs from interface I suppose this should be corrected but if further access will correctly generate those then this is not really a problem.