[Lunatixz]

I recently upgrade to 0.5.6c and I gotta say this addon has improved dramatically in both stability and featureset over the last couple of month, great work Luna, very impressive.
Code related question for you Luna, in FileAccess.py, what is the intent of the refreshLocks method? I've been having a strange issue on my FireTVs and I think it's related to that method. Long story short, my system works great for a seemingly random period of time and then it becomes unstable and can't play any videos either via PSTVL or direct launching. Any attempts to play a video just bring up the XBMC loading indicator and the video never starts (no buffering, just never starts). Checking the log shows that the request to start the video happens, but it just doesn't start.
After some digging, I believe on the FireTVs that the refreshLocks method is spinning up threads that never return and eventually there aren't enough system threads available to even start up a video which is why I spin like this. Restarting XBMC (not the whole FireTV) temporarily solves the issue. A couple of weeks ago I put a return statement at the top of the refreshLocks method so that the refreshLocksTimer doesn't get reset and no more threads get spun up. This has solved my issue and my system is good to go, or at least appears to be. I'm curious what this method is for and if I may have caused downstream side effects that I haven't noticed yet. Thanks!

If you don't mind me asking... what makes you believe this has anything to do with your problem? other then you see a print of it on your log? Just wondering...

Anyway, refreshLock doesn't call new threads, then abandon them. It's only called once, and doesn't run more then one thread.

Debugging by guessing . refreshLocks is the only thing active in my logs when this issue starts and returning False right away was the only change I made and seems to have solved my issue. Python isn't my bread and butter but I was looking at "self.refreshLocksTimer = threading.Timer(4.0, self.refreshLocks)" and thinking that was spinning up a new thread but not seeing anything to kill the old thread. I just re-read the timer API that while it is true that it is starting a new thread, the old thread stops when refreshLocks ends. Looking at this now, I'm not sure why this change seems to have corrected my problem. What is this method for anyhow? Not looking for a fix in the codebase, this might be a one-off that I run on my system that works for me for some reason.

It's part of channel sharing and file locking... it runs once, every 4 minutes as designed. If you could send me a log when you experience your problem I could provide further input.