2014-05-12, 20:13
First time on the forum so apologies if this is not the way it's done. First class piece of software btw, absolutely brilliant.
I think there may be a 'feature'(but not a true bug) in XBMC 13.0 (but was also present I 12.0).
Version running 13.0
Chipset Intel i7-3770k
12Gb Memory
Windows 8.1 fully patched
I noticed that several times after starting XBMC it would freeze - i.e. became unresponsive in Windows and had to be force closed. If you left it for long enough (several - over 5 - minutes) it responded again (as in the screen came back and repainted). Selecting any of the options caused the same freeze though. After a bit of debugging/systinternals devilry it came down to (I believe) a USB hub connected to the machine. The connecting cable looks slightly loose - remove the cable and XBMC runs fine. It seems (and I haven't looked at the code so is a guess) that the program may rescan the machine looking for USB connected media players. If there is a problem with the hub it will obviously cause a slow response whilst the (unresponsive) devices fails to respond.
So after all the ramblings the question is - Should I report this? I haven't seen it reported before and was a feature i 12.0 as well as 13. If the scan was fired on a background thread for example then the block would probably not happen (and could be reported as slow running?). As I say - it is not a bug I as much as there is an easy work round and is hardly XBMCs fault my hub has been probably chewed by two little rugrats, but possibly a design issue that could be improved?
Thanks
Mike
I think there may be a 'feature'(but not a true bug) in XBMC 13.0 (but was also present I 12.0).
Version running 13.0
Chipset Intel i7-3770k
12Gb Memory
Windows 8.1 fully patched
I noticed that several times after starting XBMC it would freeze - i.e. became unresponsive in Windows and had to be force closed. If you left it for long enough (several - over 5 - minutes) it responded again (as in the screen came back and repainted). Selecting any of the options caused the same freeze though. After a bit of debugging/systinternals devilry it came down to (I believe) a USB hub connected to the machine. The connecting cable looks slightly loose - remove the cable and XBMC runs fine. It seems (and I haven't looked at the code so is a guess) that the program may rescan the machine looking for USB connected media players. If there is a problem with the hub it will obviously cause a slow response whilst the (unresponsive) devices fails to respond.
So after all the ramblings the question is - Should I report this? I haven't seen it reported before and was a feature i 12.0 as well as 13. If the scan was fired on a background thread for example then the block would probably not happen (and could be reported as slow running?). As I say - it is not a bug I as much as there is an easy work round and is hardly XBMCs fault my hub has been probably chewed by two little rugrats, but possibly a design issue that could be improved?
Thanks
Mike
