XBMC4Xbox

Not sure if this is discussed somewhere here already, Ive spent a while searching for it but after going through 100's of results that had nothing to do with what im experiencing I figured that I would just ask.

anyway....

when I dont have internet connected to my xbox, the cpu speed and also the hdd temp as well as the other hdd info (such as serial, firmware, power cycle count, etc) show up as 'busy' for an extended period of time. The query of this data does finally complete, but it takes a few minutes. Then it will show the proper values, but only for maybe a few seconds, then it goes back to 'busy' for a few minutes again. It just repeats this long query process over and over.

when I do have an internet connection on my xbox, they only show as 'busy' for a second or two before the values show up.

* note: the cpu temp and gpu temp dont have this problem *

is there anyway to resolve the long delay in getting these values when there is no internet connection? as I only have my xbox hooked up to my pc (and internet) when Im actually transfering files via ftp.


I dont know what the actual cause of this is, but if I had to guess I would probably say that it seems that at whatever interval it checks for all this data, that it checks for an internet connection before checking the hdd info and cpu speed and when theres no internet it just takes a bit longer till it accepts that theres no internet connection and moves on to getting the hdd info and cpu speed values.


also, I could be mistaken but I dont recall experiencing this with 3.3.3. I'm pretty sure it started once I began using 3.3.5 builds (currently on 3.3.5 rc1)

A debug log might help us figure it out, see if you can enable it, let it run for a while, then connect the network and extract the log to upload to xbmclogs.com
http://www.xbmc4xbox.org.uk/forum/viewt ... p?f=6&t=65

Here's the log: http://www.xbmclogs.com/show.php?id=283620

If a longer time span for the log is needed, i can easily grab it again...


Anyway, I turned the internet on at around the 10:53 time in the log. Pretty much right when the "ERROR: DNS lookup for www.google.com failed: 10060" stops appearing

Now, I'm not that familiar with the code, but just glancing over I would say it tries to refresh the information every 15 seconds, and since the network connection is not present checking for http://www.google.com it will wait to timeout, and it will start over before it gets to the HDD info call.

https://svn.exotica.org.uk:8443/xbmc4xb ... emInfo.cpp
It's worth creating a Redmine ticket for Buzz to review (see Development tab at the top).

I just wanted to update this thread with the status of this issue....


This is now reported as being fixed in revision 32936

http://redmine.exotica.org.uk/issues/316


*edit*

I just compiled 32938 and checked it real quick, seems to be much better. If theres no network connection at all it only takes a second or two to get the info. It also seems that if there is a network connection but no internet (as in wired connection to my pc but without sharing my internet connection to the xbox) there is still the delay while it says 'busy' but for some reason it seems to not be as long for me now (though this shouldnt have changed I dont think from this fix as when it detects a network it still does the same check for an internet connection through that network i believe). But, at least to me, thats not a big deal because the only time i usually have it networked to my pc but without internet is when Im transfering some files with the intent of unplugging as soon as the transfers are complete.

Now after hearing the problem I could remember the same thing. I want to add that the rescraping of most information which is hardcoded is not necessary and annoying. Only variable things like temperature should be scanned again.

@diamond-optic
Well done!

@tim619
On the not necessary, while that might be true, that is the original code and although it could be changed, effort is higher than benefit, unless of course you want to contribute with a patch Can you detail on the annoying part? Is it annoying you that you know that it does it?

@Dan

At the moment I cannot say. Although I'm using RC2 I get "Busy" for all fields (I have no internet connection atm) I dont remember this appearances on older builds. On the HDD Info page even after 2 minutes no change... When I take a look at the source file you linked it would be: else return CInfoLoader::BusyInfo(info); but I couldnt find definition of CInfoLoader and BusyInfo() and honestly I hate OOP.

But obviously this would mean m_bRequestDone is false (m_bRequestDone never done or stayed in it forever)

Edit: Okay as I read it is maybe not included in RC2 I would have to wait for R3 or compile myself

@tim16
I will try it myself tonight and let you know. My hope is that with the new check Buzz added it will come out very quickly out of the internet connection check when no connection, so that even if it refreshes everything as it is it will do so very quickly so that will be unnoticeable.

Wait for the next build on "unofficial builds" thread, I'm sure it will get included in next RC3 (if one) or in final.

PS:
CInfoLoader is in it's own separate file, xbmc/utils/InfoLoader.cpp - not that I understand much about the JobManager and how it actually works, just noticed that it explains the refreshes.

I agree with what you're saying, technically a separation to check unmodifiable info just once while refreshing the other ones is a good idea and it could probably work, it's just that if its not done right, it could break the whole thing entirely for a while, which obviously would be worse. Best motivation I ever found though was need or want - we all hate stuff we don't get, till we start getting it

Dan Dar3 wrote:My hope is that with the new check Buzz added it will come out very quickly out of the internet connection check when no connection, so that even if it refreshes everything as it is it will do so very quickly so that will be unnoticeable.

With Buzz's fix, when you are not connected to a network it pulls the info quickly and Im only seeing the 'busy' value for a second or so before they get filled back in. But i will agree that it could be viewed as unnecessary to retrieve every value over and over when the majority are not going to change. From a coding point of view, it just might be a more simple route to just have one function get all the values each time then to have seperate functions that get all the values initially then after that only update the temps & ones that might change. At the same time it wouldnt be much work to have a bool variable that gets set after the initial values are received and then have all further checks skip over most of the queries when the bool is set to true. I guess having it only update values that might change could lower the overhead of the queries but it would probably be a negligible difference in the end.


Also, im very new to xbmc (especially the code to it all, but ive been browsing through it and seeing how it works a bit) but i almost get the feeling previous builds might not refresh all the info (or maybe just not as often?) because I also dont remember this happening when I first started using xbmc (3.3.3 i believe). I would have to check it out to be sure because Im just guessing without actually looking to be sure, but just from what I remember experiencing I'm leaning towards it only getting most of these values one time.

I could be totally wrong but I dont remember my HDD temp, for example, ever changing from the initial value till I updated to one of the 3.5 betas. What I seem to remember is playing a game or something pretty heavily off the HDD and exiting out to xbmc and the hdd temp would be pretty high and never change even after letting it just sit on the xbmc home screen for a while with the fan cranked up. Then i could reboot the xbox and the hdd temp would be way down to normal idle temp. (I use the PM3.HD skin that Ive slightly modified so my cpu, gpu, hdd temps are always shown at the botton of the screen so I could sit there and watch the other temps decrease while my hdd temp I dont think ever did). Perhaps my memory of it is wrong because I didnt really pay much attention to it at the time.

*edit*

actually just glancing over it, since the hdd temp is called seperately via SMART:
then the serial etc:
it would seem that if the m_hddRequest variable didnt get reset to false that it would not retrieve those values again while still updating the temp value...


There is also this where that variable (as well as the values themself get wiped):
But i dont see exactly where the CSysInfo::Reset function is being called from to set that variable back to false. Does the same thing happen with the DVD drive info as well? (unable at the moment to check myself but I would guess that that same thing is happening with the dvd drive values).

I do see the m_hddRequest variable being set to false in another spot in the CSysInfo::GetHDDInfo function:
In that snippet it also sets the variable to true once completing the query (assuming that it successfully sets it to true), and then only back to false if the values didnt get retrieved (personally I wouldnt write it this way, setting it to true then checking if it needs to be set back to false would usually be considered sloppy and the check should happen first with an else statement to set it to true instead), so I would think that where it sets it to false in the CSysInfo::Reset function is what makes them get retrieved again. I might just be reading the code wrong as well too (very likely actually) as its been a while since Ive done any coding and even longer since Ive messed around in C++

If i get a chance (likely not till the weekend when I have a day off), I might try commenting out part of the CSysInfo::Reset function and recompiling to see if that makes them stop updating while still updating the temp. Though I would also like to dig a bit deeper and see where the reset is being called from because I guess ive missed it at the moment

Today I set up all things to compile x4x 32938 and it worked (on win7x64). After 20min I got the zip package. I'll now try it. And from now on if I'll update things which aren't important for you by myself

E: Okay tested it and works fine. Also without internet connection all things unless os version and uptime show immediately and the others ~2seconds.

Now my plans are to take a look at the splash screen. I mean if its needed and if not I will kill it and let xbmc boot 1 second quicker

tim619 wrote:Now my plans are to take a look at the splash screen. I mean if its needed and if not I will kill it and let xbmc boot 1 second quicker

dont have time to look in any detail as im on my way out the door for dinner, but for the splash stuff take a look in the
..\xbmc\Application.cpp file
I dont know if removing it will save any time. For me, the splash screen is just a quick flash before im in the xbmc home screen.. It's probably sorta just a background image for while xbmc is doing its loading thing, so removing the splash might not make any difference since xbmc still needs to do its other stuff at the same time

@diamond-optic

Thank you very much for posting the filename where it loads the splash. I compiled a version without splash screen and it was exactly like you supposed.
Instead of the splash it loaded a black screen and after the normal waiting time xbmc appeared. So no need for further work here

@tim619
If it still has to wait, you can just as easily replace the splash.png with very small blank image, which should be fast to decode and will take little RAM, all without a code change.

No there wasnt any additional waiting time. I didnt simply removed the splash.png. I compiled a new build with patched source code and saw that it was like diamond said. If you mean a small png or low colour image could increase the loading time than I'm pretty sure that wouldnt improve the process.